Dynamic service calling method and device, computer program product and electronic equipment

Abstract

The invention discloses a service dynamic calling method and device, a computer program product and electronic equipment. The method comprises the following steps: receiving a service calling instruction sent by a calling party, and determining a target calling service from the service calling instruction; the calling state of the calling party is determined, the address synchronization state of the target registration center connected with the calling party and the target main registration center is determined according to the calling state, and the calling state is used for determining whether the calling party is allowed to call all addresses in the target main registration center or not; judging whether a calling address of the target calling service exists in the target registration center or not according to the address synchronization state; and under the condition that the calling address exists in the target registration center, executing service calling operation according to the calling address. Through application of the method and the device, the problem that the service address does not have a dynamic adjustment capability and further the efficiency and the accuracy of service calling operation are reduced due to the fact that the service address is configured by using a static configuration file in the related technology is solved.

Description

Technical Field

[0001] This application relates to the field of distributed systems, and more specifically, to a method, apparatus, computer program product, and electronic device for dynamically invoking services. Background Technology

[0002] In the complex distributed architectures of the financial sector, service discovery mechanisms play a crucial role in ensuring the efficiency and reliability of core business functions such as transaction processing, risk management, and customer service. This mechanism allows service consumers to dynamically identify and locate service providers at runtime, thereby adjusting service invocation strategies to cope with node additions, removals, failures, or load changes without manual intervention. However, traditional service discovery methods, such as pre-setting service provider addresses through static configuration files or environment variables, have significant limitations.

[0003] While static configuration is simple to implement and easy to manage, when service provider nodes change dynamically, such as when a service provider needs to be hidden, the address information in the static configuration will be updated to include that service provider, but it cannot be hidden. This allows service consumers to still call that address, leading to exceptions.

[0004] For example, in non-disaster recovery mode, if service consumers can access service providers in the disaster recovery environment, it may cause unnecessary traffic load and even interfere with the production environment during disaster recovery drills. Conversely, during disaster recovery switchover, service consumers in the production environment must be able to quickly locate service providers in the disaster recovery environment to ensure service continuity and business security. Static configuration files cannot flexibly meet the service discovery needs in this scenario and lack the ability to perceive and dynamically adjust service status.

[0005] There is currently no effective solution to the problem that the use of static configuration files to configure service addresses in related technologies results in the service addresses not having the ability to be dynamically adjusted, which in turn reduces the efficiency and accuracy of service call operations. Summary of the Invention

[0006] The main objective of this application is to provide a method, apparatus, computer program product, and electronic device for dynamic service invocation, in order to solve the problem in related technologies where the use of static configuration files to configure service addresses results in the service addresses not having the ability to be dynamically adjusted, thereby reducing the efficiency and accuracy of service invocation operations.

[0007] To achieve the above objectives, according to one aspect of this application, a method for dynamic service invocation is provided. The method includes: receiving a service invocation instruction sent by a caller, and determining the target service to be invoked from the service invocation instruction; determining the caller's invocation status, and determining the address synchronization status between the target registry and the target main registry connected to the caller based on the call status, wherein the call status is used to determine whether the caller is allowed to invoke all addresses in the target main registry; determining whether the invocation address of the target service exists in the target registry based on the address synchronization status; and, if the invocation address exists in the target registry, performing a service invocation operation based on the invocation address.

[0008] Optionally, determining the target service from the service invocation instruction includes: identifying the instruction content in the service invocation instruction and determining whether there is a preset service name in the instruction content; if there is a preset service name in the instruction content, determining the target service based on the preset service name; if there is no preset service name in the instruction content, performing semantic recognition on the instruction content to obtain the service requirement indicated by the instruction content, and determining the service with the highest correlation to the service requirement as the target service.

[0009] Optionally, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. Determining the address synchronization status between the target registry center connected to the caller and the target master registry center based on the call status includes: when the call status is not abnormal, determining that the address information stored in the first slave registry center and the first master registry center is synchronized, and determining that the address information stored in the second slave registry center and the second master registry center is not synchronized; when the call status is abnormal, determining that the address information stored in the first slave registry center and the first master registry center is synchronized, and determining that the address information stored in the second slave registry center and the second master registry center is synchronized.

[0010] Optionally, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. Determining whether the target registry center contains a call address for the target service based on the address synchronization status includes: if the address information stored in the second slave registry center and the second master registry center is not synchronized, determining whether the first slave registry center contains a call address; if the first slave registry center contains a call address, determining that the target registry center contains a call address; if the first slave registry center does not contain a call address, determining that the target registry center does not contain a call address.

[0011] Optionally, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. Determining whether the target registry center contains a call address for the target service based on the address synchronization status includes: if the address information stored in the second slave registry center is synchronized with the address information stored in the second master registry center, determining whether the second slave registry center contains a call address; if the second slave registry center contains a call address, determining that the target registry center contains a call address; if the second slave registry center does not contain a call address, determining whether the first slave registry center contains a call address; if the first slave registry center contains a call address, determining that the target registry center contains a call address; if the first slave registry center does not contain a call address, determining that the target registry center does not contain a call address.

[0012] Optionally, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. The method further includes: when the call state changes from a non-abnormal state to an abnormal state, connecting the second slave registry center with the second master registry center and synchronizing the address information stored in the second master registry center to the second slave registry center; when the call state changes from an abnormal state to a non-abnormal state, disconnecting the connection between the second slave registry center and the second master registry center and clearing the address information in the second slave registry center.

