A method and device for managing a service system

By building the exception code mapping relationship in the service system, the complex problem of scene call exception handling in software microservice development is solved, and the effect of reducing the amount of code changes and shortening the iteration cycle is achieved.

CN114546475BActive Publication Date: 2025-03-18JINGDONG TECH HLDG CO LTD
View PDF 2 Cites 0 Cited by

Patent Information

Application Number
CN202210181699.0
Authority / Receiving Office
CN · China
Patent Type
Patents(China)
Current Assignee / Owner
Filing Date
2022-02-25
Publication Date
2025-03-18
Estimated Expiration
2042-02-25

AI Technical Summary

Technical Problem

During the development of software microservices, the business link involves multiple service calls, which leads to the need for developers to modify the relevant business code when a scene call exception occurs, resulting in large amounts of code changes and long iteration cycles.

Method used

By building a mapping relationship between the exception codes of upstream and downstream services, the scene call exception is handled directly by adding or modifying the nodes in the mapping relationship without modifying the business code of upstream and downstream services.

Benefits of technology

It reduces the amount of code changes, shortens the iteration cycle, improves development efficiency, and facilitates query and maintenance by storing mapping relationships in the database, improving the timeliness of the system.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN114546475B_ABST
    Figure CN114546475B_ABST
Patent Text Reader

Abstract

The present invention discloses a method and device for service system management, and relates to the field of computers. A specific implementation of the method includes: receiving a management request, the management request indicates a service to be managed and a management type in a service system; in response to the management type being a newly added type, determining a first exception code of the service to be managed, and an upstream service to be managed and a second exception code of the upstream service that can be called; determining a system code segment corresponding to the service to be managed, the number of exception codes corresponding to the system code segment being greater than or equal to the number of second exception codes; determining a system exception code corresponding to the service to be managed from the system code segment, the number of system exception codes being less than or equal to the number of first exception codes; and constructing a mapping relationship between the system exception code, the first exception code, and the second exception code according to the corresponding relationship between the system code segment and the second exception code, to respond to the management request. This implementation avoids code modification and improves development efficiency by establishing a mapping relationship.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method and device for managing a service system. Background Art

[0002] In the process of software microservice development, a business link often involves multiple service calls. When call exceptions occur in different scenarios, the exception code corresponding to the scenario will be used to identify the call exception.

[0003] At present, when a new scenario call exception occurs, developers usually need to modify the relevant business code to add the exception code of the corresponding scenario. Since the business chain involves multiple service calls, when the exception code in the business code of the downstream service is modified, the upstream service that calls the downstream service also needs to make code changes accordingly. As a result, there are many links involved in the changes, the amount of code changes is large, and the iteration cycle is long. Summary of the invention

[0004] In view of this, an embodiment of the present invention provides a method and device for service system management, which can construct a mapping relationship between the exception codes of upstream and downstream services. Therefore, when it comes to adding or modifying scene call exceptions, it can be achieved directly by adding nodes in the mapping relationship or modifying the mapping relationship, without having to modify the business codes of the upstream and downstream services respectively, thereby reducing the amount of code changes, shortening the iteration cycle, and improving development efficiency.

[0005] Furthermore, by storing the mapping relationship in the database, the corresponding relationship of the exception codes in the system can be easily queried and maintained, which reduces the difficulty of system maintenance and improves development efficiency. The mapping relationship is pushed to the system memory in real time, so that the newly added or modified exception codes take effect in real time, improving the timeliness of the system.

[0006] To achieve the above object, according to a first aspect of an embodiment of the present invention, a method for managing a service system is provided, comprising:

[0007] receiving a management request, wherein the management request indicates a service to be managed and a management type in the service system;

[0008] In response to the management type being a newly added type, determining one or more first exception codes of the service to be managed, and an upstream service that can call the service to be managed and one or more second exception codes of the upstream service;

[0009] Determine a system code segment corresponding to the service to be managed, wherein the number of exception codes corresponding to the system code segment is greater than or equal to the number of the second exception codes;

[0010] Determine one or more system exception codes corresponding to the service to be managed from the system code segment, where the number of the system exception codes is less than or equal to the number of the first exception codes;

[0011] According to the corresponding relationship between the system code segment and the second exception code, a mapping relationship among the system exception code, the first exception code and the second exception code is constructed to respond to the management request.

[0012] Optionally, the method further comprises:

[0013] receiving a call request, wherein the call request indicates a service to be called;

[0014] Determine the target exception code corresponding to the service to be called;

[0015] Determine the upstream exception code of the upstream service of the service to be called according to the mapping relationship;

[0016] The upstream exception code is converted into a natural language description, and the natural language description is output to the upstream service.

[0017] Optionally, the method further comprises:

[0018] In response to the management type being a modification type, the management request indicates a modification relationship, and according to the modification relationship, at least one of the following steps is performed: a step of modifying the correspondence between the first exception code and the system exception code in the mapping relationship, and a step of modifying the correspondence between the system exception code and the second exception code in the mapping relationship.

[0019] Optionally, after constructing a mapping relationship between the system exception code, the first exception code, and the second exception code, the method further includes:

[0020] The mapping relationship is stored in a database and pushed to the service system memory in real time.

[0021] Optionally, the system code segments corresponding to different services to be managed do not have overlapping code segments.

[0022] Optionally, the correspondence between different services and independent domains includes any one or both of the following:

[0023] Different services to be managed correspond to different independent domains isolated from each other, and different upstream services correspond to different independent domains isolated from each other.

