Service calling mode based on data message

Abstract

The invention relates to the technical field of communication between services, and discloses a service calling mode based on a data message. According to the application, the Kafka cluster is used as the message middleware to realize asynchronous request and return message transmission among the services through the data message, the services do not directly call each other and do not depend on a centralized registration component, decentralization can be realized on an architecture level, low coupling is realized on a dependency relationship, and the service performance is improved. And light weight is realized on the technical tool stack.

Description

Technical Field

[0001] This application relates to the technical field of inter-service communication, and particularly to the inter-service communication technology in distributed systems and microservice architectures. Background Art

[0002] This section aims to provide background or context for understanding the embodiments of this application. It is for reference only and should not be considered as an admission by the applicant that this section belongs to the prior art that has been publicly available before the filing date of this application.

[0003] In existing enterprise applications and information systems, with the increasing complexity of business scenarios and the continuous expansion of processing scale, the architecture mode of distributed systems has been widely adopted. In a distributed system, the originally centralized monolithic application is usually split into multiple independent and relatively independently deployed service modules, and these modules cooperate with each other to complete the overall business process. The communication and cooperation methods between such services directly affect the scalability, maintainability, and reliability of the system.

[0004] To achieve the interaction and data transfer between services, various communication methods and protocols are often adopted in the prior art. Among them, the more common ones include:

[0005] 1. Remote Procedure Call (RPC for short): RPC hides the call details and allows the caller to call a remote service as if it were a local method. However, RPC usually requires relatively tight interface constraints between services. When the interface or parameter definition of the called service changes, the calling party needs to update synchronously, resulting in potential coupling and fragility within the system.

[0006] 2. Representational State Transfer Application Programming Interface (RESTful API for short): RESTful API realizes the interaction between services based on the Hypertext Transfer Protocol (HTTP for short). Since HTTP is relatively common in network transmission and the RESTful style has certain resource and standardization characteristics, this method has been widely used in practice. However, for application scenarios that need to handle high concurrency and large amounts of data, there are still challenges in terms of performance and scalability in the synchronous call mode of RESTful interfaces.

[0007] 3. WebService (Web service) is a web-based communication protocol that allows applications on different platforms and in different programming languages to interoperate and exchange data over a network. Web Service enables applications to call each other and share functions through standard network protocols and data formats without having to worry about the underlying implementation details. Web Service typically uses the XML format to transmit data, which is more verbose than binary or simplified formats (such as JSON or Protobuf), thus incurring a relatively large message overhead. In addition, SOAP messages usually require complex parsing, which results in relatively low performance.

[0008] In typical business scenarios such as process approval, not only approval requests and results need to be transmitted between services, but also process identifiers, business parameters, and approval results need to be transmitted efficiently, flexibly, and with low coupling. If traditional RPC or RESTful communication methods are used in such scenarios, there may be many limitations when interfaces change, versions are upgraded, or interface exceptions occur.

[0009] Therefore, under the existing technical conditions, there is still a need for a service communication method that does not rely on centralized components to achieve loose coupling and flexible expansion between services, so as to meet the requirements of complex business scenarios including process approval. This method should be based on asynchronous communication to make the request and return data transmission between services more efficient and easy to expand, and achieve reliable data interaction without directly calling each other. This is the technical problem to be solved by the existing technology. Summary of the Invention

[0010] The purpose of this application is to provide a service call method based on data packets, which can achieve decentralization at the architecture level, low coupling in terms of dependencies, and lightweight in terms of the technical tool stack.

[0011] This application discloses a service call method based on data packets. The Kafka cluster, as a message middleware, realizes asynchronous request and return packet transmission through data packets between the requesting service and the receiving service, where each service does not directly call each other and does not rely on a centralized registration component; the method includes:

[0012] In the requesting service, a request packet is generated according to a predefined data packet format that includes service identification information and request parameters. The predefined data packet format is independent of the internal implementation of the service, does not rely on centralized components and specific communication frameworks, and can be extended for the business by adding or modifying fields; the request packet is sent to the request topic of the Kafka cluster;

[0013] In the receiving service, the process request message is received from the approval request topic of the Kafka cluster, parsed and processed according to the service identification information and request parameters therein, and a result message is generated according to the same predefined data message format, and the result message is sent to the result topic of the Kafka cluster;