[0013] Optionally, determining the caller's call status includes: obtaining the user information of the logged-in caller and determining the test status of the user information in a preset list; if the caller's user is a test user, determining the call status as an abnormal status; if the caller's user is not a test user, determining the call status as a non-abnormal status.

[0014] To achieve the above objectives, according to another aspect of this application, a service dynamic invocation apparatus is provided. The apparatus includes: a receiving unit, configured to receive a service invocation instruction sent by a caller and determine the target invocation service from the service invocation instruction; a determining unit, configured to determine the caller's invocation status and, based on the call status, determine the address synchronization status between the target registry and the target main registry connected to the caller, wherein the call status is used to determine whether the caller is allowed to invoke all addresses in the target main registry; a judging unit, configured to determine, based on the address synchronization status, whether the invocation address of the target service exists in the target registry; and an execution unit, configured to, if the invocation address exists in the target registry, execute a service invocation operation based on the invocation address.

[0015] Optionally, the receiving unit includes: a first judging module, used to identify the instruction content in the service call instruction and judge whether there is a preset service name in the instruction content; a first determining module, used to determine the target call service according to the preset service name if there is a preset service name in the instruction content; and a second determining module, used to perform semantic recognition operation on the instruction content if there is no preset service name in the instruction content, to obtain the service requirement indicated by the instruction content, and to determine the service with the highest correlation with the service requirement as the target call service.

[0016] Optionally, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. The determining unit includes: a third determining module, used to determine that the address information stored in the first slave registry center and the first master registry center are synchronized, and to determine that the address information stored in the second slave registry center and the second master registry center are not synchronized, when the call state is not abnormal; and a fourth determining module, used to determine that the address information stored in the first slave registry center and the first master registry center are synchronized, and to determine that the address information stored in the second slave registry center and the second master registry center are synchronized, when the call state is abnormal.

[0017] Optionally, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. The judgment unit includes: a second judgment module, used to determine whether the first slave registry center contains a call address when the address information stored in the second slave registry center and the second master registry center are not synchronized; a fifth determination module, used to determine that a call address exists in the target registry center when the first slave registry center contains a call address; and a sixth determination module, used to determine that a call address does not exist in the target registry center when the first slave registry center does not contain a call address.

[0018] Optionally, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. The judgment unit includes: a third judgment module, used to determine whether the second slave registry center contains a call address when the address information stored in the second slave registry center and the second master registry center are synchronized; a seventh determination module, used to determine whether a call address exists in the target registry center when the second slave registry center contains a call address; a fourth judgment module, used to determine whether the first slave registry center contains a call address when the second slave registry center does not contain a call address; an eighth determination module, used to determine whether a call address exists in the target registry center when the first slave registry center contains a call address; and a ninth determination module, used to determine whether a call address does not exist in the target registry center when the first slave registry center does not contain a call address.

[0019] Optionally, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. The device further includes: a synchronization unit, used to connect the second slave registry center and the second master registry center when the call state changes from a non-abnormal state to an abnormal state, and to synchronize the address information stored in the second master registry center to the second slave registry center; and a disconnection unit, used to disconnect the connection between the second slave registry center and the second master registry center and to clear the address information in the second slave registry center when the call state changes from an abnormal state to a non-abnormal state.

[0020] Optionally, the determining unit includes: a first obtaining module, used to obtain user information of the logged-in caller and determine the test status of the user information in a preset list; a tenth determining module, used to determine the call status as an abnormal state when the caller's user is a test user; and an eleventh determining module, used to determine the call status as a non-abnormal state when the caller's user is not a test user.

[0021] To achieve the above objectives, according to another aspect of this application, an electronic device is provided, the electronic device including a memory storing an executable program; and a processor for running the program, wherein the program executes the above-described service dynamic invocation method during runtime.

[0022] To achieve the above objectives, according to another aspect of this application, a computer program product is provided, including computer instructions that, when executed by a processor, implement the steps of the above-described service dynamic invocation method.

[0023] In this embodiment, the method involves receiving a service invocation instruction sent by the caller and determining the target service from the instruction; determining the caller's invocation status and, based on the invocation status, determining the address synchronization status between the target registry and the target main registry connected to the caller, wherein the invocation status is used to determine whether the caller is allowed to call all addresses in the target main registry; determining whether the target service's invocation address exists in the target registry based on the address synchronization status; and, if the invocation address exists in the target registry, executing the service invocation operation based on the invocation address. By identifying the caller's invocation status, the method determines the target registry and the target service's invocation status based on the invocation status. The system synchronizes the address status of the target master registry center, determines the addresses that the caller can invoke based on the address synchronization status, and synchronizes the callable addresses from the target master registry center to the target registry center. This ensures that the caller can only invoke addresses in the target registry center. By monitoring the caller's invocation status in real time, the system can dynamically adjust the addresses that the caller can invoke, thereby improving the flexibility and accuracy of the caller's service invocation operations. This solves the technical problem in related technologies where the use of static configuration files to configure service addresses results in a lack of dynamic adjustment capabilities for service addresses, thus reducing the efficiency and accuracy of service invocation operations. Attached Figure Description

[0024] The accompanying drawings, which form part of this application, are used to provide a further understanding of this application. The illustrative embodiments and descriptions of this application are used to explain this application and do not constitute an undue limitation of this application. In the drawings:

[0025] Figure 1 A hardware structure block diagram of a computer terminal for implementing a dynamic service invocation method is shown.

[0026] Figure 2 This is a flowchart of the service dynamic invocation method provided in Embodiment 1 of this application;

[0027] Figure 3 This is a schematic diagram of the service dynamic invocation system provided in Embodiment 1 of this application. Figure 1 ;