[0024] According to a second aspect of an embodiment of the present invention, a device for service system management is provided, comprising: a receiving module, a determining module and a building module; wherein:

[0025] The receiving module is used to receive a management request, where the management request indicates the service to be managed and the management type in the service system;

[0026] The determination module is used to determine, in response to the management type being a newly added type, one or more first exception codes of the service to be managed, and an upstream service that can call the service to be managed and one or more second exception codes of the upstream service; determine a system code segment corresponding to the service to be managed, the number of exception codes corresponding to the system code segment is greater than or equal to the number of the second exception codes; determine one or more system exception codes corresponding to the service to be managed from the system code segment, the number of the system exception codes is less than or equal to the number of the first exception codes;

[0027] The construction module is used to construct a mapping relationship between the system exception code, the first exception code and the second exception code according to the corresponding relationship between the system code segment and the second exception code, so as to respond to the management request.

[0028] Optionally, the device further comprises:

[0029] A calling module is used to receive a calling request, wherein the calling request indicates a service to be called; determine a target exception code corresponding to the service to be called; determine an upstream exception code of an upstream service of the service to be called based on a mapping relationship; convert the upstream exception code into a natural language description, and output the natural language description to the upstream service.

[0030] According to a third aspect of an embodiment of the present invention, there is provided an electronic device, including:

[0031] one or more processors;

[0032] a storage device for storing one or more programs,

[0033] When the one or more programs are executed by the one or more processors, the one or more processors implement any method described in the method for managing a service system provided in the first aspect above.

[0034] According to a fourth aspect of an embodiment of the present invention, a computer-readable medium is provided, on which a computer program is stored. When the program is executed by a processor, any method in the method for managing a service system provided in the first aspect is implemented.

[0035] An embodiment of the above invention has the following advantages or beneficial effects: it is able to construct a mapping relationship between the exception codes of upstream and downstream services. Therefore, when it comes to adding or modifying scenario call exceptions, it can be achieved directly by adding nodes in the mapping relationship or modifying the mapping relationship, without having to modify the business codes of the upstream and downstream services separately, thereby reducing the amount of code changes, shortening the iteration cycle, and improving development efficiency.

[0036] Furthermore, by storing the mapping relationship in the database, the corresponding relationship of the exception codes in the system can be easily queried and maintained, which reduces the difficulty of system maintenance and improves development efficiency. The mapping relationship is pushed to the system memory in real time, so that the newly added or modified exception codes take effect in real time, thereby improving the effectiveness of the system.

[0037] The further effects of the above-mentioned non-conventional optional manner will be described below in conjunction with specific implementation examples. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The accompanying drawings are used to better understand the present invention and do not constitute an improper limitation of the present invention.

[0039] Figure 1 It is a flow chart of a method for service system management provided by an embodiment of the present invention;

[0040] Figure 2 It is a flowchart of another method for service system management provided by an embodiment of the present invention;

[0041] Figure 3 This is a schematic diagram of an abnormal code mapping relationship of a service system provided by an embodiment of the present invention;

[0042] Figure 4 It is a schematic diagram of a device structure for service system management provided by an embodiment of the present invention;

[0043] Figure 5 is an exemplary system architecture diagram to which embodiments of the present invention may be applied;

[0044] Figure 6 It is a schematic diagram of the structure of a computer system of a terminal device or a server suitable for implementing an embodiment of the present invention. DETAILED DESCRIPTION

[0045] The following is a description of exemplary embodiments of the present invention in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to facilitate understanding, which should be considered as merely exemplary. Therefore, it should be recognized by those of ordinary skill in the art that various changes and modifications may be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and conciseness, the description of well-known functions and structures is omitted in the following description.

[0046] It should be pointed out that the embodiments of the present invention and the technical features therein may be combined with each other without conflict.

[0047] like Figure 1 As shown, an embodiment of the present invention provides a method for managing a service system, which may include the following steps:

[0048] Step S101: receiving a management request, wherein the management request indicates a service to be managed and a management type in the service system. In response to the management type being a newly added type, step S102 is triggered.

[0049] It is understandable that in a service system, calls between multiple services are often involved, and the interface output of the downstream service can usually be used as the input of the upstream service. Changes to the interface output of the downstream service will affect the upstream service. In one embodiment of the present invention, when managing the service system, the service to be managed can be called a downstream service, and the service that calls the service to be managed can be called an upstream service.

[0050] In a service system, it may be necessary to add a service to be managed according to a business scenario and manage the service to be managed; or modify the service system according to a modification request of a business scenario. Therefore, in an embodiment of the present invention, the management type in the management request can be a new type and a modification type.

[0051] Step S102: determining one or more first exception codes of the service to be managed, and an upstream service that can call the service to be managed and one or more second exception codes of the upstream service.

[0052] Step S103: determining a system code segment corresponding to the service to be managed, wherein the number of exception codes corresponding to the system code segment is greater than or equal to the number of the second exception codes.

[0053] Step S104: determining one or more system exception codes corresponding to the service to be managed from the system code segment, wherein the number of the system exception codes is less than or equal to the number of the first exception codes.

[0054] Step S105: constructing a mapping relationship among the system exception code, the first exception code and the second exception code according to the corresponding relationship between the system code segment and the second exception code to respond to the management request.

[0055] It is understandable that, when a service to be managed is added, the interface information output by the service to be managed can be obtained in advance according to relevant documents or corresponding codes. Therefore, one or more first exception codes of the service to be managed can be determined according to the interface information.