[0014] In a preferred example, after receiving the result message returned by the approval service, the process service determines the next processing logic of the current process instance according to the approval result field included in the result message; if the approval result field indicates approval, the process instance is advanced to the subsequent approval node or the process instance is ended; if the approval result field indicates rejection, the process instance is rolled back to the initiator node according to the rejection reason shown in the approval result field, and at the same time, a notification message containing the rejection reason is generated and sent to the corresponding topic in the Kafka cluster again, so that the relevant services can perform corresponding business processing accordingly.

[0015] In a preferred example, the approval request topic and the approval result topic are independently configured in the Kafka cluster to achieve classified storage and transmission of process approval request messages and approval result messages.

[0016] In a preferred example, both the process approval request message and the approval result message contain process identification information that can identify a specific process instance, so that the process service can determine the corresponding approval process instance when receiving the returned message.

[0017] In a preferred example, when parsing the process approval request message, the approval service selects the corresponding approval rule template for processing according to the approval node information, and generates the approval result message according to the processing result.

[0018] In a preferred example, when parsing the approval result message, the message service determines the display form of the message according to the approval result field, and sends the generated return result message to the approval service asynchronously.

[0019] In a preferred example, the Kafka cluster is a distributed cluster structure, which performs redundant storage and load balancing distribution of messages to ensure reliability and scalability in high-concurrency and high-data-volume scenarios.

[0020] In a preferred example, when modifying the process approval logic or approval node information, only the fields of the predefined data message format need to be added, subtracted or updated, and there is no need to synchronously adjust the internal implementation of the process service, approval service or message service.

[0021] The present application also discloses a non-transitory computer-readable storage medium, in which computer-executable instructions are stored, and when the computer-executable instructions are executed by a processor, the steps in the method described above are implemented.

[0022] The present application also discloses a computer program product, including computer-executable instructions, and when the computer-executable instructions are executed by a processor, the steps in the method described above are implemented.

[0023] In the embodiments of the present application, by adopting a message middleware based on a Kafka cluster for asynchronous request and return transmission of data packets between services, and introducing a predefined data packet format independent of internal implementation, not relying on centralized components and specific frameworks, decoupling between services can be achieved. The technical effects are as follows:

[0024] 1. Through the asynchronous packet transmission method without direct invocation, services do not depend on changes in each other's internal implementations. When the internal logic or interfaces of a certain service are adjusted, other services do not need to change synchronously, greatly reducing the coupling and maintenance costs.

[0025] 2. By not relying on centralized registration components, decentralized deployment and expansion of services are realized, improving the flexibility and scalability of the system.

[0026] 3. By only needing to follow the predefined packet format without integrating specific frameworks or components, the development and debugging processes of services are simplified, the development speed is increased, and the dependence on a specific technology stack is reduced.

[0027] In other words, by adopting this asynchronous communication solution based on Kafka and the predefined packet format, a more flexible, lightweight and reliable interaction method for the service architecture can be realized, thereby improving the overall maintainability, scalability and decoupling of the system.

[0028] Furthermore, after the process service receives the approval result packet returned by the approval service, by dynamically determining the next processing logic of the process according to the result field, the approval process can be advanced or rejected flexibly according to business requirements, realizing the dynamicization and flexible adjustment of the approval process, thereby significantly improving the adaptability and scalability of the system to business changes.

[0029] Furthermore, by respectively configuring independent topics for the process approval request packet and the approval result packet in the Kafka cluster, different types of messages can be clearly classified and managed, thereby improving the maintainability and scalability of message processing, and making the data interaction between services more orderly and efficient.

[0030] Furthermore, by including process identification information that can identify a specific process instance in both the process approval request message and the approval result message, it is possible to ensure that the returned message can accurately correspond to the corresponding process instance, thereby improving the accuracy of process tracking and tracing, and simplifying the debugging and diagnosis work at the process instance level in the system.

[0031] Furthermore, by selecting the corresponding approval rule template for processing according to the approval node information in the approval service, the approval rules can be quickly changed, extended, or replaced according to business requirements, thereby providing high flexibility and configurability for the process approval logic of the system, and helping to quickly respond to business changes and reduce maintenance costs.