[0028] Figure 4 This is a schematic diagram of the service dynamic invocation system provided in Embodiment 1 of this application. Figure 2 ;

[0029] Figure 5 This is a schematic diagram of a service dynamic invocation device provided according to Embodiment 2 of this application;

[0030] Figure 6 This is a structural block diagram of an electronic device according to an embodiment of this application. Detailed Implementation

[0031] It should be noted that, unless otherwise specified, the embodiments and features described in this application can be combined with each other. This application will now be described in detail with reference to the accompanying drawings and embodiments.

[0032] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0033] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0034] It should be noted that the service dynamic invocation method, apparatus, computer program product and electronic device defined in this disclosure can be used in the distributed domain, or in any domain other than the distributed domain. The application fields of the service dynamic invocation method, apparatus, computer program product and electronic device defined in this disclosure are not limited.

[0035] It should be noted that all information, user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, and displayed data) used in this application are information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, storage, use, processing, transmission, provision, disclosure, and application of related data all comply with the relevant laws, regulations, and standards of the relevant regions, have taken necessary confidentiality measures, do not violate public order and good morals, and provide corresponding operation entry points for users to choose to authorize or refuse use. If the user chooses to refuse, the process will proceed to the expert decision-making process. For example, this system has an interface with relevant users or organizations. Before obtaining relevant information, a request to obtain the information needs to be sent to the aforementioned user or organization through the interface. After receiving consent from the aforementioned user or organization, the relevant information is obtained. Users can view the purpose of data use in real time through the authorization interface and have the right to withdraw authorization or delete data at any time. After the authorization is withdrawn, the system will terminate the relevant data processing within 24 hours.

[0036] The embodiments or examples disclosed herein are not exhaustive, but merely illustrative of some embodiments or examples, and are not intended to limit the scope of protection of this disclosure. Unless otherwise specified, each step in a particular embodiment or example can be implemented as an independent embodiment, and the steps can be arbitrarily combined. For example, a solution after removing some steps in a particular embodiment or example can also be implemented as an independent embodiment, and the order of the steps in a particular embodiment or example can be arbitrarily interchanged. Furthermore, optional methods or examples in a particular embodiment or example can be arbitrarily combined; moreover, embodiments or examples can be arbitrarily combined. For example, some or all steps of different embodiments or examples can be arbitrarily combined, and a particular embodiment or example can be arbitrarily combined with optional methods or examples of other embodiments or examples.

[0037] For ease of description, the following explains some of the nouns or terms used in the embodiments of this application:

[0038] Service Registry: A service registry is a component in a distributed system used for service registration and discovery. Its main function is to provide a centralized, dynamically registerable, and discoverable platform for service providers and consumers. In a distributed system, service providers typically register their services with the registry. When a service consumer needs to invoke a service, it obtains the service provider's address from the registry and makes the call. This process is called service discovery.

[0039] Consumer: In a distributed system, a consumer is a component that uses the functionality or services provided by a service provider. Consumers do not directly execute business logic; instead, they complete tasks by calling interfaces provided by the service provider. Consumers can select and invoke different service providers as needed.

[0040] A service provider is a component in a distributed system that provides specific functionality or services. It can be an application, a module, a microservice, or any entity capable of performing specific tasks and providing interfaces to the outside world. The service provider is responsible for handling data and service requests from external sources, completing specific business logic or computational tasks, and then returning the results.

[0041] Example 1

[0042] According to an embodiment of this application, an embodiment of a service dynamic invocation method is also provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0043] The method embodiment provided in Embodiment 1 of this application can be executed on a mobile terminal, computer terminal, or similar computing device. Figure 1 A hardware block diagram of a computer terminal for implementing a dynamic service invocation method is shown. Figure 1 As shown, the computer terminal 10 (or mobile device) may include one or more processors 102 (shown as 102a, 102b, ..., 102n in the figure) 102 (processor 102 may include, but is not limited to, processing devices such as microprocessors or programmable logic devices), a memory 104 for storing data, and a transmission device 106 for communication functions. In addition, it may also include: a display, an input / output interface, a universal serial bus port (which may be included as one of the ports of a BUS bus), a network interface, a power supply, and / or a camera. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the aforementioned electronic device. For example, computer terminal 10 may also include... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0044] It should be noted that the aforementioned one or more processors 102 and / or other data processing circuits are generally referred to herein as "data processing circuits". These data processing circuits may be embodied, in whole or in part, in software, hardware, firmware, or any other combination thereof. Furthermore, the data processing circuits may be a single, independent processing module, or may be integrated, in whole or in part, into any other element within the computer terminal 10 (or mobile device). As involved in the embodiments of this application, the data processing circuits serve as a processor control mechanism (e.g., selection of a variable resistor termination path connected to an interface).

[0045] The memory 104 can be used to store software programs and modules of application software, such as the program instructions / data storage device corresponding to the service dynamic invocation method in this embodiment. The processor 102 executes various functional applications and data processing by running the software programs and modules stored in the memory 104, thereby realizing the aforementioned service dynamic invocation method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the computer terminal 10 via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0046] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by the communication provider of the computer terminal 10. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module, used for wireless communication with the Internet.

[0047] The display may be, for example, a touchscreen LCD display that allows the user to interact with the user interface of the computer terminal 10 (or mobile device).

[0048] Under the aforementioned operating environment, this application provides the following: Figure 2 The method for dynamically invoking the service is shown. Figure 2 This is a flowchart of the service dynamic invocation method provided in Embodiment 1 of this application, as follows: Figure 2 As shown, the method includes:

[0049] Step S201: Receive the service invocation instruction sent by the caller, and determine the target service to be invoked from the service invocation instruction.

