Service control method, system and device for a railway system

Abstract

The application discloses a service control method, system and device of a railway system, relates to the technical field of computer software system architecture, and comprises the following steps: receiving a remote access request initiated by a client device by using a preset gateway; detecting whether an effective token exists in a request header of the remote access request by using a global filter in the preset gateway; if the effective token exists, determining a target service instance from health service instances of a target microservice, and forwarding the remote access request to the target service instance; the application realizes deep integration of railway multi-systems at a service level by setting microservices with independent data storage and deployment environments based on division of business function boundaries of the railway system; the preset gateway is used as a unified entrance of all client requests, can shield address changes of rear-end microservices, and enhances system security and maintainability; meanwhile, based on dynamic routing of instance health states, system availability and fault tolerance capability are improved.

Description

Technical Field

[0001] This invention relates to the field of computer software system architecture technology, and in particular to a service control method, system and equipment for a railway system. Background Technology

[0002] With the continuous improvement of the railway industry's informatization level, various specialized railway management systems (such as signal monitoring systems, dispatching and command systems, wireless data conversion systems, equipment maintenance systems, and production operation systems) have been gradually established and put into operation. Most of these systems are independently developed and deployed monolithic application architectures, resulting in serious data silos, difficulties in business linkage, and insufficient availability and stability among them.

[0003] While some related technologies involve service-oriented decomposition of existing monolithic systems using a microservice architecture centered on "single responsibility," this approach suffers from several drawbacks: 1) The increasing number of services leads to dynamic changes in IP addresses and ports, making it difficult for the front-end to directly locate services. 2) Each service independently implements authentication logic, resulting in code redundancy and the risk of key leakage. 3) The health status of service instances is difficult to perceive, impacting call reliability. Therefore, the challenge lies in integrating various railway management systems to achieve a unified identity authentication access point, thereby shielding backend service address changes and improving call reliability and user experience. Summary of the Invention

[0004] The purpose of this invention is to provide a service control method, system, and device for railway systems, which can integrate various railway management systems, realize a unified identity authentication access point, shield the address changes of backend services, and improve the reliability of calls and user experience.

[0005] To solve the above-mentioned technical problems, the present invention provides a service control method for a railway system, comprising: Using a preset gateway, remote access requests initiated by client devices are received; The global filter in the preset gateway is used to detect whether a valid token exists in the request header of the remote access request; If a valid token exists, the target service instance is determined from the health service instances of the target microservice, and the remote access request is forwarded to the target service instance; wherein, the target microservice is the preset microservice corresponding to the remote access request, and each preset microservice is a microservice registered in the service registry that has an independent data storage and deployment environment based on the business function boundary of the railway system, and the preset microservice includes at least one of signal monitoring service, wireless transshipment service and production operation service; the service registry registers instance information of each preset microservice, and the instance information includes address information and health status information.

[0006] On the other hand, the step of using the global filter in the preset gateway to detect whether a valid token exists in the request header of the remote access request includes: The global filter is used to detect whether the interface path of the remote access request is a preset whitelist path; If the path is a preset whitelist path, the remote access request is forwarded to the service corresponding to the interface path; wherein, the preset whitelist path includes at least one of the login path, registration path, and public information query path; If the path is not in the preset whitelist, then check if a token with a preset token format exists in the request header; If a token with the preset token format exists, then check if the user information corresponding to the token exists in the preset distributed cache; If user information corresponding to the token exists, then it is determined that a valid token exists in the request header, and the steps of determining the target service instance from the health service instances of the target microservice and forwarding the remote access request to the target service instance are executed.

[0007] On the other hand, the preset whitelist path includes the login path, and forwarding the remote access request to the service corresponding to the interface path includes: If the interface path is the login path, then the remote access request will be forwarded to the authentication and authorization service; The authentication and authorization service is used to verify the user login credentials in the remote access request; After the user login credentials are verified, a globally unique token is generated, and the generated token and the user information corresponding to the user login credentials are stored in the preset distributed cache in the form of key-value pairs; wherein, the user information includes at least one of user identifier, role list, organization, and token validity period; The generated token is sent to the client device.

[0008] Determining the target service instance from the health service instances of the target microservice includes: Using the preset gateway, select a healthy service instance of the target microservice from the list of available instances as the target service instance.

[0009] On the other hand, after forwarding the remote access request to the target service instance, the method further includes: The token is extracted from the request header of the remote access request using the interceptor of the target microservice, and the token is then used for permission verification. If the permission verification is successful, the target service instance will be used to process the remote access request.

[0010] On the other hand, the task of processing the remote access request using the target service instance includes: During the process of handling the remote access request using the target service instance, if it is necessary to access other microservices, an inter-service call request is generated and sent to the other microservices based on the token in the request header of the remote access request. This allows the other microservices to process the inter-service call request task after the permission verification of the token in the inter-service call request is passed. The inter-service call request includes the token, and the other microservices are preset microservices other than the target microservice.

[0011] On the other hand, the method also includes: When the health service instance of the target microservice is processing the current task, if it needs to access other microservices, a system-level access token is generated based on the registration and allocation information of the target microservice, in the absence of a user context for the current task. The other microservices are preset microservices other than the target microservice, and the registration and allocation information includes the service identifier and encryption key allocated when the target microservice is started, stored in the configuration management center. Based on the system-level access token, an inter-service call request is generated and sent to the other microservices, so that the other microservices can process the task of the inter-service call request after the system-level access token in the inter-service call request passes the permission verification; wherein, the inter-service call request includes the system-level access token, and the other microservices are preset microservices other than the target microservice.

[0012] On the other hand, the method also includes: Using a distributed transaction coordination service, a corresponding target global transaction is registered based on the global transaction registration request sent by the transaction initiator; wherein, the target global transaction includes a global transaction identifier; Before executing the local database operation corresponding to the target global transaction, each participating microservice generates and stores a data snapshot before the operation, and sends a branch transaction registration request to the distributed transaction coordination service to register the branch transaction corresponding to the target global transaction; wherein, the participating microservice is a preset microservice corresponding to the target global transaction; the branch transaction includes a branch transaction identifier; Each participating microservice executes the local database operation corresponding to the target global transaction, and sends the corresponding branch transaction execution result to the distributed transaction coordination service. Using the distributed transaction coordination service, the execution results of all branch transactions corresponding to the target global transaction are aggregated. If the execution results of all branch transactions are successful, all participating microservices are notified to delete their respective pre-operation data snapshots corresponding to the target global transaction. If the execution result of any branch transaction fails, all participating microservices are notified to perform data compensation operations based on their respective pre-operation data snapshots corresponding to the target global transaction, so that the data is restored to its pre-operation state.