[0032] Furthermore, by determining the message display form and transmission path according to the approval result field in the approval result message in the message service, personalized and scenario-based message output can be achieved, thereby improving the user experience and the effectiveness of message notifications, and providing customized processing capabilities for different user scenarios.

[0033] Furthermore, by using a distributed Kafka cluster to perform redundant storage and load balancing distribution of messages, the reliability of message transmission and the scalability of the system can be ensured in scenarios of high concurrency and high data volume, thereby meeting the high-performance and high-availability requirements of large-scale distributed applications.

[0034] Furthermore, by only adding, deleting, or updating fields in the predefined data message format, the process approval logic or approval node information can be modified without synchronously adjusting the internal logic of the service, which can make the system more flexible and agile in dealing with business changes, and reduce the later maintenance cost and implementation difficulty. BRIEF DESCRIPTION OF THE DRAWINGS

[0035] Figure 1 is a schematic diagram of the service call method relationship based on data messages according to an embodiment of the present application;

[0036] Figure 2 is a flowchart of the collection, preprocessing, processing, and warehousing services according to an embodiment of the present application;

[0037] Figures 3 - 5 is a diagram of the metadata definition fields corresponding to the collected data message according to an embodiment of the present application;

[0038] Figure 6 is a sample diagram of the collected data message according to an embodiment of the present application;

[0039] Figure 7 is a sample diagram of the processed data message according to an embodiment of the present application;

[0040] Figure 8It is a sample diagram of the incoming data message according to an embodiment of the present application;

[0041] Figure 9 It is a flowchart of the leave application business according to an embodiment of the present application;

[0042] Figure 10 It is a flowchart of service interaction according to an embodiment of the present application;

[0043] Figure 11 It is a schematic diagram of the multi-center change process according to an embodiment of the present application;

[0044] Figure 12 It is a sample diagram of the approval request message according to an embodiment of the present application;

[0045] Figure 13 It is a sample diagram of the approval return message according to an embodiment of the present application;

[0046] Figure 14 It is a sample diagram of the preprocessed message according to an embodiment of the present application. Detailed implementation manners

[0047] In the following description, many technical details are provided to help readers better understand the present application. However, those of ordinary skill in the art can understand that the technical solutions claimed in the present application can be implemented even without these technical details and various changes and modifications based on the following embodiments.

[0048] Explanation of some concepts:

[0049] The Kafka cluster is a distributed message system deployment structure composed of multiple Kafka server (i.e., Broker) nodes. The cluster realizes redundant storage of messages and fault tolerance by storing messages in partitions and replicas. Each node works collaboratively in the cluster to provide a high-throughput, scalable, and low-latency transmission channel for message production (writing) and consumption (reading). Through cluster management coordination, Kafka can maintain reliable message transmission and high availability and scalability of the system in the event of node failures or load changes.

[0050] To make the purpose, technical solutions, and advantages of the present application clearer, the embodiments of the present application will be further described in detail below with reference to the accompanying drawings.

[0051] Figure 1It is a relationship diagram of service call methods based on data packets in an embodiment of the present application, which generally includes three parts, namely microservices, message middleware, and message packets. Among them, microservices are composed of process services, approval services, and message services. The communication between microservices is all realized through the Kafka cluster of message middleware, and there is no need for direct calls between microservices. The message middleware is the Kafka cluster, which is used to provide a transmission channel for request and return packets of microservices. The packets are divided into two types: request packets and received packets of services, corresponding to the input parameters during requests and the return information when receiving results respectively. The overall implementation does not need to rely on centralized components, such as the implementation of microservice registration centers, and does not need to rely on specific implementation frameworks. Only the transmission of packets is required. In addition, there is no need for direct communication between services, which greatly reduces the coupling between services.

[0052] Embodiment 1: Implementation of the basic process approval scenario

[0053] Taking the leave approval process within an enterprise as an example, the service call method based on data packets described in the present invention will be described.

[0054] I. System environment and participating objects

[0055] Process service: Responsible for initiating and promoting the leave process, including receiving the submission of leave forms, creating or updating process instances, etc.

[0056] Approval service: Responsible for parsing and processing the approval request packets sent by the process service, and judging the received approval requests and generating approval results according to preset approval rules (such as department manager approval nodes, supervisor approval nodes).