[0050] It should be noted that the execution entity in this embodiment can be a service dynamic invocation system. This system can adjust the address that the caller can invoke by adjusting the synchronization status of the address in the target registry center connected to the caller, thereby ensuring the accuracy and flexibility of address invocation.

[0051] It should be noted that the caller refers to the service consumer in the distributed system, which has the ability to initiate service calls based on business needs. The service call instruction is issued by the caller to request the target service, and it contains the identification information of the service to be called. The target service is the specific service requested by the caller.

[0052] Specifically, when any caller in the system needs to invoke a service to complete a specific task, the caller needs to construct a service invocation instruction and send it to the system. This instruction not only needs to include basic information about the target service (such as service ID and version), but may also include detailed invocation parameters and the expected response format. After receiving the instruction, the system will parse it, extract the name and version of the service that the caller needs to invoke, determine the target service, and thus ensure that subsequent operations can accurately execute the invocation of the target service.

[0053] Step S202: Determine the caller's call status, and determine the address synchronization status between the target registry center connected to the caller and the target main registry center based on the call status. The call status is used to determine whether the caller is allowed to call all addresses in the target main registry center.

[0054] It should be noted that the call status can be used to describe the current operational status or business needs of the caller, determining the service providers it can access. The target registry is the registry directly connected to the caller, used to provide the caller with query and subscription services for service provider addresses. The target primary registry can refer to the registry that stores the registration services of all service providers. The address synchronization status can be used to describe the data synchronization status between the target registry and its primary registry.

[0055] Specifically, when determining whether a caller can invoke the service requested in the instruction, it is first necessary to determine the caller's call status. Based on the call status, the registry center is controlled to perform different address synchronization operations to dynamically control the addresses that the caller can invoke, thereby controlling the execution result of the call operation.

[0056] It should be noted that the call status can involve multiple dimensions, such as whether it is currently in a peak transaction period, whether a system upgrade or disaster recovery drill is underway, or whether it involves access to sensitive data. The system can determine the address synchronization strategy between the target registry center and the target main registry center based on the caller's call status, thereby controlling the service call result.

[0057] Furthermore, after determining the call status, the synchronization addresses between the target registry and the target main registry can be adjusted according to the call status. Synchronization operations are performed on the addresses of services that are allowed to be called, and desynchronization operations are performed on the addresses of services that are not allowed to be called. This ensures that when the caller uses the target registry to make service calls, it can only call services that are allowed to be synchronized, thereby completing the dynamic adjustment operation of services.

[0058] Step S203: Determine whether the target service call address exists in the target registry center based on the address synchronization status.

[0059] Specifically, after determining the synchronization status between the target registry and the target master registry based on the service status, the system needs to check whether the target registry has synchronized the call address of the target service. If the call address of the target service exists in the target registry, it indicates that the service caller can call the target service, and the service call operation can be performed directly.

[0060] Furthermore, if the target registry does not have the call address of the target service, it indicates that the target service is hidden from the caller, and the caller cannot perform a call operation on the target service, so the call operation is not allowed.

[0061] Step S204: If a call address exists in the target registry, perform a service call operation based on the call address.

[0062] Specifically, after confirming that the target service call address exists in the target registry, the caller can establish a network connection with the service provider based on the address information, initiate and execute the service call, and thus complete the service call operation.

[0063] The service dynamic invocation method provided in this application embodiment involves receiving a service invocation instruction sent by a caller and determining the target service from the instruction; determining the caller's invocation status and, based on the invocation status, determining the address synchronization status between the target registry and the target main registry connected to the caller, wherein the invocation status is used to determine whether the caller is allowed to invoke all addresses in the target main registry; determining whether the target service's invocation address exists in the target registry based on the address synchronization status; and, if the invocation address exists in the target registry, executing the service invocation operation according to the invocation address. By identifying the caller's invocation status, the target service of the caller is determined based on the invocation status. The registry center synchronizes its address with the target main registry center. Based on this synchronization, it determines the addresses that the caller can invoke and synchronizes these addresses from the target main registry center to the target registry center. This ensures that the caller can only invoke addresses from the target registry center. By monitoring the caller's invocation status in real time, the system dynamically adjusts the addresses that the caller can invoke, thereby improving the flexibility and accuracy of the caller's service invocation operations. This solves the technical problem in related technologies where static configuration files are used to configure service addresses, resulting in a lack of dynamic adjustment capabilities and reduced efficiency and accuracy of service invocation operations.

[0064] To accurately determine the target service to be invoked, optionally, in the service dynamic invocation method provided in this application embodiment, determining the target service to be invoked from the service invocation instruction includes: identifying the instruction content in the service invocation instruction and determining whether there is a preset service name in the instruction content; if there is a preset service name in the instruction content, determining the target service to be invoked based on the preset service name; if there is no preset service name in the instruction content, performing semantic recognition operation on the instruction content to obtain the service requirement indicated by the instruction content, and determining the service with the highest correlation to the service requirement as the target service to be invoked.

[0065] It should be noted that the preset service name is a service name predefined in the system, used to quickly identify and locate known service instances. The target service to be invoked is the service determined based on the content of the service invocation command. Semantic recognition operation, when there is no explicit service name in the service invocation command, involves in-depth analysis and understanding of the command content to determine the actual service needs of the caller.

[0066] Specifically, after receiving the service call instruction from the caller, the parsing engine configured in the system first reads and analyzes the various fields in the instruction. These fields may include the service identifier, parameter list, request headers, etc. The parsing engine identifies the preset service name by recognizing the service identifier.