[0013] On the other hand, the method also includes: Utilize a distributed transaction coordination service to periodically detect global transactions in progress via asynchronous tasks; If a target branch transaction is detected as having timed out and not completed, the preset microservice corresponding to the target branch transaction will be re-driven to execute the target branch transaction.

[0014] The present invention also provides a service control system for a railway system, comprising: a preset gateway, preset microservices, and a service registration center; wherein each preset microservice is a microservice registered in the service registration center that has an independent data storage and deployment environment based on the business function boundaries of the railway system, and the preset microservice includes at least one of signal monitoring service, wireless transshipment service, and production operation service; the service registration center registers instance information of each preset microservice, and the instance information includes address information and health status information; The preset gateway is used to receive remote access requests initiated by client devices; using a global filter in the preset gateway, it detects whether a valid token exists in the request header of the remote access request; if a valid token exists, it determines the target service instance from the health service instances of the target microservice and forwards the remote access request to the target service instance; wherein, the target microservice is the preset microservice corresponding to the remote access request, and the service registry registers instance information of each preset microservice, the instance information including address information and health status information.

[0015] Furthermore, the present invention also provides a service control device for a railway system, comprising: Memory, used to store computer programs; A processor is used to execute the computer program to implement the steps of the service control method for the railway system as described above.

[0016] The present invention provides a service control method for a railway system, comprising: receiving a remote access request initiated by a client device using a preset gateway; detecting whether a valid token exists in the request header of the remote access request using a global filter in the preset gateway; if a valid token exists, determining a target service instance from the health service instances of the target microservice, and forwarding the remote access request to the target service instance; wherein, the target microservice is a preset microservice corresponding to the remote access request, and each preset microservice is a microservice registered in the service registry that has an independent data storage and deployment environment based on the business function boundaries of the railway system, and the preset microservice includes at least one of signal monitoring service, wireless transshipment service, and production operation service; the service registry registers instance information of each preset microservice, and the instance information includes address information and health status information.

[0017] As can be seen, this invention uses a pre-defined gateway as the unified entry point for all client requests, which can shield the physical address changes of backend microservices and provide a stable unified access point for the frontend. This eliminates the need for the frontend to be concerned with the location of backend microservices, enabling transparent microservice calls and enhancing system security and maintainability. The global filter in the pre-defined gateway enables centralized token verification, avoiding redundant authentication logic implementation in each microservice, reducing code redundancy and security risks, and improving overall authentication efficiency. By registering instance information of each pre-defined microservice through a service registry center and determining the target service instance from the healthy service instances of the target microservice when the token is valid, the invention can perceive the health status of service instances and dynamically route to healthy instances, improving the overall availability and fault tolerance of the system. Furthermore, by setting up microservices with independent data storage and deployment environments based on the business function boundaries of the railway system, deep integration of multiple railway systems at the service layer is achieved. In addition, this invention also provides a service control system and equipment for a railway system, which also has the above-mentioned beneficial effects. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0019] Figure 1 A flowchart illustrating a service control method for a railway system provided in an embodiment of the present invention; Figure 2 This is a schematic diagram of the system architecture of a service control method for a railway system provided in an embodiment of the present invention; Figure 3This is a schematic diagram of a unified login and token issuance process provided in an embodiment of the present invention; Figure 4 This is a schematic diagram of a gateway authentication and routing process provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of a user-triggered chained cross-service call process provided in an embodiment of the present invention; Figure 6 This is a schematic diagram illustrating a cross-service call triggered within a system, as provided in an embodiment of the present invention. Figure 7 A flowchart illustrating a distributed transaction coordination method provided in an embodiment of the present invention; Figure 8 This is a flowchart illustrating another distributed transaction coordination method provided in an embodiment of the present invention; Figure 9 This is a structural block diagram of a service control system for a railway system provided in an embodiment of the present invention; Figure 10 This is a schematic diagram of the structure of a service control device for a railway system provided in an embodiment of the present invention. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0021] Please refer to Figure 1 , Figure 1 A flowchart illustrating a service control method for a railway system provided in an embodiment of the present invention. The method may include: Step 101: Receive remote access requests initiated by client devices using a preset gateway.

[0022] It is understood that the preset gateway in this embodiment (such as...) Figure 2 The unified gateway in this embodiment can serve as a gateway service that acts as a unified entry point for all client requests, receiving various remote access requests initiated by client devices (such as mobile phones or computers). In this embodiment, the remote access request can be initiated by a client device (such as...) Figure 2 Access requests initiated remotely over the network by the front-end client (in the context of the application), such as... Figure 2 HTTP (Hypertext Transfer Protocol) or HTTPS (Hypertext Transfer Secure Protocol) requests.

[0023] Correspondingly, the specific types of remote access requests in this embodiment can be set by the designers according to practical scenarios and user needs. For example, remote access requests may include resource access requests to microservices of various railway business systems (such as signal monitoring systems, wireless transshipment systems, and production operation systems); they may also include login requests, registration requests, and public information query requests (such as verification code acquisition and health check requests). This embodiment does not impose any restrictions on this.

[0024] Step 102: Use the global filter in the preset gateway to check if there is a valid token in the request header of the remote access request; if so, proceed to step 103.

[0025] In this embodiment, the token can be an encrypted string representing the user's legitimate identity. This step utilizes a global filter built into the preset gateway to detect the presence of a valid token in the request header of remote access requests, thereby achieving unified authentication for each preset microservice and ensuring secure access to all microservice resources.

[0026] Correspondingly, the specific method for detecting whether a valid token exists in the request header of a remote access request using the global filter in the preset gateway in this step can be set by the designer according to the use case and user needs. For example, in this step, it can directly detect whether a token with a preset token format exists in the request header of the remote access request; if a token with a preset token format exists, it can check whether the user information corresponding to the token is stored; if the user information corresponding to the token is stored, it is determined that a valid token exists in the request header, and proceed to step 103; if a token with a preset token format does not exist or the user information corresponding to the token is not stored, the process ends or the corresponding response information is returned, such as an "unauthorized" response.