[0056] At the same time, it is also possible to determine through relevant documents or corresponding codes that one or more second exception codes already exist in the upstream service that calls the service to be managed.

[0057] Among them, the exception code and the natural language description of the exception code are one-to-one corresponding. The natural language description is a simple description of the cause of the exception obtained after converting the exception code. In the service system, when a service is called and an exception occurs, the service returns the exception code and converts the exception code into a natural language description and returns it at the same time to inform the upstream service that calls the service of the specific reason for the exception. For example, when service A is called and an exception occurs, the exception code (code) is 001, and the corresponding converted natural language description (info) can be "system exception". At this time, the exception code and its corresponding natural language description can be returned to the upstream service that calls service A, such as the returned {code: info} can be {001: system exception}.

[0058] It is understandable that in large service systems, there are often many levels of system calls. When a service call exception occurs, the natural language description output by the outermost layer is required to provide users with reasonable and friendly reminders and explanations. If the natural language description provided by the underlying service is used directly, it is often difficult for users to understand. Therefore, the upstream service usually needs to convert the exception code and the corresponding natural language description returned by the downstream service to ensure that the output information of the upstream service is reasonable and understandable to the higher-level service.

[0059] For example, in a system that provides account opening services, there may be situations where users are prohibited from opening accounts. The exception code corresponding to the call exception that prohibits users from opening accounts can be provided by the downstream service G. For example, the downstream service G provides exception codes 001, 002, 003, 004, and 005 for prohibiting account opening. Each exception code corresponds to a detailed reason for an abnormal account opening. The system does not need to provide each detailed exception reason of the downstream service G to the user. Instead, the exception codes 001, 002, 003, 004, and 005 provided by the downstream service G can be merged into the same exception code 001 for the account opening service, and the exception code 001 can be converted into a natural language description and displayed to the user, so as to provide the user with a more friendly and easy-to-understand reminder.

[0060] In one embodiment of the present invention, the correspondence between different services and independent domains includes any one or two of the following: different services to be managed correspond to different independent domains isolated from each other, and different upstream services correspond to different independent domains isolated from each other. Therefore, although the exception code 001 of the upstream service and the exception code 001 of the downstream service G have the same value, they are in independent domains isolated from each other, so they will not affect the exception handling of the service system.

[0061] Therefore, in one embodiment of the present invention, the management of the service system involves the operation of converting and configuring the exception codes of each layer of services. That is, when calling the service to be managed, the second exception code of the corresponding upstream service needs to be configured for the first exception code of the service to be managed to be output.

[0062] At the same time, in the process of conversion configuration, due to different scenarios, one or more first exception codes of the service to be managed may only need to be returned to the internal logic of the system, and do not need to be output externally through the upstream service. It may also be necessary to convert one or more first exception codes of the service to be managed through the upstream service, and output one or more second exception codes of the upstream service externally; in other words, it is necessary to convert and configure one or more first exception codes of the service to be managed into corresponding one or more second exception codes for external output in the upstream service.

[0063] It is understandable that in a service system, multiple upstream services may call the same service to be managed. In order to reduce the workload of converting and configuring the exception codes of the same service to be managed in multiple upstream services, one or more system exception codes can be determined for one or more first exception codes of the same service to be managed at the system level of the service system, and then one or more second exception codes corresponding to each of the multiple upstream services are determined based on the one or more system exception codes. In this way, a mapping relationship between the first exception code, the system exception code, and the second exception code is constructed, so that different upstream services can reuse the same system exception code, reducing the operation of directly converting and configuring the first exception code of the service to be managed in the upstream service, reducing the workload of writing code, shortening the development iteration cycle, and improving the efficiency of development.

[0064] For example, in a service system Y, upstream service A and upstream service B both call the service to be managed G, then the first exception code 001, 002, 003 of G can be mapped to a system exception code 100 in the system layer, and then this system exception code can be mapped to a second exception code 002 of upstream service A and a second exception code 003 of upstream service B respectively. In this way, upstream service A and upstream service B reuse the same system exception code 100. In other words, upstream service A and upstream service B can customize the exception cause generated by calling service G2 into their own external output reasons according to their own business, that is, the corresponding natural language description. When the exception code of the service to be managed G is added or modified, only the mapping relationship needs to be modified, without modifying the code of upstream service A or upstream service B, which can meet the changing needs of the scene, reduce the workload of modifying the code, and shorten the development iteration cycle.

[0065] Of course, there may also be a situation where an upstream service calls multiple downstream services. Similar scenarios in multiple downstream services can be corresponded to an exception code of the upstream service through different system exception codes, so that similar exception call scenarios in different downstream services can be merged and integrated in the upstream service, and output to the outside as the same exception code, identified as the same exception scenario, which can further integrate downstream exception scenarios, avoid passing too much exception information to the upstream, unify the natural language description of exception scenarios, and improve user experience.

[0066] In one embodiment of the present invention, when determining one or more system exception codes corresponding to the service to be managed, the system code segment corresponding to the service to be managed may be determined first, and then the one or more system exception codes corresponding to the service to be managed may be determined from the system code segment.

[0067] When determining the system code segment corresponding to the service to be managed, an independent code segment, i.e., an interval segment, can be allocated to the service to be managed at the system level according to the total number of exception codes of the service to be managed, so as to correspond the exception code of the service to be managed to the system exception code of the interval segment. For example, if the number of exception codes of the service to be managed G1 is 50, then a code segment space of 100 to 199 is allocated to the service to be managed G1 at the system level.