[0067] Furthermore, if a preset service name is found in the instruction content, it indicates that the service call instruction directly points to a known service, and the target service can be directly determined. However, if the preset service name is missing from the instruction content, or the service name is ambiguous, a semantic recognition operation needs to be performed. This involves semantically recognizing the instruction content to obtain the service requirements indicated by the instruction. The semantic recognition module can understand the service requirements described in natural language and convert them into machine-readable parameters and attributes. Then, based on these parsed requirements, it searches for the most matching service instance in the service directory to determine the target service that the caller needs to invoke.

[0068] This embodiment ensures the accuracy of service call operations by accurately identifying the target service indicated by the service call instruction.

[0069] To accurately determine the address synchronization status based on the call status, optionally, in the service dynamic invocation method provided in this application embodiment, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. Determining the address synchronization status between the target registry center connected to the caller and the target master registry center based on the call status includes: when the call status is not abnormal, determining that the address information stored in the first slave registry center and the first master registry center is synchronized, and determining that the address information stored in the second slave registry center and the second master registry center is not synchronized; when the call status is abnormal, determining that the address information stored in the first slave registry center and the first master registry center is synchronized, and determining that the address information stored in the second slave registry center and the second master registry center is synchronized.

[0070] It should be noted that the target registry may include a first slave registry and a second slave registry, which are used to perform address synchronization operations with the first master registry and the second master registry in the target master registry, respectively. That is, the first slave registry performs address synchronization operations with the first master registry, and the second slave registry performs address synchronization operations with the second master registry. The first master registry and the second master registry obtain service addresses from the service provider, respectively.

[0071] Specifically, when a caller is ready to invoke a service, the system first needs to assess the caller's current invocation status. Figure 3 This is a schematic diagram of the service dynamic invocation system provided in Embodiment 1 of this application. Figure 1 ,like Figure 3As shown, if the call status is determined to be non-abnormal, meaning the system is running smoothly without disaster recovery drills or actual disaster impacts, the system will execute the following strategy: A synchronization mechanism for address information will be initiated between the first slave registry and the first master registry. This means the first slave registry will maintain address information synchronization with the first master registry to obtain all service addresses under normal operating conditions. Simultaneously, the synchronization mechanism between the second slave registry and the second master registry will be set to asynchronous, ensuring that the second slave registry will not receive service addresses from the second master registry, thus maintaining its service list unchanged under non-abnormal conditions.

[0072] Furthermore, Figure 4 This is a schematic diagram of the service dynamic invocation system provided in Embodiment 1 of this application. Figure 2 ,like Figure 4 As shown, if the call status is determined to be abnormal, such as during a disaster recovery drill or in the face of a real disaster, the service discovery system will adjust its synchronization strategy: the first slave registry will continue to synchronize with the first primary registry to maintain access to services in the normal operating environment; simultaneously, the second slave registry will initiate synchronization with the second primary registry to ensure that it can obtain and maintain all service address information under abnormal conditions. This strategy shift ensures that at any given time, the caller can access the service provider most suitable for the current environment.

[0073] In other words, under normal operating conditions, the caller's requests are primarily for services in the daily operation environment. At this time, the first slave registry will periodically or in real-time synchronize data with the first master registry, updating its service catalog to reflect the latest and most complete service address information. The second slave registry remains unchanged, for example, in an empty state, thus avoiding interaction with services in the second master registry. When the call state changes to an abnormal state, such as entering a disaster recovery drill phase, the system dynamically adjusts the address synchronization state. The second slave registry then begins full synchronization with the second master registry, obtaining all service address information from the second master registry. This ensures that the caller will not call services from the second master registry under normal operating conditions, and can access services from the second master registry promptly and accurately under abnormal conditions.

[0074] This embodiment ensures that the caller can make accurate service calls based on the call status by dynamically adjusting the address synchronization status between the registration centers, thus avoiding the caller calling the wrong address and affecting the normal operation of the caller.

[0075] To accurately determine whether the caller can perform the invocation operation, optionally, in the service dynamic invocation method provided in this application embodiment, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. Determining whether the target registry center has a call address for the target service based on the address synchronization status includes: if the address information stored in the second slave registry center and the second master registry center is not synchronized, determining whether the first slave registry center contains a call address; if the first slave registry center contains a call address, determining that the target registry center has a call address; if the first slave registry center does not contain a call address, determining that the target registry center does not have a call address.

[0076] Specifically, when the system is in an abnormal state, the second slave registry and the second master registry are not synchronized in terms of address. In this case, when the caller obtains the service address, it can only obtain it through the first slave registry. Therefore, it can be determined whether the first slave registry contains the call address. If the first slave registry contains the call address, the address can be obtained and the service can be called directly. If the first slave registry does not contain the call address, the service cannot be called. This ensures that when the address information stored in the second slave registry and the second master registry is not synchronized, that is, when the call state is not abnormal, the caller is only allowed to make service calls from the first slave registry, avoiding the caller from making service calls from the second slave registry, thereby ensuring the accuracy of the call operation.

[0077] This embodiment ensures the accuracy of service call operations under normal circumstances by allowing the caller to perform service call operations only from the first registry center.

[0078] To accurately determine whether the caller can perform the invocation operation, optionally, in the service dynamic invocation method provided in this application embodiment, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. Determining whether the target registry center has a call address for the target service based on the address synchronization status includes: if the address information stored in the second slave registry center and the second master registry center is synchronized, determining whether the second slave registry center contains a call address; if the second slave registry center contains a call address, determining that the target registry center has a call address; if the second slave registry center does not contain a call address, determining whether the first slave registry center contains a call address; if the first slave registry center contains a call address, determining that the target registry center has a call address; if the first slave registry center does not contain a call address, determining that the target registry center does not have a call address.