[0027] Accordingly, since remote access requests can include requests that can be accessed without authentication, such as login requests, registration requests, and public information query requests, this embodiment can define a set of interface paths that can be accessed without authentication (i.e., preset whitelist paths), such as login paths, registration paths, and public information query paths. In this step, a global filter can be used to detect whether the interface path of the remote access request is a preset whitelist path; if it is a preset whitelist path, the remote access request is forwarded to the service corresponding to the interface path; wherein, the preset whitelist path includes at least one of the login path, registration path, and public information query path; if it is not a preset whitelist path, it is detected whether a token in a preset token format exists in the request header; if a token in a preset token format exists, it is detected whether user information corresponding to the token exists in the preset distributed cache; if user information corresponding to the token exists, it is determined that there is a valid token in the request header, and proceed to step 103; if no token in a preset token format exists, an unauthorized response information can be returned to the client device; if no user information corresponding to the token exists, the remote access request can be determined to be an illegal request, and the request can be directly discarded.

[0028] It should be noted that the method provided in this embodiment may also include a token issuance process. If the aforementioned preset whitelist path includes a login path, the forwarding of the remote access request to the service corresponding to the interface path may include: if the interface path is a login path, forwarding the remote access request to the authentication and authorization service; using the authentication and authorization service to verify the user login credentials (such as username and password) in the remote access request; after the user login credentials are verified, generating a globally unique token, and storing the generated token and the user information corresponding to the user login credentials in a key-value pair format in a preset distributed cache; wherein, the user information includes at least one of user identifier, role list, affiliated organization, and token validity period; sending the generated token to the client device, so that the client device can subsequently include the token in the request header (such as the Authorization header) of the resource access request.

[0029] For example, such as Figure 3 As shown, users can enter their credentials (such as username and password) on the client device's front-end interface to initiate a login request (POST / login). This request first reaches a preset gateway. The preset gateway routes this request to a login path in a preset whitelist, without performing identity verification, and directly routes it to the authentication and authorization service. The authentication and authorization service verifies the correctness of the user's credentials. If the verification is successful, it generates a globally unique encrypted token, such as a JWT (JSON Web Token, an open standard) format token, and stores the token and corresponding user information in a preset distributed cache as key-value pairs. Figure 3The system caches data in Redis (a data storage method), then returns a token and login success information to the user's client device; if verification fails, it returns the corresponding verification failure information to the user's client device, such as... Figure 3 The 401 Unauthorized message.

[0030] The key-value pair format for storing the Token in the pre-defined distributed cache can be: Key="TOKEN:" + Token string, Value = user information in JSON format (such as user ID, role list, affiliated organization, and validity period). The cache setting is consistent with the Token's validity period (TTL, Time To Live), supporting proactive deletion for immediate account cancellation. In this embodiment, a pre-defined distributed cache is used to store the Token and user information, supporting fast verification and proactive account cancellation.

[0031] Step 103: Determine the target service instance from the health service instances of the target microservice and forward the remote access request to the target service instance.

[0032] The target microservice is the preset microservice corresponding to the remote access request. Each preset microservice is a microservice registered in the service registry that has an independent data storage and deployment environment based on the business function boundary of the railway system. The preset microservice includes at least one of signal monitoring service, wireless transshipment service and production operation service. The service registry registers instance information of each preset microservice. The instance information includes address information and health status information.

[0033] It is understood that the preset microservices in this embodiment can be pre-configured (i.e., pre-registered in the service registry) microservices with independent data storage and deployment environments, based on the business function boundaries of the railway system. For example... Figure 2 As shown, the technical architecture of the method provided in this embodiment can adopt a layered design concept. The access layer can include a unified gateway (i.e., a preset gateway), which serves as the sole entry point for all client requests and is responsible for request routing, identity verification, and access control. The control layer can include a centralized authentication and authorization service for unified management of user identities. The service layer can include multiple independently deployed preset microservices. Each preset microservice is divided based on the business function boundaries of the railway system, has its own independent data storage and operating environment, and provides capabilities to the outside world through standard interfaces. The support layer can include infrastructure components such as a service registration center, a configuration management center, a preset distributed cache (distributed cache), and a database cluster, providing basic support capabilities such as dynamic addressing, hot configuration updates, and health monitoring for upper-layer services.

[0034] Correspondingly, the method provided in this embodiment may also include the registration process of each preset microservice in the service registry. For example, when a service instance of each preset microservice starts up, it can register its own instance information with the service registry, such as service name, address information (e.g., IP action), port number, and health status information. Correspondingly, the method provided in this embodiment may also include the process of the service registry monitoring the health status of each service instance. For example, using the service registry, based on the monitored heartbeat status of each service instance of each preset microservice, service instances with abnormal heartbeat status (i.e., abnormal health status) are deleted from the list of available instances; using a preset gateway, the latest list of available instances is obtained from the service registry at preset time intervals, or the latest list of available instances is pushed to the preset gateway when the list of available instances changes.

[0035] In other words, the process of determining the target service instance from the healthy service instances of the target microservice using the preset gateway in this step can be achieved by using the preset gateway to select one healthy service instance of the target microservice from the list of available instances as the target service instance.

[0036] Furthermore, to address the challenges of scattered configurations and difficulties in updating various pre-defined microservices, this embodiment utilizes a configuration management center to implement a centralized configuration management mechanism. For example, the method provided in this embodiment may further include: storing the configuration parameter set of all pre-defined microservices (such as database connection parameters, on / off parameters, and rate limiting thresholds, etc.) in the configuration management center; when each pre-defined microservice (i.e., a service instance of a pre-defined microservice) starts, it retrieves its initial configuration parameters from the configuration management center; the configuration management center listens for configuration change events, and when a configuration parameter in the configuration parameter set changes, it sends a configuration change notification to the pre-defined microservice corresponding to the target configuration parameter; wherein the target configuration parameter is the changed configuration parameter; after receiving the configuration change notification, each pre-defined microservice obtains and loads its latest configuration parameters from the configuration management center, achieving hot updates of the pre-defined microservices and avoiding invalid restarts. In other words, when a pre-defined microservice service instance starts up, it can automatically register its instance information with the service registry and obtain the initial configuration parameters from the configuration management center. Furthermore, the configuration management center enables hot updates of configuration items, reducing system downtime and improving availability. This allows the pre-defined microservice service instance to dynamically load new configurations or code changes from the configuration management center without stopping service operation.