[0057] Message service: Generate corresponding message notifications according to the approval requests, and return the approval results to the approval service in the form of data packets.

[0058] Kafka cluster: As message middleware, it provides an asynchronous and reliable transmission channel for data packet interaction between the above services. There are at least two topics in the Kafka cluster, namely the approval request topic and the approval result topic. The approval request topic is used to store the approval request packets sent by the process service, and the approval result topic is used to store the approval result packets and return packets generated by the approval service and the message service.

[0059] II. Predefined data packet format

[0060] The packets use a predefined format for data exchange. The main fields include:

[0061] Process identifier: Used to identify a specific process instance. For example, a certain process instance can be called process number 123.

[0062] Approval Node: Used to indicate the current approval process, such as department manager approval, HR approval node, etc.

[0063] Request Parameters: Used to carry request business data, such as the number of days off, reason for leave, applicant's name.

[0064] Approval Result: Reflected in the result message, used to indicate the conclusion of approval passed or rejected.

[0065] Reason: Used to specify the specific reason when the approval result is rejected, such as the need to supplement supporting documents.

[0066] The definition of the data message format is independent of the internal implementation logic of the service and does not require the aid of centralized components and specific communication frameworks. When the process requirements change, the message content can be extended by adding or adjusting fields without a large-scale modification of the docking method between services.

[0067] III. Transmission Process of Request and Return Messages

[0068] After the process service receives the leave application form submitted by the user, it will generate an approval request message according to business needs. This message contains a process identifier (such as process number 123), an approval node (such as department manager approval), and request parameters (such as 3 days off, reason for leave: family affairs). The process service sends this message to the approval request topic in the Kafka cluster.

[0069] The approval service subscribes to the approval request topic. When it receives the corresponding approval request message, it extracts information such as the process identifier, approval node, and request parameters from it and processes them according to the predefined approval rules. After the approval service matches the approval item, it generates a message request message and sends it to the message request topic.

[0070] The message service subscribes to the message request topic. When it receives the approval request message, it generates a message reply to the approval service based on the result of the user's approval. If the approval is passed, the message service generates a message result message, which contains that the approval result corresponding to the original process identifier is passed. If the approval is rejected, it indicates the rejection and the reason (such as the need to supplement supporting documents) in the approval result and sends this message to the approval result topic.

[0071] The process service also subscribes to the corresponding topic. When it receives a return message that matches its own process identifier from it, if the approval result is passed, it advances the process instance to the next step or ends the process; if it is rejected, it rolls back the process instance to the applicant for modification and can initiate an approval request again as needed.

[0072] This embodiment demonstrates that under the conditions of no registry center and no specific framework dependence, the process service, approval service, and message service interact only through the Kafka middleware and data messages, so as to achieve decoupling, decentralization, and lightweighting among services.

[0073] Embodiment 2: Dynamic Expansion of Approval Nodes and Update of Message Fields

[0074] In practical applications, it may be necessary to expand the approval process. For example, adding a legal approval node based on the original department manager approval node. The traditional method often requires modifying the service interface definition and registry center information, increasing coupling and configuration costs. The present invention can easily adapt to such changes through data message expansion.

[0075] When adding a new legal approval node, when the process service generates an approval request message, it only needs to expand the approval node field in the message from department manager approval to legal approval in the message, and add legal review-related information in the request parameters. There is no need to modify the communication framework or registry center configuration.

[0076] After receiving the new message, the approval service only needs to add a processing rule for the legal approval node in the internal logic, and can parse the corresponding fields without changing the communication method, and generate a new approval result message.

[0077] The message service is the same as the process service, and can make corresponding business processing according to the newly added fields. Thus, the ability to dynamically expand the approval process is achieved.

[0078] Embodiment 3: Data Collection and Warehousing of the Operation and Maintenance Basic Platform Subsystem

[0079] The core of the operation and maintenance basic platform is a data middle platform. Based on the data middle platform, the operation and maintenance of enterprise information systems are carried out around the middle platform data, and it is required that this platform can integrate data from different subsystems. The data integration ability of the platform is to carry out the transfer of data collection, data processing, and data warehousing in the service call mode based on data messages, collect, preprocess, process, and warehouse all data from subsystems. The operation and maintenance basic platform uses data to supply the required data to other subsystems to meet the functions of other subsystems. The specific process is as Figure 2 shown.