[0068] Usually, the value range of the system code segment allocated to the service to be managed will be greater than or equal to the number of exception codes of the service to be managed. This is to ensure that when the exception code of the service to be managed is expanded, the system code segment range can meet the expansion requirements of the service to be managed, reduce the situation where new system code segments may need to be allocated for the service to be managed again, and ensure that the same service to be managed uses one system code segment in the service system.

[0069] In one embodiment of the present invention, the system code segments corresponding to different services to be managed do not have overlapping code segments. For example, in a service system Z, system code segments of 100 to 199 are allocated to the service to be managed G1, system code segments of 200 to 299 are allocated to the service to be managed G2, and system code segments of 300 to 399 are allocated to the service to be managed G3. In this way, it can be ensured that the system exception codes selected for different services to be managed are unique.

[0070] It is understandable that, in a service system, usually the more exception codes of the bottom service are, the more details of the corresponding abnormal call are. When determining one or more system exception codes corresponding to the service to be managed from the system code segment, often according to the business segmentation requirements, the exception codes that do not need to be segmented externally for the abnormal cause are corresponding to the same system exception code, or the exception codes that can be merged for the abnormal cause are corresponding to the same system exception code, so as to reduce the number of system exception codes, so as to facilitate the upstream service to select the integrated system exception code when determining the second exception code. At this point, the system exception code can be regarded as the intermediate exception code between the upstream service and the service to be managed, which can play the role of integrating the exception codes of the service to be managed. Therefore, in one embodiment of the present invention, the number of system exception codes is less than or equal to the number of the first exception code.

[0071] In a preferred embodiment of the present invention, a default system exception code is provided in each system code segment. When multiple first exception codes of the services to be managed do not need to be subdivided, the multiple first exception codes of the services to be managed can all correspond to the default system exception code.

[0072] For example, in the service system Z, there are 50 first exception codes of the service to be managed G1, and the allocated system code segment is 100-199, and 100 is selected as the default system exception code of the system code segment. When the 50 first exception codes of the service to be managed G1 do not need to be subdivided, the 50 first exception codes can be mapped to the default system exception code 100.

[0073] As the number of service system scenarios increases, it may be necessary to subdivide 5 (001, 002, 003, 004, 005) of the 50 first exception codes of the service G1 to be managed, and other values ​​may be selected from the system code segment 100 to 199 as the system exception code for these 5 first exception codes. For example, according to the segmentation requirements of the business, the system exception code 101 corresponds to the first exception codes 001 and 002 of the service G1 to be managed, and the system exception code 102 corresponds to the first exception codes 003, 004, and 005 of the service G1 to be managed, while the other first exception codes (006 to 050) of the service G1 to be managed still correspond to the default system exception code 100.

[0074] After determining one or more system exception codes corresponding to the service to be managed, one or more second exception codes are selected from one or more second exception codes existing in the upstream service to correspond to the system exception code, and a mapping relationship between the system exception code, the first exception code and the second exception code is constructed.

[0075] It is understandable that some system exception codes can also be combined for upstream services. In other words, the system exception codes can also be not subdivided for upstream services, so there will be a situation where multiple system exception codes correspond to the exception code of the same upstream service. Therefore, in one embodiment of the present invention, the number of system exception codes is greater than or equal to the number of the second exception codes.

[0076] For example, for service system Z, the system exception codes corresponding to the service to be managed G1 are 100, 101, and 102. When adding the service to be managed G1 to the upstream service C, the second exception code 001 of the upstream service C can be selected to correspond to the system exception code 100, and the second exception code 002 of the upstream service C can be selected to correspond to the system exception codes 101 and 102.

[0077] When adding a new service G1 to be managed for the upstream service D, the existing second exception code 002 of the upstream service D can be selected to correspond to the system exception code 100, and the existing second exception code 003 of the upstream service D can be selected to correspond to the system exception code 101. For the system exception code 102, the exception code of the upstream service D may not be selected to correspond to it.

[0078] When the second exception code already existing in the upstream service cannot meet the identification requirements of the scene exception, one or more second exception codes can be added to the upstream service so that these newly added second exception codes correspond to the system exception code. At this time, the determination of one or more second exception codes of the upstream service in step S102 can be performed after step S104. That is, after determining one or more system exception codes, one or more second exception codes to be added are determined in the corresponding upstream service.

[0079] It is understandable that the addition of one or more second exception codes is performed in an independent domain of the upstream service exception code, and the exception code in each independent domain is unique.

[0080] For example, in service system Z, when the existing second exception codes 001 and 002 of upstream service C cannot meet the scenario requirements of system exception code 103 corresponding to the service G1 to be managed, a new second exception code 003 corresponding to system exception code 103 can be added in upstream service C, and a corresponding natural language description can be added for the newly added second exception code 003.

[0081] After constructing the mapping relationship among the system exception code, the first exception code and the second exception code, in one embodiment of the present invention, the mapping relationship is stored in a database and pushed to the service system memory in real time.

[0082] It is understandable that the mapping relationship is stored in the database, and the corresponding system exception code and the exception code of the downstream service called by the upstream service can be easily queried according to the second exception code of the upstream service. It is convenient to comb the relationship between the exception code in each service and the exception code of the downstream service called by it, and provide data reference for the merging of the exception codes of the same scene. When adding a new service to be managed, it can be checked whether there is the same scene according to the mapping relationship in the database, and whether there is a system exception code that can be reused, thereby reducing the situation of increasing exception codes in the system.