[0037] In this step, the specific method for determining the target service instance from the healthy service instances of the target microservice (such as service instances of the target microservice in the available instance list) using a preset gateway can be set by the designer. For example, it can select a healthy service instance from the healthy service instances of the target microservice sequentially according to a preset selection order. To ensure load balancing, in this embodiment, the preset gateway can determine the target service instance from the healthy service instances of the target microservice according to a preset load balancing algorithm (such as round-robin, weighted, and minimum connection count). The preset load balancing algorithm can be a strategy used to select a specific call target when multiple healthy service instances exist, such as round-robin, weighted round-robin, minimum connection count, or response time priority strategies, aiming to reasonably distribute request pressure and improve system throughput. For example, after determining each healthy service instance of the target microservice according to preset routing rules (such as path matching and service name mapping), the preset gateway can select the healthy service instance with the minimum number of connections as the target service instance through round-robin.

[0038] Furthermore, to address the risk of cascading failures in high-concurrency scenarios, the method provided in this embodiment may also include a service protection mechanism. For example, this embodiment may set a maximum number of requests per unit time for critical interfaces; when the number of requests received by a critical interface within a unit time reaches the maximum number of requests, subsequent requests are rejected to achieve request rate limiting; wherein, the critical interfaces may include all or some of the interfaces of pre-set service instances. This embodiment may also allocate independent thread pools for different preset microservices to prevent fault propagation and achieve thread isolation. This embodiment may also count the call exception rate of each interface, and automatically circuit breakers will be triggered if the rate exceeds a preset threshold, jumping to the degradation logic; for example, when the call exception rate of a service instance of a preset microservice exceeds the preset threshold, subsequent requests will be automatically interrupted for a period of time to prevent the fault from propagating to the entire call chain, and then gradually allowed to proceed after the service is restored; the degradation logic may be to respond using backup response logic (such as default values ​​or cached data) to ensure the availability of core functions.

[0039] Accordingly, the specific method by which the preset gateway forwards remote access requests to the target service instance in this step can be configured by the designer according to the practical scenario and user needs. For example, the preset gateway can directly forward remote access requests to the target service instance; to facilitate the target service instance's processing of remote access requests, the preset gateway can first add target user information to the request header of the remote access request before sending the remote access request to the target service instance; where the target user information is the user information corresponding to the token in the request header (such as user information stored in the preset distributed cache). Figure 4As shown, after all remote access requests from paths not on the preset whitelist enter the preset gateway, the global filter of the preset gateway can check whether the request header contains a valid token. If there is no token or the format is incorrect, an "unauthorized" response is returned. If a token exists, the preset distributed cache is queried to see if there is a corresponding record. If there is no record in the cache (e.g., the user has logged out), it is determined to be an illegal request. If there is a record in the cache, the verification is confirmed to be successful. The user identifier and permission information (such as role list and organization) carried by the token can be parsed and encapsulated into the request header and forwarded to the target service instance for subsequent use by the target service instance.

[0040] Furthermore, the method provided in this embodiment may also include the processing of remote access requests forwarded by a preset gateway by the target service instance. For example, after step 103, an interceptor (or hook function) of the target microservice can be used to extract a token from the request header of the remote access request and perform permission verification on the token. If the permission verification passes, the target service instance is used to process the remote access request to ensure that only authorized users can access the required resources. The interceptor can be a separate interceptor mechanism for each preset microservice. Alternatively, since the preset gateway has already verified the validity of the token, the target service instance can be directly used to process the remote access request after step 103. This embodiment does not impose any limitations on this.

[0041] In other embodiments, after step 103, if the remote access request is sent by a preset gateway, the target service instance is used to process the remote access request task; if the remote access request is sent by another preset microservice, the interceptor of the target microservice is used to extract the token from the request header of the remote access request and to verify the token's permissions; if the permission verification is successful, the target service instance is used to process the remote access request task.

[0042] like Figure 2 As shown, the preset gateway (unified gateway) serves as an intermediate proxy service for the unified entry point of the microservice cluster, encompassing all preset microservices. It is responsible for receiving requests from all client devices and performing common functions such as routing, authentication, access control, rate limiting, and degradation. Front-end applications on client devices only need to interact with the preset gateway and do not need to be aware of the specific deployment location of the back-end microservices.

[0043] Pre-defined microservices (the services in the service layer) can be an architectural pattern for splitting a large monolithic application into multiple small, independent, and autonomous service units according to business boundaries. Each pre-defined microservice has its own codebase, database, runtime environment, and release cycle, focuses on completing a single business responsibility, and communicates through lightweight protocols (such as HTTP).

[0044] The service registry provides a dynamic directory service for centrally managing the network location and running status of service instances of various pre-defined microservices. Each pre-defined microservice automatically registers its own instance information upon startup and periodically sends heartbeats to report its health status. Service consumers can query the list of available instances through the registry to achieve service discovery and dynamic addressing.

[0045] The configuration management center can be used for service modules to centrally store and manage common configuration parameters of various microservices (such as database connection, switch flags, and rate limiting thresholds); it supports dynamic updates and real-time push of configurations, enabling preset microservices to load the latest configurations without restarting, thus improving operational efficiency.

[0046] In this embodiment, the present invention uses a preset gateway as the unified entry point for all client requests. This can shield the physical address changes of backend microservices, providing a stable unified access point for the frontend. This eliminates the need for the frontend to be aware of the location of backend microservices, enabling transparent microservice calls and enhancing system security and maintainability. The global filter in the preset gateway enables centralized token verification, avoiding redundant authentication logic implementation in each microservice, reducing code redundancy and security risks, and improving overall authentication efficiency. By registering instance information of each preset microservice through a service registry, and determining the target service instance from the healthy service instances of the target microservice when the token is valid, the system can perceive the health status of service instances and dynamically route to healthy instances, improving the overall availability and fault tolerance of the system. Furthermore, by setting up microservices with independent data storage and deployment environments based on the business function boundaries of the railway system, deep integration of multiple railway systems at the service layer is achieved.