[0080] The business processes of data collection, preprocessing, processing, and warehousing are as follows:

[0081]

[0082]

[0083] In the important link of data acquisition, processing, and storage, the subsystem data docking is carried out by combining the service call method of data messages, which is conducive to the decoupling of each data processing stage, and load separation and horizontal expansion can be achieved in each stage. Since the communication method of the present invention does not depend on a registration center and a specific framework, the expansion of service instances or topic allocation only needs to be completed at the Kafka level, and there is no need to make complex adjustments to the service communication logic.

[0084] Embodiment 4: Approve the leave application process.

[0085] The following is an introduction to an application scenario using the service call method based on data messages. This scenario is a business scenario where platform users use the process center module to submit a leave application process, and the approving user approves the leave application process. It is divided into three steps as a whole. The first step is to initiate the process. The leave applicant clicks the leave application process on the platform to initiate it. The second step is to submit the form. The leave applicant fills in the leave form and clicks submit for the process. The third step is approval. The approving user will see the leave approval message of the leave applicant in the message list of the personal portal, and then clicks pass or reject. If it passes, the process ends. If it is not approved, the process node will be returned to the originator, the leave applicant node. The overall process is as Figure 9 shown.

[0086] Next is the description of the service interaction process of the leave approval scenario. First, the backend microservices involved are the process service, the approval service, and the message service. The process service is the backend service of the process center module, and its functions include process portal, process management, process template management, etc. The approval service is the backend service for platform user approval, and it has functions such as approval item management, approval management, approval delegation, etc. The message service is a module for platform users to receive internal messages, and it has functions such as message management and message policy management. Business interactions need to be carried out among the three services. However, the three microservices do not need to rely on a communication framework. Only the message specification needs to be defined, and then the business interaction can be achieved according to the message specification. Secondly, there is no need to directly call each other, which greatly reduces the coupling between service interactions. In addition, there is no need to rely on a centralized registration center component during the interaction, making the architecture layer lighter.

[0087] The overall service interaction process is as follows. First, the process service sends an approval request message to the approval service. Then, the approval service sends an approval message request message to the message service according to the approval request message and the corresponding approval item rules. At this time, the message service displays the approval message on the page according to the approval message request message. After the approval message is approved by the user, the message service sends the approval result to the approval service in the form of a message return message. The approval service sends the approval result to the process service in the form of an approval return message. The process service performs the next step of passing or rejecting according to the approval result message. The service interaction process is as Figure 10 shown.

[0088] Example 5: Complex business process.

[0089] In this embodiment, a special processing mechanism for specific types of processes (such as "multi-center change process") is introduced. Such processes need to automatically generate multiple parallel approval nodes according to the conditional fields in the message, perform dynamic compliance verification on the approval nodes, and automatically perform backtracking when an exception occurs, so as to reflect the unique steps and data processing methods of the present invention in specific scenarios of process approval. The overall process is as Figure 11 shown.

[0090] Step 1: Process initiation and conditional field setting

[0091] (1.1) After the process service receives a specific form submitted by the user (such as "multi-center change process"), it generates an approval request message according to the predefined data message format. The message includes:

[0092] Business type (such as: businessType = APPROVE_REQUEST)

[0093] Request authentication (such as: token = kS4BN8R5GweDXPJo0UJM7jwdKQ)

[0094] Request time (such as: time = 1704178466000)

[0095] Approval name (such as: title = multi-center change approval)

[0096] Business parameters (e.g., requester name requestName = "Zhang San", requester department requestDepartment = "Operation and Maintenance Department", requester mobile phone requestMobile = 18888888888, title = "Synchronous Dual-live Switching of Credit Investigation System", change environment changeEnvironment = "Production Environment", change scope changeScope = ["Shanghai Data Center", "Metropolitan Data Center"], business system bus inessSystem = "Second-generation Credit Investigation System", planned completion time of change plannedComplet ionTimeOfChange = "2023-04-07 21:00:00", technical support contact technicalSupportContact = "Li Si", verification support contact verificationSupportContact = "Zhang San", test verification report testVerificationReport = "Switching Plan Test Verification Report.docx", change implementation plan changeImplementationPlan = "Switching Plan Change Implementation Plan.docx", change rollback plan changeRollbackPlan = "Switching Plan Change Rollback Plan.docx")