[0079] Specifically, if the address information stored in the second slave registry is synchronized with that in the second master registry, it indicates that the current state is abnormal. In this case, when the caller performs a call operation, there may be a situation where the target service has an address in both the second slave registry and the first slave registry. Therefore, in order to ensure the accuracy of the service address call, it is necessary to first determine whether the second slave registry contains the call address. If the second slave registry contains the call address, the corresponding address can be obtained from the second slave registry to execute the call operation of the target service, thereby ensuring the accuracy of the service call in the abnormal state.

[0080] If the second registry does not contain the call address, it may be because the target service's address has not been updated in time or the target service has not participated in disaster recovery testing or other projects, and therefore does not have the corresponding address. In this case, it is still necessary to determine whether the first registry contains the call address. If the first registry contains the call address, the address can be obtained and the service can be called directly. If the first registry does not contain the call address, it indicates that the service call cannot be performed. This ensures that if the call status is abnormal, the address is obtained from the second registry first to ensure accurate calling of the target service.

[0081] This embodiment ensures the accuracy of service call operations in abnormal situations by controlling the caller to first perform service call operations from the second registry center.

[0082] Optionally, in the service dynamic invocation method provided in this application embodiment, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. The method further includes: when the invocation state changes from a non-abnormal state to an abnormal state, connecting the second slave registry center with the second master registry center and synchronizing the address information stored in the second master registry center to the second slave registry center; when the invocation state changes from an abnormal state to a non-abnormal state, disconnecting the connection between the second slave registry center and the second master registry center and clearing the address information in the second slave registry center.

[0083] Specifically, when the system detects that the caller's call status has changed from a non-abnormal state to an abnormal state, it executes the connection establishment and data synchronization operation between the master and slave registry centers. The system first confirms that the communication link between the second slave registry center and the second master registry center is available, and then initiates the data synchronization protocol to copy all service address information in the second master registry center to the second slave registry center, so that the addresses in the second slave registry center and the second master registry center are consistent.

[0084] Similarly, when it is necessary to restore the state from an abnormal state to a normal state, the connection between the second slave registry and the second master registry needs to be disconnected to prevent unnecessary data synchronization activities from continuing and to avoid interference or resource waste to service providers in the normal operating environment. The disconnection operation can be performed by modifying the configuration file of the second slave registry or by calling the interface, so that the second slave registry no longer actively synchronizes data from the second master registry, but maintains an independent operating state.

[0085] Next, the address information in the second registry center needs to be cleared so that even if the caller accesses the second registry center, it cannot obtain any address information, thereby ensuring the accuracy of the service address call operation in a non-abnormal state.

[0086] This embodiment ensures the accuracy of service call operations by real-time monitoring of the service provider's call status and adjusting the registry's status when the call status changes.

[0087] To accurately determine the calling status of the caller, optionally, in the service dynamic calling method provided in this application embodiment, determining the calling status of the caller includes: obtaining the user information of the logged-in caller and determining the test status of the user information in a preset list; if the caller's user is a test user, determining the calling status as an abnormal status; if the caller's user is not a test user, determining the calling status as a non-abnormal status.

[0088] Specifically, when a caller attempts to execute a call operation, it needs to log in to the system to make the call. At this time, the login process will trigger the collection of user information. The system will verify the legitimacy of the login credentials provided by the caller and extract detailed user information, such as username, user role, department, and permission level, to lay the foundation for the call status judgment in subsequent steps.

[0089] After obtaining the user message, the system compares the caller's user information with a preset list to determine whether the user is a test user. The preset list is a database or list containing test user information that is predefined by the system. It can be stored in local memory, a remote service, or a distributed database for quick access and efficient querying.

[0090] If the system determines that the user who logged in is a test user in the preset list, the call status will be marked as abnormal. If the system fails to find a test status that matches the user information of the logged-in user in the preset list, the call status will be marked as non-abnormal. This will help identify whether the user who logged in is a test user and ensure the accuracy of subsequent service call operations.

[0091] This embodiment analyzes the caller's user information and determines the call status based on the user information, thereby ensuring the accuracy of subsequent call operations.

[0092] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0093] Example 2

[0094] This application also provides a service dynamic invocation apparatus. It should be noted that the service dynamic invocation apparatus of this application can be used to execute the service dynamic invocation method provided in the above embodiments. The service dynamic invocation apparatus provided in this application will be described below.

[0095] According to an embodiment of this application, an apparatus for implementing the above-described service dynamic invocation method is also provided. Figure 5 This is a schematic diagram of a service dynamic invocation device provided according to Embodiment 2 of this application, as shown below. Figure 5 As shown, the device includes:

[0096] The receiving unit 51 is used to receive the service call instruction sent by the caller and determine the target service to be called from the service call instruction.

[0097] The determining unit 52 is used to determine the calling status of the caller and determine the address synchronization status between the target registry center connected to the caller and the target main registry center based on the calling status. The calling status is used to determine whether the caller is allowed to call all addresses in the target main registry center.

[0098] The judgment unit 53 is used to determine whether the target service call address exists in the target registry center based on the address synchronization status.

[0099] Execution unit 54 is used to perform service call operations based on the call address if a call address exists in the target registry center.