[0047] Based on the above embodiments, this invention also provides a method for handling inter-service calls to achieve secure and efficient cross-service calls. As described above, in the process of handling remote access requests using a target service instance, if access to other microservices is required, an inter-service call request is generated and sent to the other microservices based on the token in the request header of the remote access request. This ensures that the other microservices process the inter-service call request task after the token's permission verification in the inter-service call request is successful. The inter-service call request includes a token, and the other microservices are preset microservices other than the target microservice.

[0048] For example, consider a scenario where a client device sends an HTTP request (i.e., a remote access request) carrying a token to access a resource and initiates a remote call; such as... Figure 5As shown, a user initiates an HTTP request containing a token (such as a JWT token) through the application on the client device to access microservice A. If a valid token is detected in the HTTP request header by a pre-defined gateway, the request is forwarded to the target service instance of microservice A. If the target service instance needs to call microservice B to handle the task requested, the user context is automatically extracted from the request header by the interceptor of microservice A and appended to the remote call request to microservice B. Microservice A uses a declarative remote call approach, converting the call to microservice B into an HTTP request (i.e., an inter-service call request) according to a predefined RESTful (Representation Layer State Transfer) interface contract, and automatically adds the user context to the request header. After receiving the request, microservice B extracts the user context through its built-in interceptor for permission checks or logging, ensuring that only authorized users can access the required resources. Then, microservice B processes the request and returns the result to microservice A. Microservice A then returns the integrated result to the application on the client device, completing the entire request process. Declarative remote invocation can be a programming model that simplifies communication between services. Developers only need to define local interfaces to describe remote service methods, and the system automatically converts them into HTTP requests and handles the serialization and deserialization process, reducing the complexity of remote invocation.

[0049] In other embodiments, during the process of handling remote access requests using the target service instance, if access to other microservices is required, a system-level access token can be generated based on the registration and allocation information of the target microservice. An inter-service call request is then generated and sent to the other microservices based on the system-level access token, so that the other microservices can process the inter-service call request task after the system-level access token in the inter-service call request passes the permission verification. Here, the other microservices are preset microservices other than the target microservice, and the registration and allocation information includes the service identifier and encryption key allocated when the target microservice starts, stored in the configuration management center. The inter-service call request includes a system-level access token, and the other microservices are preset microservices other than the target microservice.

[0050] Based on the above embodiments, this invention also provides another method for handling inter-service calls, so as to achieve secure and efficient cross-service calls in the absence of user context (such as service calls triggered by scheduled tasks).

[0051] For example, when the health service instance of the target microservice is processing the current task, if it needs to access other microservices, then, without a user context for the current task, a system-level access token is generated based on the registration and allocation information of the target microservice. Based on the system-level access token, an inter-service call request is generated and sent to the other microservices. This ensures that the other microservices process the inter-service call request task only after their system-level access token in the inter-service call request passes permission verification. Here, the other microservices are preset microservices other than the target microservice, and their registration and allocation information includes the service identifier and encryption key allocated when the target microservice starts, stored in the configuration management center. The inter-service call request includes the system-level access token, and the other microservices are preset microservices other than the target microservice.