[0097] Compliance check instruction fields (e.g., complianceCheck = true)

[0098] Dynamic node generation trigger condition fields (e.g., conditionalExpansion = {"threshold": ["Shanghai Data Center", "Metropolitan Data Center", "Off-site Disaster Recovery Center"], "extraApprovals": ["insertValueNode"]} indicates that when multiple data centers are involved, approval nodes corresponding to the respective data centers need to be automatically inserted), and an example of the approval request data message is as Figure 12 shown.

[0099] (1.2) The process service sends the message containing the above fields to the "Approval Request Topic" in the Kafka cluster.

[0100] Step 2: Dynamic node generation and compliance check parsing of the approval service

[0101] (2.1) After receiving the message from the "Approval Request Topic", the approval service first checks the data centers to be changed according to the predefined fields (e.g., conditionalExpans ion). After detecting multiple data centers, parallel approval nodes for the corresponding data center management positions need to be inserted into the subsequent approval path: such as the production change management position, metropolitan changeMore management positions, Disaster recovery change management position .

[0102] (2.2) If there is a predetermined flag in the message (for example, complianceCheck = true), the approval service loads the corresponding compliance verification rule template according to the process type (multi-center change). The template contains consistency requirements for parallel approval results, that is, after multiple data center nodes return results, it is necessary to conduct a compliance comparison on their change scope to see if it is within the specified change scope (such as Shanghai data center, local data center, and remote disaster recovery center).

[0103] (2.3) The approval service generates several sub-messages for the next approval based on the analysis results. Among them:

[0104] Three parallel approval request messages are generated according to the scope of change, pointing to the Shanghai change management post node, the same city change management post approval node, and the disaster recovery change management post. These three messages contain a parallelGroupID="PG1234" field, which is used for identification and association in subsequent result aggregation. The feedback message generated by the approval is as follows Figure 13 shown.

[0105] Step 3: Parallel approval process and result aggregation

[0106] (3.1) The approval service sends the above three approval request messages to the corresponding topics in Kafka, such as the "Process Approval Request Topic". The approval service instance subscribes to the corresponding topic, receives the message from it, and processes the request. Production change Management position , Same - city change management position and disaster recovery change management position After the approval is completed, they each generate an approval result message, which contains:

[0107] Original process identification information, for example, businessId = 6775ffea133aewefcc

[0108] Information related to the parallel identifier, such as parallelGroupID="PG1234"

[0109] Approval result field (eg approvalResult = "agree", R skControlResult = "agreeWithConditions").

[0110] (3.3) After the three parallel result messages are received by the approval service, result aggregation is performed based on the information related to the parallel identifier (such asParallelGroupID). The approval service generates a merged result message after aggregation, which not only contains the approval conclusions of the three parallel nodes but also makes additional judgments according to the predefined compliance verification rules. For example, when all data center change management positions approve, the compliance verification logic will record this requirement in the merged result message as a "conditional approval" flag (complianceStatus = "conditionalApproval").

[0111] Step 4: Exception Handling and Automatic Backtracking

[0112] (4.1) If a certain node does not return a result for a long time during the parallel approval process (for example, exceeding the set time limit of 48 hours), the approval service executes automatic reminder according to the delay policy and reminder field predefined in the message.

[0113] For example:

[0114] delayPolicy = {"maxWaitHours": 48, "escalationNode": "financeDirector"} When timeout occurs, the approval service automatically publishes a reminder message to the "message notification topic", and the message service sends a reminder notice after receiving it.

[0115] (4.2) If a certain node rejects the application (for example, the same - city change management position rejects the same - city change application), the result message contains a backtracking instruction (rollbackInstruction = {"targetNode": "requestNode", "approvalResult": "refuse"}). After receiving this merged result message, the process service returns the process to the change requester (requestNode) node according to the backtracking instruction (rollbackInstruction) and prompts the rejection information of the same - city change management position on the user interface. This backtracking ability is not necessary in ordinary message transmission but is unique and has significant practicality in the process approval scenario.

[0116] Step 5: Final Processing and Archiving