[0100] The service dynamic invocation apparatus provided in this application embodiment receives a service invocation instruction sent by a caller through a receiving unit 51 and determines the target invocation service from the service invocation instruction; a determining unit 52 determines the caller's invocation status and determines the address synchronization status between the target registry and the target main registry connected to the caller based on the invocation status, wherein the invocation status is used to determine whether the caller is allowed to invoke all addresses in the target main registry; a judging unit 53 determines whether the target invocation service's invocation address exists in the target registry based on the address synchronization status; and an execution unit 54, if the invocation address exists in the target registry, executes a service invocation operation based on the invocation address. By identifying the caller's invocation status, the apparatus determines the target service invocation service based on the invocation status. The system determines the address synchronization status between the caller's target registry center and the target main registry center. Based on this synchronization status, it identifies the addresses the caller can invoke and synchronizes these addresses from the target main registry center to the target registry center. This ensures the caller can only invoke addresses from the target registry center. By monitoring the caller's invocation status in real time, the system dynamically adjusts the addresses the caller can invoke, thereby improving the flexibility and accuracy of service invocation operations. This solves the technical problem in related technologies where static configuration files for service addresses prevent dynamic adjustment, thus reducing the efficiency and accuracy of service invocation operations.

[0101] Optionally, in the service dynamic invocation device provided in this application embodiment, the receiving unit 51 includes: a first judgment module, used to identify the instruction content in the service invocation instruction and determine whether there is a preset service name in the instruction content; a first determination module, used to determine the target invocation service according to the preset service name when there is a preset service name in the instruction content; and a second determination module, used to perform semantic recognition operation on the instruction content when there is no preset service name in the instruction content, obtain the service requirement indicated by the instruction content, and determine the service with the highest correlation with the service requirement as the target invocation service.

[0102] Optionally, in the service dynamic invocation device provided in this application embodiment, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. The determining unit 52 includes: a third determining module, used to determine that the address information stored in the first slave registry center and the first master registry center are synchronized when the invocation state is not abnormal, and to determine that the address information stored in the second slave registry center and the second master registry center are not synchronized; and a fourth determining module, used to determine that the address information stored in the first slave registry center and the first master registry center are synchronized when the invocation state is abnormal, and to determine that the address information stored in the second slave registry center and the second master registry center are synchronized.

[0103] Optionally, in the service dynamic invocation device provided in this application embodiment, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. The judgment unit 53 includes: a second judgment module, used to determine whether the first slave registry center contains a call address when the address information stored in the second slave registry center and the second master registry center are not synchronized; a fifth determination module, used to determine that a call address exists in the target registry center when the first slave registry center contains a call address; and a sixth determination module, used to determine that a call address does not exist in the target registry center when the first slave registry center does not contain a call address.

[0104] Optionally, in the service dynamic invocation device provided in this application embodiment, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. The judgment unit 53 includes: a third judgment module, used to determine whether the second slave registry center contains a call address when the address information stored in the second slave registry center and the second master registry center are synchronized; a seventh determination module, used to determine whether a call address exists in the target registry center when the second slave registry center contains a call address; a fourth judgment module, used to determine whether the first slave registry center contains a call address when the second slave registry center does not contain a call address; an eighth determination module, used to determine whether a call address exists in the target registry center when the first slave registry center contains a call address; and a ninth determination module, used to determine whether a call address does not exist in the target registry center when the first slave registry center does not contain a call address.

[0105] Optionally, in the service dynamic invocation device provided in this application embodiment, the target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. The device further includes: a synchronization unit, used to connect the second slave registry center and the second master registry center when the invocation state changes from a non-abnormal state to an abnormal state, and to synchronize the address information stored in the second master registry center to the second slave registry center; and a disconnection unit, used to disconnect the connection between the second slave registry center and the second master registry center and to clear the address information in the second slave registry center when the invocation state changes from an abnormal state to a non-abnormal state.

[0106] Optionally, in the service dynamic invocation device provided in the embodiments of this application, the determining unit 52 includes: a first obtaining module, used to obtain user information of the logged-in invoker and determine the test status of the user information in a preset list; a tenth determining module, used to determine the invocation status as an abnormal status when the user of the invoker is a test user; and an eleventh determining module, used to determine the invocation status as a non-abnormal status when the user of the invoker is not a test user.

[0107] It should be noted that the receiving unit 51, determining unit 52, judging unit 53, and executing unit 54 mentioned above correspond to steps S201 to S204 in Embodiment 1. The instances and application scenarios implemented by each of the above units and the corresponding steps are the same, but are not limited to the content disclosed in Embodiment 1. It should be noted that the above modules or units can be hardware components or software components stored in memory (e.g., memory 104) and processed by one or more processors (e.g., processors 102a, 102b, ..., 102n). The above modules can also be part of the device and can run in the computer terminal 10 provided in Embodiment 1.

[0108] Example 3

[0109] Embodiments of this application may provide an electronic device. Figure 6 This is a structural block diagram of an electronic device according to an embodiment of this application. Figure 6 As shown, the electronic device may include: one or more ( Figure 6 (Only one is shown) processor 1002, memory 1004, memory controller, and peripheral interface, wherein the peripheral interface is connected to the radio frequency module, audio module and display.

[0110] The memory can be used to store software programs and modules, such as the program instructions / modules corresponding to the methods and apparatus in the embodiments of this application. The processor executes various functional applications and data processing by running the software programs and modules stored in the memory, thereby implementing the above-described methods. The memory may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory may further include memory remotely located relative to the processor, and these remote memories can be connected to the terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0111] Those skilled in the art will understand that Figure 6The structure shown is for illustrative purposes only. Electronic devices can also be smartphones, tablets, handheld computers, mobile internet devices (MIDs), PADs, and other terminal devices. Figure 6 This does not limit the structure of the aforementioned electronic device. For example, electronic devices may also include components that are more... Figure 6 The more or fewer components shown (such as network interfaces, display devices, etc.), or having the same Figure 6 The different configurations shown.