[0052] Correspondingly, the system token in this embodiment can be a short-term valid identity credential generated by the microservice itself, such as an identity credential generated in scenarios without user context (e.g., scheduled tasks and internal scheduling). This token is generated based on the service's own identity identifier (i.e., Service ID) and encryption key, and may include the initiating service identifier (e.g., the target microservice's service identifier), the target service identifier (e.g., other microservices' service identifiers), validity period, and digital signature. It is used for authentication during inter-service calls, ensuring the security and auditability of system-level calls. The user context in this embodiment can be the user identity information in the request, such as the token and user identifier. In this embodiment, during the microservice chained call process, a mechanism automatically appends the user context (e.g., the token) or system token from the original request (e.g., a remote access request) to the downstream service request header, realizing the transfer of remote call context and ensuring the continuity of the permission chain and the integrity of audit information.

[0053] For example, such as Figure 6As shown, each pre-defined microservice is assigned service identity credentials upon registration, such as a unique service ID and an encryption key (e.g., a shared key or asymmetric key pair). These service identity credentials are securely stored by the configuration management center and distributed via an encrypted channel when the pre-defined microservice starts; plaintext storage or hardcoding in the code is prohibited. When microservice A is processing its current task (e.g., a scheduled task) and needs to call microservice B, in the absence of user context (e.g., a token), microservice A generates a short-lived, valid system-level access token (System Token) using its own Service ID and encryption key, following a standard encryption algorithm. This System Token can use the JWT standard format and may include iss (issuer), sub (target service), exp (expiration time), aud (audience), and custom permission statements. It is signed using HMAC (Hash Message Authentication Code) with the service identity key, and the recipient verifies the signature validity using the shared key. Before initiating an HTTP request (i.e., an inter-service call request) to microservice B, service A writes the generated System Token into the Authorization field of the request header, in the format Bearer. <system-token>Then, an HTTP request is sent to microservice B. After receiving the request, microservice B verifies the validity of the token through a preset gateway or local interceptor, including parsing the token, verifying the signature, checking the expiration status, and confirming whether the initiator has the right to access the current interface. After confirming that the verification is successful, the task of processing the request is completed.

[0054] Based on the above embodiments, to ensure data consistency across service operations, this embodiment of the invention also provides a quasi-two-phase commit transaction coordination process based on compensation logs. For details, please refer to... Figure 7 , Figure 7 A flowchart illustrating a distributed transaction coordination method provided in an embodiment of the present invention. The method may include: Step 201: Using the distributed transaction coordination service, register the corresponding target global transaction based on the global transaction registration request sent by the transaction initiator.

[0055] The target global transaction includes a global transaction identifier (XID).

[0056] It is understood that the distributed transaction coordination service in this embodiment can be a central coordination component responsible for managing the global transaction lifecycle across multiple microservice operations, such as... Figure 2 The distributed transaction coordination service is the coordinator in the context of transactions. It maintains the state of global and branch transactions, drives the two-phase commit process, and makes a unified decision to commit or rollback after all participants (i.e., participating microservices) are ready, ensuring eventual data consistency.

[0057] Correspondingly, in this embodiment, the transaction initiator can be a terminal device (such as a client device) or a service (such as a preset microservice) that initiates cross-service operations; the target global transaction in this embodiment can be a global transaction corresponding to a global transaction registration request.

[0058] Step 202: Before each participating microservice performs local database operations corresponding to the target global transaction, it generates and stores a snapshot of the data before the operation, and sends a branch transaction registration request to the distributed transaction coordination service to register the branch transaction corresponding to the target global transaction.

[0059] Among them, the participating microservice is the preset microservice (i.e., the service instance of the preset microservice) corresponding to the target global transaction; the branch transaction includes the branch transaction identifier.

[0060] Correspondingly, in this embodiment, the participating microservices can be preset microservices (i.e., service instances) that participate in the target global transaction. This step involves each participating microservice generating and storing a data snapshot (Undo Log) before executing the local database operation corresponding to the target global transaction. This allows each participating microservice to perform compensation operations based on the Undo Log and restore the original state when the local branch transaction (i.e., local transaction) or the target global transaction fails.

[0061] Furthermore, in this step, each participating microservice can store its pre-operation data snapshot in a separate log table (such as a transaction log table). Since the Undo Log is written to a separate transaction log table during the branch transaction registration phase and stored separately from the business data table, it ensures that even if a failure occurs after the local transaction is committed, recovery and compensation operations can still be performed through the log.

[0062] Step 203: Utilize the local database operations corresponding to the target global transaction executed by each participating microservice, and send the corresponding branch transaction execution results to the distributed transaction coordination service.

[0063] Step 204: Use the distributed transaction coordination service to summarize the execution results of all branch transactions corresponding to the target global transaction; if the execution results of all branch transactions are successful, notify all participating microservices to delete the data snapshots of the target global transaction before the operation that they stored.

[0064] Correspondingly, in this embodiment, after summarizing the execution results of all branch transactions corresponding to the target global transaction using the distributed transaction coordination service, the distributed transaction coordination service can be used to notify all participating microservices to perform data compensation operations based on the pre-operation data snapshots of the target global transaction stored by themselves when the execution result of any branch transaction fails, so as to restore the data to the pre-operation state.

[0065] Furthermore, the method provided in this embodiment may also include a periodic detection process for global transactions by a distributed transaction coordination service. For example, the distributed transaction coordination service can be used to periodically detect global transactions in progress through asynchronous tasks. If a target branch transaction that has timed out and failed to complete is detected, the preset microservice (i.e., service instance) corresponding to the target branch transaction is re-driven to execute the target branch transaction. In other words, the distributed transaction coordination service can periodically scan global transactions in progress through asynchronous tasks, drive timeout or failed branches to complete the final state cleanup, and ensure the eventual consistency of the system.

[0066] For example. Figure 8 As shown, when the transaction initiator starts a global transaction, it sends a global transaction registration request to the distributed transaction coordination service, notifying the service to register a global transaction ID (XID). Each participating service (i.e., participating microservice) registers its corresponding branch transaction with the distributed transaction coordination service before executing local database operations. Each participating microservice generates a data snapshot (Undo Log) before executing local database operations (such as Structured Query Language SQL) within its branch transaction and records it in a separate transaction log table. Each participating microservice executes its local database operations and immediately commits its local transaction, then reports its execution status (i.e., the branch transaction execution result), whether successful or not. The distributed transaction coordination service summarizes the execution results of all branch transactions: if all are successful, it sends a commit confirmation command, controlling each participating microservice to delete the Undo Log; if any branch transaction fails, it sends a rollback command, controlling each participating microservice to restore data based on the Undo Log. The coordinator cleans up the global transaction record. The distributed transaction coordination service cleans up the global transaction record. If a participating microservice crashes and becomes unresponsive, the distributed transaction coordination service uses a periodic scanning mechanism to detect incomplete transactions and restarts the compensation process.

[0067] Corresponding to the above method embodiments, this invention also provides a service control system for a railway system. The service control system for a railway system described below and the service control method for a railway system described above can be referred to in correspondence.

[0068] Please refer to Figure 9 , Figure 9 This is a structural block diagram of a service control system for a railway system provided in an embodiment of the present invention. The system may include: a preset gateway 10, preset microservices 20, and a service registration center 30; wherein each preset microservice 20 is a microservice registered in the service registration center 30, defined based on the business function boundaries of the railway system, and possessing an independent data storage and deployment environment. Each preset microservice 20 includes at least one of signal monitoring service, wireless transshipment service, and production operation service; the service registration center 30 registers instance information for each preset microservice 20, including address information and health status information. The preset gateway 10 is used to receive remote access requests initiated by client devices. The global filter in the preset gateway 10 is used to check whether there is a valid token in the request header of the remote access request. If there is a valid token, the target service instance is determined from the health service instances of the target microservice and the remote access request is forwarded to the target service instance. The target microservice is the preset microservice 20 corresponding to the remote access request. The service registry 30 registers the instance information of each preset microservice 20. The instance information includes address information and health status information.

[0069] In some embodiments, using a global filter in the preset gateway 10 to detect whether a valid token exists in the request header of a remote access request may include: Use a global filter to detect whether the interface path of the remote access request is a preset whitelist path; If a preset whitelist path is used, the remote access request will be forwarded to the service corresponding to the interface path; the preset whitelist path includes at least one of the login path, registration path, and public information query path. If the path is not a pre-defined whitelist path, check if a token with a pre-defined token format exists in the request header; If a token with a preset token format exists, check if the user information corresponding to the token exists in the preset distributed cache; If user information corresponding to the token exists, then it is determined that there is a valid token in the request header, and the steps of determining the target service instance from the health service instances of the target microservice and forwarding the remote access request to the target service instance are executed.

[0070] In some embodiments, the preset whitelist path includes a login path, and forwarding remote access requests to the service corresponding to the interface path may include: If the interface path is the login path, the remote access request will be forwarded to the authentication and authorization service; Use the authentication and authorization service to verify the user's login credentials in the remote access request; After the user's login credentials are verified, a globally unique token is generated. The generated token and the user information corresponding to the user's login credentials are stored in a preset distributed cache in the form of key-value pairs. The user information includes at least one of the following: user identifier, role list, organization, and token validity period. The generated token is sent to the client device.

[0071] In some embodiments, forwarding a remote access request to a target service instance may include: After adding the target user information to the request header of the remote access request, the remote access request is sent to the target service instance; where the target user information is the user information corresponding to the token in the request header.

[0072] In some embodiments, the service registry 30 can also be used to remove service instances with abnormal heartbeat states from the list of available instances based on the heartbeat states of each service instance of each preset microservice 20 as monitored. The default gateway 10 can also be used to retrieve the latest list of available instances from the service registry 30 at default time intervals; The target service instance is determined from the health service instances of the target microservice, including: Using the default gateway 10, select a healthy service instance of the target microservice from the list of available instances as the target service instance.

[0073] In some embodiments, determining the target service instance from the health service instances of the target microservice includes: The target service instance is determined from the healthy service instances of the target microservice according to the preset load balancing algorithm.

[0074] In some embodiments, the target service instance can also be used to extract a token from the request header of the remote access request using the interceptor of the target microservice, and to perform permission verification on the token; if the permission verification is successful, the task of processing the remote access request is then performed.

[0075] In some embodiments, the target service instance is specifically used to generate and send an inter-service call request to other microservices if it needs to access other microservices during the task of processing remote access requests, based on the token in the request header of the remote access request, so that the other microservices can process the task of inter-service call request after the permission verification of the token in the inter-service call request is passed; wherein, the inter-service call request includes a token, and the other microservices are preset microservices 20 other than the target microservice.

[0076] In some embodiments, when a health service instance of a target microservice needs to access other microservices while processing its current task, it generates a system-level access token based on the registration and allocation information of the target microservice, provided that the current task has no user context. It then generates and sends an inter-service call request to the other microservice based on the system-level access token, so that the other microservices can process the task of the inter-service call request after the system-level access token in the inter-service call request passes the permission verification. The other microservices are preset microservices 20 other than the target microservice, and the registration and allocation information includes the service identifier and encryption key allocated when the target microservice starts, stored in the configuration management center. The inter-service call request includes a system-level access token, and the other microservices are preset microservices 20 other than the target microservice.

[0077] In some embodiments, the system may further include: The configuration management center stores the configuration parameter sets of all preset microservices 20; it listens for configuration change events, and when a configuration parameter in the configuration parameter set changes, it sends a configuration change notification to the preset microservice 20 corresponding to the target configuration parameter; where the target configuration parameter is the configuration parameter that has changed. Each pre-defined microservice 20 is used to pull its initial configuration parameters from the configuration management center at startup; and to obtain and load its latest configuration parameters from the configuration management center after receiving a configuration change notification.

[0078] In some embodiments, the system may further include: The distributed transaction coordination service is used to register the corresponding target global transaction based on the global transaction registration request sent by the transaction initiator; to summarize the execution results of all branch transactions corresponding to the target global transaction; and if the execution results of all branch transactions are successful, to notify all participating microservices to delete the data snapshots of the target global transaction before the operation that they have stored; wherein, the target global transaction includes a global transaction identifier. Correspondingly, each participating microservice is responsible for generating and storing a snapshot of the data before the execution of the local database operation corresponding to the target global transaction, and sending a branch transaction registration request to the distributed transaction coordination service to register the branch transaction corresponding to the target global transaction; executing the local database operation corresponding to the target global transaction, and sending the corresponding branch transaction execution result to the distributed transaction coordination service; wherein, the participating microservice is the preset microservice 20 corresponding to the target global transaction; the branch transaction includes a branch transaction identifier.

[0079] In some embodiments, the distributed transaction coordination service is also used to notify all participating microservices to perform data compensation operations based on the pre-operation data snapshots corresponding to the target global transaction stored by each microservice when the execution result of any branch transaction of a branch transaction fails, so as to restore the data to the pre-operation state.

[0080] In some embodiments, the distributed transaction coordination service is also used to periodically detect global transactions in progress through asynchronous tasks; if a target branch transaction that has timed out is detected, the preset microservice 20 corresponding to the target branch transaction is re-driven to execute the target branch transaction.

[0081] In this embodiment, the present invention uses a preset gateway 10 as a unified entry point for all client requests. This can shield the physical address changes of backend microservices, providing a stable unified access point for the frontend. This eliminates the need for the frontend to be concerned with the location of backend microservices, enabling transparent microservice calls and enhancing system security and maintainability. The global filter in the preset gateway 10 is used to centrally verify tokens, avoiding the duplication of authentication logic by each microservice, reducing code redundancy and security risks, and improving overall authentication efficiency. The instance information of each preset microservice 20 is registered through the service registry 30, and the target service instance is determined from the healthy service instances of the target microservice when the token is valid. This allows the system to perceive the health status of service instances and dynamically route to healthy instances, improving the overall availability and fault tolerance of the system. Furthermore, through the microservice settings with independent data storage and deployment environments based on the business function boundaries of the railway system, deep integration of multiple railway systems at the service layer is achieved.

[0082] Corresponding to the above method embodiments, this invention also provides a service control device for a railway system. The service control device for a railway system described below and the service control method for a railway system described above can be referred to in correspondence.

[0083] Please refer to Figure 10 , Figure 10 This is a schematic diagram of the structure of a service control device for a railway system provided in an embodiment of the present invention. The server may include: Memory D1 is used to store computer programs; Processor D2 is used to execute computer programs to implement the steps of the service control method for the railway system provided in the above-described method embodiments.

[0084] In this embodiment, the service control equipment for the railway system can be specifically a server. For example, the server can run a system that deeply integrates multiple professional railway management systems (such as signal monitoring systems, dispatching and command systems, and wireless data conversion systems) based on a microservice architecture.

[0085] Corresponding to the above method embodiments, this invention also provides a computer program product. The computer program product described below can be referred to in correspondence with the service control method for a railway system described above.

[0086] A computer program product includes a computer program / instructions that, when executed by a processor, implement the steps of the service control method for a railway system provided in the above-described method embodiments.

[0087] Corresponding to the above method embodiments, this invention also provides a computer-readable storage medium. The computer-readable storage medium described below can be referred to in conjunction with the service control method for a railway system described above.

[0088] A computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of the service control method for a railway system provided in the above-described method embodiments.

[0089] The computer-readable storage medium can specifically be a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other readable storage medium capable of storing program code.

[0090] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems, devices, computer program products, and computer-readable storage media disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple, and relevant details can be found in the method section.

[0091] The above provides a detailed description of the service control method, system, and equipment for a railway system provided by the present invention. Specific examples have been used to illustrate the principles and implementation methods of the invention. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and core ideas of the present invention. It should be noted that those skilled in the art can make various improvements and modifications to the present invention without departing from its principles, and these improvements and modifications also fall within the protection scope of the present invention.

Claims

1. A service control method for a railway system, characterized in that, include: Using a preset gateway, remote access requests initiated by client devices are received; The global filter in the preset gateway is used to detect whether a valid token exists in the request header of the remote access request; If a valid token exists, the target service instance is determined from the health service instances of the target microservice, and the remote access request is forwarded to the target service instance; wherein, the target microservice is the preset microservice corresponding to the remote access request, and each preset microservice is a microservice registered in the service registry that has an independent data storage and deployment environment based on the business function boundary of the railway system, and the preset microservice includes at least one of signal monitoring service, wireless changing service and production operation service; The service registry registers instance information for each of the preset microservices, and the instance information includes address information and health status information.

2. The service control method for a railway system according to claim 1, characterized in that, The step of using the global filter in the preset gateway to detect whether a valid token exists in the request header of the remote access request includes: The global filter is used to detect whether the interface path of the remote access request is a preset whitelist path; If the path is a preset whitelist path, the remote access request is forwarded to the service corresponding to the interface path; wherein, the preset whitelist path includes at least one of the login path, registration path, and public information query path; If the path is not in the preset whitelist, then check if a token with a preset token format exists in the request header; If a token with the preset token format exists, then check if the user information corresponding to the token exists in the preset distributed cache; If user information corresponding to the token exists, then it is determined that a valid token exists in the request header, and the steps of determining the target service instance from the health service instances of the target microservice and forwarding the remote access request to the target service instance are executed.

3. The service control method for a railway system according to claim 2, characterized in that, The preset whitelist path includes the login path, and forwarding the remote access request to the service corresponding to the interface path includes: If the interface path is the login path, then the remote access request will be forwarded to the authentication and authorization service; The authentication and authorization service is used to verify the user login credentials in the remote access request; After the user login credentials are verified, a globally unique token is generated, and the generated token and the user information corresponding to the user login credentials are stored in the preset distributed cache in the form of key-value pairs; wherein, the user information includes at least one of user identifier, role list, organization, and token validity period; The generated token is sent to the client device.

4. The service control method for a railway system according to claim 1, characterized in that, After forwarding the remote access request to the target service instance, the method further includes: The token is extracted from the request header of the remote access request using the interceptor of the target microservice, and the token is then used for permission verification. If the permission verification is successful, the target service instance will be used to process the remote access request.

5. The service control method for a railway system according to claim 4, characterized in that, The task of processing the remote access request using the target service instance includes: During the process of handling the remote access request using the target service instance, if it is necessary to access other microservices, an inter-service call request is generated and sent to the other microservices based on the token in the request header of the remote access request. This allows the other microservices to process the inter-service call request task after the permission verification of the token in the inter-service call request is passed. The inter-service call request includes the token, and the other microservices are preset microservices other than the target microservice.

6. The service control method for a railway system according to claim 1, characterized in that, Also includes: When the health service instance of the target microservice is processing the current task, if it needs to access other microservices, a system-level access token is generated based on the registration and allocation information of the target microservice, in the absence of a user context for the current task. The other microservices are preset microservices other than the target microservice, and the registration and allocation information includes the service identifier and encryption key allocated when the target microservice is started, stored in the configuration management center. Based on the system-level access token, an inter-service call request is generated and sent to the other microservices, so that the other microservices can process the task of the inter-service call request after the system-level access token in the inter-service call request passes the permission verification; wherein, the inter-service call request includes the system-level access token, and the other microservices are preset microservices other than the target microservice.

7. The service control method for a railway system according to any one of claims 1 to 6, characterized in that, Also includes: Using a distributed transaction coordination service, a corresponding target global transaction is registered based on the global transaction registration request sent by the transaction initiator; wherein, the target global transaction includes a global transaction identifier; Before executing the local database operation corresponding to the target global transaction, each participating microservice generates and stores a data snapshot before the operation, and sends a branch transaction registration request to the distributed transaction coordination service to register the branch transaction corresponding to the target global transaction; wherein, the participating microservice is a preset microservice corresponding to the target global transaction; the branch transaction includes a branch transaction identifier; Each participating microservice executes the local database operation corresponding to the target global transaction, and sends the corresponding branch transaction execution result to the distributed transaction coordination service. Using the distributed transaction coordination service, the execution results of all branch transactions corresponding to the target global transaction are aggregated. If the execution results of all branch transactions are successful, all participating microservices are notified to delete their respective pre-operation data snapshots corresponding to the target global transaction. If the execution result of any branch transaction fails, all participating microservices are notified to perform data compensation operations based on their respective pre-operation data snapshots corresponding to the target global transaction, so that the data is restored to its pre-operation state.

8. The service control method for a railway system according to claim 7, characterized in that, Also includes: Utilize a distributed transaction coordination service to periodically detect global transactions in progress via asynchronous tasks; If a target branch transaction is detected as having timed out and not completed, the preset microservice corresponding to the target branch transaction will be re-driven to execute the target branch transaction.

9. A service control system for a railway system, characterized in that, include: The system includes a preset gateway, preset microservices, and a service registry center. Each preset microservice is a microservice registered in the service registry center that has an independent data storage and deployment environment based on the business function boundaries of the railway system. The preset microservices include at least one of signal monitoring service, wireless transshipment service, and production operation service. The service registry center registers instance information for each preset microservice, and the instance information includes address information and health status information. The preset gateway is used to receive remote access requests initiated by client devices; using a global filter in the preset gateway, it detects whether a valid token exists in the request header of the remote access request; if a valid token exists, it determines the target service instance from the health service instances of the target microservice and forwards the remote access request to the target service instance; wherein, the target microservice is the preset microservice corresponding to the remote access request, and the service registry registers instance information of each preset microservice, the instance information including address information and health status information.

10. A service control device for a railway system, characterized in that, include: Memory, used to store computer programs; A processor for executing the computer program to implement the steps of the service control method for a railway system as described in any one of claims 1 to 8.

Images