[0117] (5.1) When the process service receives the merged result message that has passed the final qualification and meets the compliance requirements (complianceStatus = "conditionalApproval"), it will push the process instance to the subsequent change processing node. After the change processing node is completed, the process service will send a processing confirmation message to the Kafka topic, and the approval service will confirm the change result after receiving it.

[0118] (5.2) Finally, when all conditions are met and the approval requirements of all parallel nodes are completed, the approval service generates a final approval message and carries full-link audit fields (including the approval timestamp, digital signature, etc. of each node). After receiving the final message, the process service archives the approval records for future audits.

[0119] As can be seen from the above embodiments, the technical solution of this application has the following advantages in practical applications:

[0120] Decentralization: It does not rely on centralized components such as a registration center, reducing the system complexity and maintenance cost.

[0121] Low coupling: Services do not directly call each other, and only need to interact with messages according to a unified data message format, significantly reducing the coupling degree between services.

[0122] Lightweight: It does not need to rely on a specific communication framework, and developers only need to ensure that all parties follow the established message format.

[0123] Flexible expansion: Message fields can be easily added or deleted, and approval nodes and process logics can be quickly adjusted without making major changes to the infrastructure.

[0124] Accordingly, an embodiment of the present application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the method embodiments of the present application. The computer-readable storage medium includes permanent and non-permanent, removable and non-removable media and can implement information storage by any method or technology. The information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette tapes, disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible by a computing device. As defined herein, computer-readable storage media do not include transitory computer-readable media, such as modulated data signals and carrier waves, etc.

[0125] In addition, an embodiment of the present application further provides a process approval system based on data packets, which includes a memory for storing computer-executable instructions and a processor; the processor is configured to implement the steps in the above method embodiments when executing the computer-executable instructions in the memory. Among them, the processor may be a central processing unit (abbreviated as "CPU"), a graphic processing unit (abbreviated as "GPU"), a digital signal processor (abbreviated as "DSP"), a microcontroller unit (abbreviated as "MCU"), a neural network processor (abbreviated as "NPU"), an application specific integrated circuit (abbreviated as "ASIC"), a field programmable gate array (abbreviated as "FPGA") or other programmable logic devices, etc. The aforementioned memory may be a read-only memory (abbreviated as "ROM"), a random access memory (abbreviated as "RAM"), a flash memory, a hard disk or a solid state drive, etc. The steps of the methods disclosed in the embodiments of the present invention can be directly embodied as being executed and completed by a hardware processor, or executed and completed by a combination of hardware and software modules in the processor.

[0126] In addition, an embodiment of the present application further provides a computer program product, which includes computer-executable instructions, and the computer-executable instructions implement the steps in the above method embodiments when being executed by a processor.

[0127] It should be noted that in this application, relational terms such as first and second are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the term "comprising", "including" or any other variant thereof is intended to cover non-exclusive inclusion, such that a process, method, article or device comprising a series of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article or device. Without further limitation, an element defined by the statement "comprising one" does not exclude the presence of additional identical elements in the process, method, article or device comprising the element. In this application, if it is mentioned that an act is performed according to a certain element, it means at least performing the act according to the element, including two cases: performing the act only according to the element and performing the act according to the element and other elements. Expressions such as multiple, multiple times, multiple types, etc. include 2, 2 times, 2 types, as well as more than 2, more than 2 times, more than 2 types.

[0128] The serial numbers used when describing the steps of a method do not themselves impose any limitation on the order of these steps. For example, a step with a larger serial number is not necessarily to be executed after a step with a smaller serial number. It is also possible to execute the step with a larger serial number first and then the step with a smaller serial number, or they can be executed in parallel, as long as this execution order is reasonable for those skilled in the art.

[0129] This specification includes combinations of various embodiments described herein. Separate references to embodiments (such as "an embodiment" or "some embodiments" or "preferred embodiments"); however, unless indicated as mutually exclusive or clearly understood by those skilled in the art to be mutually exclusive, these embodiments are not mutually exclusive. It should be noted that, unless the context clearly indicates or requires otherwise, the word "or" is used in a non-exclusive sense in this specification.