[0112] Those skilled in the art will understand that all or part of the steps in the various methods of the above embodiments can be implemented by a program instructing the hardware related to the terminal device. The program can be stored in a computer-readable storage medium, which may include: flash drive, read-only memory (ROM), random access memory (RAM), disk or optical disk, etc.

[0113] Example 4

[0114] Embodiments of this application also provide a storage medium. Optionally, in this embodiment, the storage medium can be used to store the program code executed by the service dynamic invocation method provided in Embodiment 1.

[0115] Optionally, in this embodiment, the storage medium may be located in any computer terminal in a group of computer terminals in a computer network, or in any mobile terminal in a group of mobile terminals.

[0116] Embodiments of this application also provide a computer program product, which, when executed on a data processing device, is adapted to perform the steps of a service dynamic invocation method.

[0117] Embodiments of this application also provide a computer-readable storage medium, which includes a stored executable program, wherein the executable program controls the device where the computer-readable storage medium is located to execute the above-described service dynamic invocation method during runtime.

[0118] The sequence numbers of the embodiments in this application are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0119] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0120] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual coupling, direct coupling, or communication connection may be through some interfaces; the indirect coupling or communication connection between units or modules may be electrical or other forms.

[0121] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0122] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0123] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0124] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for dynamically invoking services, characterized in that, include: Receive a service invocation instruction sent by the caller, and determine the target service to be invoked from the service invocation instruction; The caller's call status is determined, and the address synchronization status between the target registry and the target main registry connected to the caller is determined based on the call status. The call status is used to determine whether the caller is allowed to call all addresses in the target main registry. Based on the address synchronization status, determine whether the target service call address exists in the target registry center; If the call address exists in the target registry, the service call operation is performed based on the call address.

2. The method according to claim 1, characterized in that, Determining the target service from the service invocation instruction includes: Identify the instruction content in the service call instruction and determine whether a preset service name exists in the instruction content; If the preset service name exists in the instruction content, the target service to be invoked is determined based on the preset service name; If the preset service name is not present in the instruction content, a semantic recognition operation is performed on the instruction content to obtain the service requirement indicated by the instruction content, and the service with the highest relevance to the service requirement is determined as the target invocation service.

3. The method according to claim 1, characterized in that, The target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. Determining the address synchronization status between the target registry center connected to the caller and the target master registry center based on the call status includes: If the call status is not abnormal, it is determined that the address information stored in the first slave registry center and the first master registry center are synchronized, and the address information stored in the second slave registry center and the second master registry center are not synchronized. If the call status is abnormal, it is determined that the address information stored in the first slave registry center is synchronized with the address information stored in the first master registry center, and the address information stored in the second slave registry center is synchronized with the address information stored in the second master registry center.

4. The method according to claim 1, characterized in that, The target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. Determining whether the target service call address exists in the target registry center based on the address synchronization status includes: If the address information stored in the second slave registry center and the second master registry center is not synchronized, determine whether the first slave registry center contains the calling address; If the first registry contains the call address, it is determined that the target registry contains the call address. If the calling address is not found in the first registry center, it is determined that the calling address does not exist in the target registry center.

5. The method according to claim 1, characterized in that, The target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. Determining whether the target service call address exists in the target registry center based on the address synchronization status includes: If the address information stored in the second slave registry center is synchronized with that in the second master registry center, determine whether the second slave registry center contains the calling address; If the second registry contains the call address, it is determined that the call address exists in the target registry. If the second registry does not contain the call address, determine whether the first registry contains the call address; If the first registry contains the call address, it is determined that the target registry contains the call address. If the calling address is not found in the first registry center, it is determined that the calling address does not exist in the target registry center.

6. The method according to claim 1, characterized in that, The target registry center includes a first slave registry center and a second slave registry center, and the target master registry center includes a first master registry center and a second master registry center. The method further includes: When the call state changes from a non-abnormal state to an abnormal state, the second slave registry center is connected to the second master registry center, and the address information stored in the second master registry center is synchronized to the second slave registry center. If the call status changes from an abnormal state to a normal state, the connection between the second slave registry and the second master registry is disconnected, and the address information in the second slave registry is cleared.

7. The method according to claim 1, characterized in that, Determining the caller's call status includes: Obtain the user information of the logged-in caller, and determine the test status of the user information in a preset list; If the user calling the service is a test user, the call status will be determined as an abnormal status. If the user of the caller is not the test user, the call status is determined to be a non-abnormal state.

8. A service dynamic invocation device, characterized in that, include: The receiving unit is used to receive a service invocation instruction sent by the caller and determine the target service to be invoked from the service invocation instruction; A determining unit is configured to determine the calling status of the caller and, based on the calling status, determine the address synchronization status between the target registry and the target main registry connected to the caller, wherein the calling status is used to determine whether the caller is allowed to call all addresses in the target main registry; The judgment unit is used to determine whether the target service call address exists in the target registry center based on the address synchronization status. An execution unit is configured to perform a service call operation based on the call address if the call address exists in the target registry.

9. A computer program product comprising computer instructions, characterized in that, When the computer instructions are executed by the processor, they implement the steps of the service dynamic invocation method according to any one of claims 1 to 7.

10. An electronic device, characterized in that, include: Memory, which stores executable programs; A processor for running the program, wherein the program executes the service dynamic invocation method according to any one of claims 1 to 7 when it runs.

Images