[0083] And with these mapping relationships stored in the database, query summary charts can be easily generated, so that the information of these exception codes can be more intuitively understood from a global perspective, and the downstream services that provide the output exception codes and natural language descriptions can be better understood. The context is relatively clear, which is convenient for the subsequent global integration planning.

[0084] When the scenario corresponding to the existing exception code changes, the corresponding relationship of the exception code is unreasonable and needs to be adjusted, the mapping relationship in the database can be easily modified, and the data can be pushed to the system memory in real time so that the modified mapping relationship takes effect immediately, thereby improving the timeliness of the system.

[0085] When modifying the mapping relationship, the following method provided by an embodiment of the present invention can be adopted. In response to the management type being a modification type, the management request indicates a modification relationship. According to the modification relationship, at least one of the following steps is performed: a step of modifying the correspondence between the first exception code and the system exception code in the mapping relationship, and a step of modifying the correspondence between the system exception code and the second exception code in the mapping relationship.

[0086] Among them, the modification relationship in the management request can be to modify the relationship between the first exception code of the system to be managed and the system exception code. For example, in the service system Z, the system exception code 101 corresponds to the first exception codes 001 and 002 of the service G2 to be managed, and the system exception code 102 corresponds to the first exception codes 003, 004, and 005 of the service G2 to be managed, and the other first exception codes (006-050) of the service G2 to be managed correspond to the default system exception code 100. The modification relationship in the management request indicates that the system exception code corresponding to the first exception code 006 of the system to be managed is changed from 100 to 102. At this time, the relationship data of the system exception code corresponding to the first exception code 006 of G2 is queried from the database: 006->100, and the value of the system exception code is changed from 100 to 102, that is, 006->102, to complete the modification of the mapping relationship.

[0087] The modification relationship in the management request can also be to modify the correspondence between the system exception code and the second exception code. For example, in the service system Z, the second exception code 001 of the upstream service C corresponds to the system exception code 100, and the second exception code 002 of the upstream service C corresponds to the system exception codes 101 and 102. The modification relationship in the management request indicates that the system exception codes 101 and 102 corresponding to the second exception code 002 of the upstream service are changed to 101. Then, two relationship data corresponding to the second exception code 002 of the upstream service C can be queried in the database: 002->101, 002->102, and the data 002->102 is deleted to complete the modification of the mapping relationship.

[0088] It is understandable that the exception code and the natural language description of the exception code are stored in the database at the same time. When the natural language description of the exception code needs to be modified, it is also convenient to query the natural language description corresponding to the exception code in the database according to the exception code, and modify the natural language description in the database, and push the modified data to the memory in real time, and take effect immediately, so as to facilitate the system to output the modified exception description to the outside.

[0089] After configuring the mapping relationship of exception codes in the database for a downstream service, when a service system calls the downstream service to be called, the following method provided by an embodiment of the present invention can be adopted: receiving a call request, the call request indicating the service to be called; determining the target exception code corresponding to the service to be called; determining the upstream exception code of the upstream service of the service to be called based on the mapping relationship; converting the upstream exception code into a natural language description, and outputting the natural language description to the upstream service.

[0090] It is understandable that when the service to be called is called in the service system and a call exception occurs, the mapping relationship corresponding to the target exception code is queried from the database based on the target exception code returned by the service to be called, the upstream exception code of the upstream service is determined, and the natural language description corresponding to the upstream exception code in the database is output to the outside.

[0091] According to an embodiment of the present invention, a method for service system management is provided, which can build a mapping relationship between the exception codes of upstream and downstream services. Therefore, when it comes to adding or modifying scene call exceptions, it can be achieved directly by adding nodes in the mapping relationship or modifying the mapping relationship, without having to modify the business codes of the upstream and downstream services respectively, thereby reducing the amount of code changes, shortening the iteration cycle, and improving development efficiency.

[0092] Furthermore, by storing the mapping relationship in the database, the corresponding relationship of the exception codes in the system can be easily queried and maintained, which reduces the difficulty of system maintenance and improves development efficiency. The mapping relationship is pushed to the system memory in real time, so that the newly added or modified exception codes take effect in real time, thereby improving the effectiveness of the system.

[0093] Combine the following Figure 2 Taking a newly added downstream service in a service system as an example, a method for managing a service system provided by an embodiment of the present invention is described in detail. Figure 2 As shown, the method may include the following steps:

[0094] Step S201: Obtain a request for adding a new downstream service G.

[0095] The request indicates that a downstream service G is added to an upstream service A in a service system.

[0096] Step S202: Allocate a unique key to the downstream service G.

[0097] In the service system, each service has a unique key, and the key can be used to divide the service into independent domains that are isolated from each other. The exception codes of different services can be the same.

[0098] Step S203: Allocate a system code segment for the downstream service G and determine a system abnormality code.

[0099] Step S204: construct a mapping relationship between the downstream service G and the system exception code.

[0100] Step S205: construct a mapping relationship between the system exception code corresponding to the downstream service G and the exception code of the upstream service A.

[0101] Step S206: Store the mapping relationship in the database and push it to the system memory.

[0102] The mapping relationship in step S204 and the mapping relationship in step S205 are stored in a database, and these mapping relationship data are pushed to the system memory.

[0103] Step S207: Determine the exception code of upstream service A.

