Asynchronous mode supporting distributed micro service framework system and implementation method thereof

Abstract

The invention discloses a high-availability framework system for single-point isomerous data storage. The system comprises a client library ti-a59-client, an isomerous data conversion and storage service module ti-a59-builder, a data write operation log service module ti-a59-log-srv, a data queue framework ti-queue, a message queue service module MQServer, a single-point deployment isomerous data storage server Single Server DataStore, a write request log service data storage module Write Log DataStore and a write request control log data storage module Ctrl Log DataStore. Furthermore, the invention further discloses an implementation method of the system. The system has higher cross-platform deployment capacity besides the characteristic of high-availability supporting of single-point deployment storage including an existing framework, and important characteristics of supporting more data storage types, supporting data synchronization between isomerous data and supporting data backup and data recovery functions during failure of a node.

Description

technical field [0001] The invention belongs to the field of computers, and relates to a micro-service framework, in particular to a cross-protocol calling and asynchronous distributed service callback mode, and in particular to a distributed micro-service framework system supporting an asynchronous mode; therefore, the present invention also relates to the asynchronous supporting The implementation method of the distributed microservice framework system of the pattern. Background technique [0002] With the development of the Internet, the scale of applications continues to expand, and the conventional vertical application architecture can no longer cope with it. The distributed service architecture is imperative, and the microservice architecture is one of the practices. The microservice architecture disassembles a single application into finer-grained microservices. Each service can be independently deployed, run independently, and has a complete service contract to achie...

AI Technical Summary

Problems solved by technology

This is mainly because the existing framework only saves the object reference of the local program callback when invoking the service, and does not consider the multi-node distributed service at all, which cannot meet the requirements of a distributed service system that requires high stability.

[0004] 2) Does not support cross-protocol microservice calls: The caller of microservices will involve multiple platforms and multiple communication channels. For example, when developing mobile Internet applications, the mobile APP needs to call microservices. Considering the delay and Instability and other characteristics require the use of WEB SOCKET to transmit data, while the background microservice provider transmits data based on the queue server

This requires the framework to support proxy conversion and message conversion between protocols and transporters. However, the existing framework requires all calls and service providers to use a unified protocol and transporter, which cannot meet the needs of cross-platform and cross-protocol development of Internet applications.

[0005] 3) Lack of cache processing mechanism for services: the existing framework cache mechanism is relatively simple to implement, only considering the local cache processing of the calling end, which consumes a lot in the face of high-frequency service calls, reducing the efficiency of service processing

[0006] 4) Lack of unified management of services: the current framework lacks service management, and only maintains a local service list file at the service calling end, which makes it difficult to ensure the consistency and effectiveness of services, and cannot perform unified scheduling and management of services, and maintain the overall service framework The complexity of the

[0007] 5) Service calls do not support the annotation mode of the main programming model: all service calls and exposures of the current framework need to be defined in detail in the configuration file, including the interface, method, and callback description of the call service, which cannot be described in the programming process Metaphor, seamlessly embedded with the main programming model, means that the call logic of the service interface needs to be re-described in the configuration file, which increases the workload of call implementation and the complexity of maintenance

Images