[0130] All documents mentioned in this specification are considered to be integrally included in the disclosure of this application so that they can be used as a basis for modification when necessary. In addition, it should be understood that the above are only preferred embodiments of this specification and are not used to limit the protection scope of this specification. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principles of one or more embodiments of this specification shall be included within the protection scope of one or more embodiments of this specification.

[0131] In some cases, the acts or steps recited in the claims may be performed in a different order than in the embodiments and still achieve the desired result. Additionally, the processes depicted in the figures do not necessarily require the particular order shown or sequential order to achieve the desired result. In certain embodiments, multitasking and parallel processing are also possible or may be advantageous.

Claims

1. A service calling method based on data message, characterized in that: The Kafka cluster acts as a message middleware to implement asynchronous request and return message transmission between services through data messages, wherein the services do not directly call each other and do not rely on a centralized registration component; the method includes: In the process service, a process approval request message is generated according to a predefined data message format including process identification information, approval node information and approval request parameters, wherein the predefined data message format is independent of the internal implementation of the service, does not rely on centralized components and specific communication frameworks, and the approval process can be extended by adding or modifying fields; the process approval request message is sent to the approval request topic of the Kafka cluster; In the approval service, the process approval request message is received from the approval request topic of the Kafka cluster, parsed and processed according to the approval node information and approval request parameters therein, and an approval message message is generated according to the same predefined data message format, and the approval message message is sent to the message request topic; In the message service, the approval message is received from the message request topic of the Kafka cluster, displayed to the user according to the predefined data message format, and a message approval result message is generated according to the user approval result, and the message approval result message is sent to the message result topic. Then, the approval service processes the message approval result topic and generates an approval return message and sends it to the approval result topic.

2. The data message-based service calling method according to claim 1, characterized in that: The sender service generates a request message according to a predefined data message format including identification information and consumer service business request parameters, and sends the message to the request topic of the Kafka cluster; Receive the request message from the request topic of the Kafka cluster, parse and process it according to the node information and request parameters therein, generate a result message according to the same predefined data message format, and send the result message to the result topic of the Kafka cluster; The result message is received from the result topic of the Kafka cluster, the result field is parsed according to the predefined data message format, and a return message is generated according to the parsing result, and the return message is sent to the requesting party.

3. The data message-based service calling method according to claim 1, characterized in that: After receiving the approval result message returned by the approval service, the process service determines the next processing logic of the current process instance according to the approval result field contained in the approval result message; If the approval result field indicates approval, the process instance is advanced to the subsequent approval node or the process instance is terminated; If the approval result field indicates rejection, the process instance will be rolled back to the initiator node according to the rejection reason shown in the approval result field, and a notification message containing the rejection reason will be generated and sent to the corresponding topic in the Kafka cluster again so that the relevant services can perform corresponding business processing accordingly.

4. The data message-based service calling method according to claim 1, characterized in that: The approval request topic and the approval result topic are independently configured in the Kafka cluster to achieve classified storage and transmission of process approval request messages and approval result messages; The process approval request message and the approval result message both contain process identification information that can identify a specific process instance, so that the process service can determine the corresponding approval process instance when receiving the return message.

5. The data message-based service calling method according to claim 1, characterized in that: When parsing the process approval request message, the approval service selects a corresponding approval rule template for processing according to the approval node information, and generates the approval result message according to the processing result.

6. The data message-based service calling method according to claim 1, characterized in that: When parsing the approval request message, the message service determines the display form of the message according to the approval request field, and generates a message approval result message according to the result of the user's approval and sends it to the approval service in an asynchronous manner.

7. The data message-based service calling method according to claim 1, characterized in that: The Kafka cluster is a distributed cluster structure that performs redundant storage and load balancing on messages to ensure reliability and scalability in high-concurrency and high-data-volume scenarios.

8. The data message-based service calling method according to claim 1, characterized in that: When modifying the process approval logic or approval node information, it is only necessary to add, delete or update the fields of the predefined data message format without synchronously adjusting the internal implementations of the services of the various parties.

9. A non-transitory computer-readable storage medium, characterized in that: The non-transitory computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the steps in the method according to any one of claims 1 to 8 are implemented.

10. A computer program product comprising computer executable instructions, characterized in that: When the computer executable instructions are executed by a processor, the steps in the method described in any one of claims 1 to 8 are implemented.

Images