[0104] When an exception occurs when upstream service A calls downstream service G, the exception code of upstream service A is determined based on the exception code of downstream service G.

[0105] Figure 3 The diagram is a schematic diagram of an abnormal code mapping relationship of a service system provided by an embodiment of the present invention.

[0106] It can be understood that each exception code has a corresponding natural language description.

[0107] Distributed large-scale systems often involve multiple service systems, such as Figure 3 As shown, services G1, G2, and G3 are downstream services in service system X, services A, B, and C are upstream services in service system X, and services A and B are downstream services in service system Y.

[0108] Similarly, service E and service F can be upstream services in service system Y, and can also be downstream services of other service systems, which will not be repeated here.

[0109] Service G1, service G2, and service G3 all have independent system code segments corresponding to them in service system X. For example, service G1 corresponds to the code segment of 100-199, service G2 corresponds to the code segment of 200-299, and service G3 corresponds to the code segment of 300-399.

[0110] Multiple exception codes (001, 002, 003) of service G1 can correspond to the same system exception code 100 in the system code segment, so as to merge the exception scenarios that do not need to be subdivided in service G1, and output the same exception code 001 and its corresponding natural language description through service A.

[0111] like Figure 3As shown, the exception code 002 of service A corresponds to service G1 through system exception code 101, and also corresponds to service G2 through system exception code 200. That is to say, the exception scenario corresponding to the exception code 002 of service A can be provided by service G1 or by service G2. Similar scenarios of service G1 and service G2 can be merged in system X, and the natural language description of the same exception code can be output externally through service A.

[0112] For example, service A is an account opening service and may need to call service G1 for verifying the user's basic information and service G2 for verifying the user's risk level. The exceptions that occur when calling service G1 and the exceptions that occur when calling service G2 can both be output to the user through service A with the same exception code 002 and a natural language description of 002, such as "account opening prohibited."

[0113] like Figure 3 As shown, the exception code 002 of service B and the exception code 001 of service C are both corresponding to service G3 through the system exception code 300. That is to say, by reusing the same system exception code, multiple different services can customize the exception codes provided by downstream services according to the business needs of their respective services and output more reasonable natural language descriptions.

[0114] For example, service G3 provides a basic account verification service, service B is a user login verification service, and service C is a user purchase verification service. Both service B and service C need to call service G3 to verify the account. When service B encounters an exception when calling service G2, it can output 002 to the outside, and its natural language description can be "login verification failed". When service C encounters an exception when calling service G2, it can output 001 to the outside, and its natural language description can be "purchase operation failed".

[0115] It can be understood that service A and service B are called in service system Y, so system code segments in service system Y are allocated to service A and service B and a mapping relationship is established, such as Figure 3 As shown, no further details are given here.

[0116] It is understandable that the system code segments of different service systems X and Y are only visible within the system, that is, the system code segment of service system X is only used for service system X and is invisible to service system Y.

[0117] like Figure 4 As shown, the embodiment of the present invention provides a device 400 for service system management, including: a receiving module 401, a determining module 402, and a constructing module 403; wherein,

[0118] The receiving module 401 is used to receive a management request, where the management request indicates the service to be managed and the management type in the service system;

[0119] The determination module 402 is used to determine, in response to the management type being a newly added type, one or more first exception codes of the service to be managed, and an upstream service that can call the service to be managed and one or more second exception codes of the upstream service; determine a system code segment corresponding to the service to be managed, the number of exception codes corresponding to the system code segment is greater than or equal to the number of the second exception codes; determine one or more system exception codes corresponding to the service to be managed from the system code segment, the number of the system exception codes is less than or equal to the number of the first exception codes;

[0120] The construction module 403 is used to construct a mapping relationship between the system exception code, the first exception code and the second exception code according to the corresponding relationship between the system code segment and the second exception code, so as to respond to the management request.

[0121] In one embodiment of the present invention, continue to refer to Figure 4 The service system management device may further include: a calling module 404; wherein,

[0122] The calling module 404 is used to receive a calling request, which indicates a service to be called; determine a target exception code corresponding to the service to be called; determine an upstream exception code of an upstream service of the service to be called based on a mapping relationship; convert the upstream exception code into a natural language description, and output the natural language description to the upstream service.

[0123] In one embodiment of the present invention, the determination module 402 is used to respond to the management type being a modification type, and the management request indicating a modification relationship, and perform at least one of the following steps according to the modification relationship: a step of modifying the correspondence between the first exception code and the system exception code in the mapping relationship, and a step of modifying the correspondence between the system exception code and the second exception code in the mapping relationship.

[0124] In one embodiment of the present invention, the determining module 402 is used to determine that the system code segments corresponding to different services to be managed do not have overlapping code segments.

[0125] In one embodiment of the present invention, the determination module 402 is used to determine the correspondence between different services and independent domains, including any one or two of the following: different services to be managed correspond to different isolated independent domains, and different upstream services correspond to different isolated independent domains.

[0126] In one embodiment of the present invention, the construction module 403 is used to store the mapping relationship in a database and push it to the service system memory in real time.

[0127] According to a service system management device provided by an embodiment of the present invention, it is possible to construct a mapping relationship between exception codes of upstream and downstream services. Therefore, when it comes to adding or modifying scenario call exceptions, it can be achieved directly by adding nodes in the mapping relationship or modifying the mapping relationship, without having to modify the business codes of the upstream and downstream services respectively, thereby reducing the amount of code changes, shortening the iteration cycle, and improving development efficiency.

[0128] Furthermore, by storing the mapping relationship in the database, the corresponding relationship of the exception codes in the system can be easily queried and maintained, which reduces the difficulty of system maintenance and improves development efficiency. The mapping relationship is pushed to the system memory in real time, so that the newly added or modified exception codes take effect in real time, thereby improving the effectiveness of the system.

[0129] Figure 5 An exemplary system architecture 500 is shown to which the method or apparatus for service system management according to an embodiment of the present invention may be applied.

[0130] like Figure 5 As shown, the system architecture 500 may include terminal devices 501, 502, 503, a network 504 and multiple servers 505, 506, 507. The network 504 is used to provide a medium for communication links between the terminal devices 501, 502, 503 and the servers 505, 506, 507, and multiple servers 505, 506, 507. The network 504 may include various connection types, such as wired, wireless communication links or optical fiber cables, etc. Multiple servers 505, 506, 507 may correspond to upstream and downstream services respectively, and multiple servers 505, 506, 507 may perform service calls based on their calling relationships.

[0131] The user can use the terminal devices 501 , 502 , 503 to interact with the server 505 via the network 504 to initiate a call request or receive a natural language description, etc.

[0132] The terminal devices 501 , 502 , and 503 may be various electronic devices having a display screen and supporting information browsing, including but not limited to smart phones, tablet computers, laptop computers, desktop computers, and the like.

[0133] Servers 505, 506, and 507 may be servers that provide various services, such as servers that provide call services for call requests made by users using terminal devices 501, 502, and 503. The server may analyze and process the received call requests and other data, and feed back the processing results including natural voice descriptions and other contents to the terminal device.

[0134] It should be noted that the service system management method provided in the embodiment of the present invention is generally executed by the servers 505 , 506 , 507 , and accordingly, the service system management device is generally set in the servers 505 , 506 , 507 .

[0135] It should be understood that Figure 5 The number of terminal devices, networks and servers in the embodiment is only for illustration. Any number of terminal devices, networks and servers may be provided according to implementation requirements.

[0136] Reference below Figure 6 , which shows a schematic diagram of the structure of a computer system 600 of a terminal device suitable for implementing an embodiment of the present invention. Figure 6 The terminal device shown is only an example and should not bring any limitation to the functions and scope of use of the embodiments of the present invention.

[0137] like Figure 6 As shown, the computer system 600 includes a central processing unit (CPU) 601, which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 602 or a program loaded from a storage part 608 into a random access memory (RAM) 603. In the RAM 603, various programs and data required for the operation of the system 600 are also stored. The CPU 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input / output (I / O) interface 605 is also connected to the bus 604.

[0138] The following components are connected to the I / O interface 605: an input section 606 including a keyboard, a mouse, etc.; an output section 607 including a cathode ray tube (CRT), a liquid crystal display (LCD), etc., and a speaker, etc.; a storage section 608 including a hard disk, etc.; and a communication section 609 including a network interface card such as a LAN card, a modem, etc. The communication section 609 performs communication processing via a network such as the Internet. A drive 610 is also connected to the I / O interface 605 as needed. A removable medium 611, such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, etc., is installed on the drive 610 as needed, so that a computer program read therefrom is installed into the storage section 608 as needed.

[0139] In particular, according to the embodiments disclosed in the present invention, the process described above with reference to the flowchart can be implemented as a computer software program. For example, the embodiments disclosed in the present invention include a computer program product, which includes a computer program carried on a computer-readable medium, and the computer program includes a program code for executing the method shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from the network through the communication part 609, and / or installed from the removable medium 611. When the computer program is executed by the central processing unit (CPU) 601, the above-mentioned functions defined in the system of the present invention are executed.

[0140] It should be noted that the computer-readable medium shown in the present invention may be a computer-readable signal medium or a computer-readable storage medium or any combination of the above two. The computer-readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, device or device, or any combination of the above. More specific examples of computer-readable storage media may include, but are not limited to: an electrical connection with one or more wires, a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the above. In the present invention, a computer-readable storage medium may be any tangible medium containing or storing a program that can be used by or in combination with an instruction execution system, device or device. In the present invention, a computer-readable signal medium may include a data signal propagated in a baseband or as part of a carrier wave, which carries a computer-readable program code. This propagated data signal may take a variety of forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination of the above. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, which may send, propagate or transmit a program for use by or in conjunction with an instruction execution system, apparatus or device. The program code contained on the computer-readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, optical cable, RF, etc., or any suitable combination of the above.

[0141] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the system, method and computer program product according to various embodiments of the present invention. In this regard, each box in the flow chart or block diagram can represent a module, a program segment, or a part of a code, and the above-mentioned module, program segment, or a part of a code contains one or more executable instructions for realizing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in a different order from the order marked in the accompanying drawings. For example, two boxes represented in succession can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram or flow chart, and the combination of the boxes in the block diagram or flow chart can be implemented with a dedicated hardware-based system that performs a specified function or operation, or can be implemented with a combination of dedicated hardware and computer instructions.

[0142] The modules involved in the embodiments of the present invention may be implemented by software or hardware. The modules described may also be arranged in a processor, for example, they may be described as: a processor includes a receiving module, a determining module, and a building module. The names of these modules do not constitute limitations on the modules themselves in certain circumstances, for example, the determining module may also be described as a "module for determining a system exception code".

[0143] As another aspect, the present invention also provides a computer-readable medium, which may be included in the device described in the above embodiment; or it may exist independently and not be assembled into the device. The above computer-readable medium carries one or more programs, and when the above one or more programs are executed by a device, the device includes: receiving a management request, the management request indicates the service to be managed and the management type in the service system; in response to the management type being a newly added type, determining one or more first exception codes of the service to be managed, and the upstream service that can call the service to be managed and one or more second exception codes of the upstream service; determining the system code segment corresponding to the service to be managed, the number of exception codes corresponding to the system code segment is greater than or equal to the number of the second exception codes; determining one or more system exception codes corresponding to the service to be managed from the system code segment, the number of the system exception codes is less than or equal to the number of the first exception codes; according to the corresponding relationship between the system code segment and the second exception code, constructing a mapping relationship between the system exception code, the first exception code and the second exception code to respond to the management request.

[0144] According to the technical solution of the embodiment of the present invention, it is possible to construct a mapping relationship between the exception codes of upstream and downstream services. Therefore, when it comes to adding or modifying scenario call exceptions, it can be achieved directly by adding nodes in the mapping relationship or modifying the mapping relationship, without having to modify the business codes of the upstream and downstream services respectively. This can reduce the amount of code changes, shorten the iteration cycle, and improve development efficiency.

[0145] Furthermore, by storing the mapping relationship in the database, the corresponding relationship of the exception codes in the system can be easily queried and maintained, which reduces the difficulty of system maintenance and improves development efficiency. The mapping relationship is pushed to the system memory in real time, so that the newly added or modified exception codes take effect in real time, thereby improving the effectiveness of the system.

[0146] The above specific implementations do not constitute a limitation on the protection scope of the present invention. It should be understood by those skilled in the art that various modifications, combinations, sub-combinations and substitutions may occur depending on design requirements and other factors. Any modification, equivalent substitution and improvement made within the spirit and principle of the present invention shall be included in the protection scope of the present invention.

Claims

1. A method for managing a service system, characterized in that: include: receiving a management request, wherein the management request indicates a service to be managed and a management type in the service system; In response to the management type being a newly added type, determining one or more first exception codes of the service to be managed, and an upstream service that can call the service to be managed and one or more second exception codes of the upstream service; Determine a system code segment corresponding to the service to be managed, wherein the number of exception codes corresponding to the system code segment is greater than or equal to the number of the second exception codes; Determine one or more system exception codes corresponding to the service to be managed from the system code segment, where the number of the system exception codes is less than or equal to the number of the first exception codes; According to the corresponding relationship between the system code segment and the second exception code, a mapping relationship among the system exception code, the first exception code and the second exception code is constructed to respond to the management request.

2. The method according to claim 1, characterized in that Also includes: receiving a call request, wherein the call request indicates a service to be called; Determine the target exception code corresponding to the service to be called; Determine the upstream exception code of the upstream service of the service to be called according to the mapping relationship; The upstream exception code is converted into a natural language description, and the natural language description is output to the upstream service.

3. The method according to claim 1, characterized in that Also includes: In response to the management type being a modification type, the management request indicates a modification relationship, and according to the modification relationship, at least one of the following steps is performed: a step of modifying the correspondence between the first exception code and the system exception code in the mapping relationship, and a step of modifying the correspondence between the system exception code and the second exception code in the mapping relationship.

4. The method according to claim 1, characterized in that After constructing the mapping relationship between the system exception code, the first exception code and the second exception code, the method further includes: The mapping relationship is stored in a database and pushed to the service system memory in real time.

5. The method according to claim 1, characterized in that The system code segments corresponding to different services to be managed do not have overlapping code segments.

6. The method according to any one of claims 1 to 5, characterized in that: The correspondence between different services and independent domains includes any one or both of the following: Different services to be managed correspond to different independent domains isolated from each other, and different upstream services correspond to different independent domains isolated from each other.

7. A device for service system management, characterized in that: include: A receiving module, a determining module and a building module; wherein, The receiving module is used to receive a management request, where the management request indicates the service to be managed and the management type in the service system; The determination module is configured to determine, in response to the management type being a newly added type, one or more first exception codes of the service to be managed, and an upstream service that can call the service to be managed and one or more second exception codes of the upstream service; Determine a system code segment corresponding to the service to be managed, the number of exception codes corresponding to the system code segment being greater than or equal to the number of the second exception codes; determine one or more system exception codes corresponding to the service to be managed from the system code segment, the number of the system exception codes being less than or equal to the number of the first exception codes; The construction module is used to construct a mapping relationship between the system exception code, the first exception code and the second exception code according to the corresponding relationship between the system code segment and the second exception code, so as to respond to the management request.

8. The device according to claim 7, characterized in that Also includes a calling module; wherein, The calling module is used to receive a calling request, which indicates a service to be called; determine a target exception code corresponding to the service to be called; determine an upstream exception code of an upstream service of the service to be called based on a mapping relationship; convert the upstream exception code into a natural language description, and output the natural language description to the upstream service.

9. An electronic device, characterized in that: include: one or more processors; a storage device for storing one or more programs, When the one or more programs are executed by the one or more processors, the one or more processors implement the method according to any one of claims 1 to 6.

10. A computer readable medium having a computer program stored thereon, characterized in that: When the program is executed by a processor, the method according to any one of claims 1 to 6 is implemented.

Citation Information

Patent Citations

  • Data processing method, device and medium and electronic device

    CN109344046A

  • Micro-service monitoring method and device, equipment and storage medium

    CN113835969A