CN110825356A - Micro-service development framework and real-time monitoring implementation method - Google Patents
Micro-service development framework and real-time monitoring implementation method Download PDFInfo
- Publication number
- CN110825356A CN110825356A CN201911097910.5A CN201911097910A CN110825356A CN 110825356 A CN110825356 A CN 110825356A CN 201911097910 A CN201911097910 A CN 201911097910A CN 110825356 A CN110825356 A CN 110825356A
- Authority
- CN
- China
- Prior art keywords
- component
- cloud
- components
- service
- model
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/20—Software design
- G06F8/24—Object-oriented
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F8/00—Arrangements for software engineering
- G06F8/30—Creation or generation of source code
- G06F8/36—Software reuse
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/542—Event management; Broadcasting; Multicasting; Notifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/546—Message passing systems or structures, e.g. queues
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/54—Interprogram communication
- G06F9/547—Remote procedure calls [RPC]; Web services
- G06F9/548—Object oriented; Remote method invocation [RMI]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Landscapes
- Engineering & Computer Science (AREA)
- Software Systems (AREA)
- Theoretical Computer Science (AREA)
- General Engineering & Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Physics & Mathematics (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Multimedia (AREA)
- Stored Programmes (AREA)
Abstract
The invention discloses a micro-service development framework and a real-time monitoring implementation method, which can arrange, assemble or reconstruct micro-services on line and provide the development environment and the operation of real-time monitoring service as a service for a real-time monitoring system. The micro-service development framework is a cloud component model and comprises a public facility model, a cloud component combination model and a public service model; the public facility model defines contract type architecture configuration and a cloud component warehouse, and drives the operation of the micro-service by relying on a multi-branch tree type component topological graph; the combined model manages the base component, the derived component and the composite component, and assembles the active component and the passive component according to the functional characteristics; the common service module for real-time monitoring micro-service and common monitoring micro-service are defined by the common service model, an assembling or reconstructing method of the real-time monitoring micro-service is provided, and a cloud native monitoring system is supported and constructed.
Description
Technical Field
The invention belongs to the technical field of cloud native micro-service development environments and real-time monitoring services, relates to a component model of a cloud technology, and further relates to a method for realizing real-time monitoring.
Background
The IOE framework of the traditional central database is difficult to support dispatching automation software which is interdependent with a next-generation communication network, an Internet of things, cloud computing and the like.
The service-oriented architecture SOA is a coarse-grained loosely-coupled service architecture, realizes integration of different applications through ESB, inhibits personalized change, and is obviously unsuitable for supporting development of real-time monitoring micro-like services by using WebService/BPM/ESB main technical carriers. The CORBA of the common object request agent has high complexity, a standard object application configuration mode is not available, an interdependent compact object set is instantiated, and the difficulty of constructing a large-scale distributed application is high.
At present, a real-time monitoring microservice development framework supporting dynamic assembly deployment, a multithreading reaction mechanism and a component trust mechanism is needed urgently, and a Platform as a Service (Platform-as-a-Service) for scheduling automation (PaaS) is supported and constructed.
Disclosure of Invention
The invention provides a micro-service development framework and a real-time monitoring implementation method, aiming at: aiming at the defects of the prior art of the dispatching automation information system, a real-time monitoring PaaS platform is supported and constructed in the form of a cloud component model and a real-time monitoring public service.
In order to achieve the purpose, the invention is realized by the following technical scheme:
a micro-service development framework is characterized in that a cloud component model is constructed; the cloud component model is a distributed componentization development model based on cloud technology.
As a further improvement of the above development framework: the cloud component is a distributed application component based on cloud technology, and is an application component for packaging a real-time monitoring PaaS public service interface access method; the cloud component model includes a public facility model, a cloud component portfolio model, and a public service model.
As a further improvement of the above development framework: the public facility model comprises specification, configuration and cloud component warehouse of the cloud component;
the specification of the cloud component comprises an interface specification, an arranging and assembling specification and a driving operation specification;
the configuration is a contract type architecture configuration made according to the standard constraint, and the configuration structure is as follows: [ component name, component type, component configuration, set of subcomponents ]; the configured contract comprises a prior condition, a posterior condition and an invariance, and defines a component access interface; mapping an ordered multi-branch tree type component topological graph based on contractual architecture configuration, wherein nodes in the topological graph are objects bound by cloud components and cloud connectors, and the cloud connectors are used for realizing communication among the cloud components; the topological graph is used as a guide carrier of the micro service, and the loading, initialization, starting, running and closing operations of the micro service are realized by traversing the topological graph.
As a further improvement of the above development framework: the cloud component warehouse comprises a cloud component registration record, a cloud component dynamic library and a cloud component cache manager;
the configuration structure of the cloud component registration record is [ library, types, md5], the library is a dynamic library name corresponding to the cloud component, and the types are an entity class set of the cloud component type;
and when the micro service is loaded, the corresponding dynamic library is retrieved according to the cloud component name and the registration record, and then the dynamic library is opened and loaded to the micro service.
As a further improvement of the above development framework: in the cloud component combination model, the cloud components are divided into the following parts according to the combination mode: a base component, a derived component, and a composite component;
the base component is an atomic computing unit of a packaged PaaS method;
the derived component is a component derived from an existing base component;
the composite component is a component formed by packaging a plurality of cloud components;
in the topological graph, leaf nodes are base components or derivative components, and other nodes are composite components;
the cloud components are divided into: a movable component and a passive component;
the active component encapsulates an active object class to realize active multithreading processing; the active component manages the subordinate passive components of the active component, and broadcasts the state information of the subordinate components to all the active components;
the passive component encapsulates a reactor mode class to realize passive processing;
the active component and the passive component can be any one of a base component, a derived component and a composite component.
As a further improvement of the above development framework: the public service model is used for defining an application entity used in real-time monitoring business and comprises a parameter library component, a numerical library component, a producer component, a consumer component, a flow calculation component, a data processor component, an alarm component and an object storage component; the common service model also includes common and customized common development components; a component in the common service model to provide common service support for monitoring or control;
the bottom layer of the common service model contains the following services: directory services, event services, distributed real-time databases, and elastic message queues.
As a further improvement of the above development framework: the micro-service is a service which is deployed in a Docker container and independently completes a single monitoring or control function; the microservices may be packaged into components that are loaded into a common service model for integration or access by other microservices.
The invention also discloses a real-time monitoring implementation method, which constructs the micro-service for monitoring on the basis of the micro-service development framework and implements the component management of the micro-service.
As a further improvement of the above implementation: the component management of the microservice comprises:
a) event monitoring: the root component corresponding to the root node in the topological graph is an active component, and events of all the active components are managed uniformly; the root component is provided with an event manager used for registering the event processor and deleting the event processor; the movable component pushes the events of the subordinate components to the root component; the root component analyzes the event set, and issues a conclusion of event analysis to a cloud component event theme of the elastic message queue at regular time or according to abnormal triggering; other active components except the root component subscribe to the event theme of the cloud component, and drive the operation of the active components when abnormal events exist;
b) thread management: analyzing the events broadcast by the associated components on the active component nodes and driving the activity of the lower sub-components; the active component comprises an active object processor and starts a passive component or an active component associated with thread running to run; the activity component is also used for analyzing the events broadcasted by the associated activity component and finishing the uploading and downloading of the driving events; the abnormal closing of the sub-component can trigger the closing of the self-component and broadcast an abnormal event; when the upper layer active component requests arrive at the passive component, the passive component receives all the requests by a non-blocking thread by using a multi-path distribution strategy, and then dispatches the requests to the passive component of the passive component or the subordinate passive component; the calculation result of the passive component is cached in the component, and when the calculation is finished or is driven by a timer, the cached data is sent to the requested active component;
c) and (3) trust authentication: the events broadcast by the cloud components comprise MD5 strings, and identity authentication of the components is realized by checking the MD5 strings.
As a further improvement of the above implementation: the cloud component model drives the search traversal based on the topological graph to complete the operations of loading, initializing, starting, running and closing of the micro-service:
(1) and (3) loading operation: processing rightwards from the leftmost sub-tree connected with the root node of the multi-branch tree, processing each sub-tree along the direction from the root node of the sub-tree to a leaf node, sequentially loading cloud components corresponding to the nodes according to the processing direction, and loading a dynamic library corresponding to the cloud components;
(2) initialization operation: processing rightwards from the leftmost sub-tree connected with the root node of the multi-branch tree, processing each sub-tree in the direction from the leaf node of the sub-tree to the root node of the sub-tree, and sequentially initializing the cloud components corresponding to the nodes along the processing direction;
(3) and (3) starting operation: after the initialization operation is completed, opening the link handles of the cloud components one by one according to the initialization sequence, completing the loading of the monitoring parameters, and establishing the connection relationship of the cloud components;
(4) and (3) operation: after the starting operation is finished, driving the movable components to run in a multithreading mode according to the reverse order during the starting operation, and finishing the event communication and processing among the cloud components by relying on the multithreading communication technology of the message bus;
(5) closing operation: and after receiving the abnormal event notification of the cloud components, closing the cloud components one by one according to the reverse order of the starting operation.
Compared with the prior art, the invention has the following beneficial effects: (1) the invention provides a fine-grained component development framework, which can arrange and replace components in microservices without recompiling programs, and supports the evolution of a monitoring system from a 'migration cloud' framework to a cloud native framework; (2) the cloud component model provides mechanisms such as thread management and trust authentication, improves the source code reuse rate, reduces the development cost and meets the requirement of real-time high-concurrency streaming computing processing.
Drawings
FIG. 1 is a schematic diagram of a tree topology of a utility model in an embodiment.
FIG. 2 is a schematic diagram of a framework structure of a cloud component model.
FIG. 3 is a schematic diagram of a cloud component loading sequence of the microservice of FIG. 1.
FIG. 4 is a schematic diagram illustrating a sequence of initialization, startup, operation, and shutdown of cloud components of the microservice of FIG. 1.
Detailed Description
The technical scheme of the invention is explained in detail in the following with the accompanying drawings:
the invention provides a micro-service development framework, which is a distributed componentization development model of a cloud technology, and is hereinafter referred to as a cloud component model. The cloud component is a short name of a cloud native distributed component, and encapsulates an access interface of the real-time monitoring public service of the PaaS platform.
The cloud component model comprises a public facility model, a cloud component assembly model and a public service model, and realizes the componentized management of the micro-service. The public facility model defines a contract type architecture configuration model and a cloud component warehouse model, a multi-branch tree type component topological graph of the micro-service is constructed by means of architecture configuration driving, and management of cloud component collaborative development of the real-time monitoring type micro-service is supported. The portfolio model manages the base, derived, or composite components and assembles active or passive components according to the functional characteristics. The common service module defines the service components commonly used by the real-time monitoring micro-service and provides a component trust authentication and multithreading cooperative computing mechanism.
The embodiment starts from the analysis of the top-level public facility of the cloud component model, explains the contract type architecture configuration and the registration format of a component warehouse, and explains the driving principle of the ordered multi-branch tree type topological graph in the micro service; the embodiment illustrates common public services for implementing monitoring control and the assembly application principle thereof; the scheme of the embodiment can support cloud component dynamic assembly of the micro-service, improves the source code reuse rate and saves the development time.
The description of the present embodiment is based on the accompanying figures 1 to 4, in which:
FIG. 1 is a tree topology diagram of a cloud component utility model, which depicts an association between passive composite components, active composite components, micro-service contractual architecture configurations, connectors, derived components, base components, leaf components, etc. The cloud component model drives cloud component assembly of the micro service based on the topological graph, analyzes cloud component architecture configuration and component registration records, extends downwards from a main/root component, and assembles a passive component and an active component.
FIG. 2 illustrates a cloud component model framework including a composition model, a public service model, and a utility model. The cloud component is divided into a base component, a derived component and a composite component according to the combination characteristics; event communication is carried out among the components by using a message bus of thread communication; the component management module collects and analyzes component events, and drives trust authentication and component management.
FIG. 3 illustrates a loading sequence of cloud components in a microservice.
FIG. 4 illustrates a sequence of initialization, startup, operation, and shutdown of cloud components in a microservice.
The construction of the cloud component model is described in detail below:
1. public facility model
The utility model refers to a utility provided by the monitoring platform and used or enjoyed by the monitoring application, and can be classified into services such as a standard, a configuration and a mirror warehouse according to the characteristics of the real-time monitoring type project. The specification comprises interface specification, editing and assembling specification and driving operation specification, and is configured into 'contractual architecture configuration' formulated according to specification constraint, and the mirror image warehouse can be called as 'cloud component warehouse'.
1) Cloud component warehouse
The cloud component warehouse comprises a set of file system, a sharded memory component snapshot of a distributed real-time library and a related management method.
A distributed file system is used to maintain cloud component registration records and a cloud component dynamic library. The structure of the partitioned memory snapshot of the distributed real-time database is as follows: key _ mmap = map < key _ t, shared _ ptr < CLASS (map < key, value >) >; wherein, key _ t is the table name of the monitoring model, and shared _ ptr is the shared pointer; CLASS is a common query and maintenance method of real-time table or abstract record and attached with a record map container; the key recorded in the container is the ID index of the record body, and the value is the JSON object of the record body.
(1) Cloud component registration records
The component repository contains a configuration file of cloud component registration, and the configuration structure is as follows: com _ register = [ library, types ], which is a dynamic library name of a cloud component, and types is an entity class set of the cloud component type; the configuration may be Libconfig, Json or Yaml format text file, and the component registration record of Libconfig in this embodiment is as follows:
modules: ({library = "libkemp_paramdb.so"; types = ["KParamDbCache","KNosqlDbBackend",…]; }, { library = "libkemp_backend.so"; types= ["KRdbmsBackend"," KParamDbProxy","KParamEventProcessor",…]; }, … )
and analyzing the cloud component registration record, and establishing an index relation from the component type to the component association dynamic library to simplify the loading of the dynamic library of the service. When the component is released, the cloud component registration record is analyzed, and MD5 strings of the dynamic library are added:
modules:( { library = "libkemp_paramdb.so"; types = ["KParamDbCache","KNosqlDbBackend",…]; md5 = "3ecdbc8399c5f632e13af93d5d928ad7"; }, … )
(2) cloud component dynamic library
The cloud component dynamic LIBRARY is a C + + dynamic LIBRARY (or a scripting LIBRARY in python language), points to a stored file directory by using an environment variable LD _ LIBRARY _ PATH, is generally a dynamic LIBRARY or a scripting LIBRARY of a distributed file system management component, and is searched and queried through a PATH.
When micro-service is loaded, reading a cloud component registration record and caching the cloud component registration record into a JSON object, and inquiring the relation between an entity class of a cloud component and an associated dynamic library through traversing the JSON object; after finding the dynamic library, the C + + component opens and loads (built) the dynamic library into the closed _ com _ mmap container (an application of the fragmented memory snapshot of the distributed real-time database) using the method provided by dlfcn.
The cloud component repository further comprises a cache manager, and the cache manager uses the 'sharded memory snapshot' cache component: close _ com _ mmap = map < name, shared _ ptr < IComponent (map < name, config >) >; wherein, name is the name of the component, config is the key value configuration information of the component implementation class; IComponent is an application interface of the "component base class" and can be embodied as any cloud component. The cloud component can be loaded into the fragment memory snapshot after registering the dynamic library and the implementation class information in the warehouse; the repository provides a per-component name retrieval method.
(3) Retrieval loading of dynamic libraries
In the contractual architecture configuration, the type attribute of the cloud component specifies the entity class, and the connection relationship between the cloud component and the dynamic library can be retrieved. The cloud component warehouse provides a basic retrieval method of 'registration record JSON' and 'cloud _ com _ mmap container', the retrieval of 'cloud component name- > cloud component type- > cloud component dynamic library' is achieved, a dlopen method is used for opening the dynamic library, and application handles are returned.
2) Contractual architecture configuration
The contractual architecture configuration is a configuration file of contractual software design, and requires a designer to define a formal, accurate and verifiable interface for a cloud component, namely, the component needs to contain a priori condition, a posteriori condition and invariants. The component contract specifies the right and responsibility of the connector to exchange messages, and the processes of initialization, caching, publishing, subscribing, storing and the like of the messages have fixed component methods. The contractual architecture configuration describes the tree assembly relationship of cloud components in the micro-service in a light-weight data exchange text configuration file mode.
The configuration structure is as follows: kemp _ mcac = [ name, type, config, children ], i.e., [ component name, component type, component configuration, set of subcomponents ]: the component name is the component name of the string; the component type is an interface and a class realized by the interface, and comprises attribute information of the class; the component configuration is a private key value class configuration of the component implementation class; a sub-component set is a collection of next level cloud components that the cloud components contain. The architecture configuration can be a configuration file in a Libconfig, Json or Yaml format, and the configuration is analyzed when the micro-service is loaded and loaded into a JSON object for global traversal.
A priori condition of the cloud component contract: according to the operation sequence of FIG. 3 or FIG. 4, the operated components are checked before the components are verified, and the sequence of the components is required to be arranged according to the contract of a designer; the posterior conditions are as follows: after any component is abnormal, the operated component needs to be backed off; invariants are identity attributes of components, such as component names or attributes of on _ dump () outputs, which are the basis for trust authentication of cloud components. In this embodiment, the architecture configuration of the parameter library component paramdb in libconfig format of the microservice application "microservice-app 01" is as follows:
name: "microservice-app01"; type: "KApplication"; children: ( { name: "paramdb"; type: "KParamDbCache";children: ( { name: "actor"; type: "KActor";children: ( { name: "param_loader"; type: "KApp01ParamLoader"; children:( {name: "backend"; type: "KNosqlDbBackend"; config : { nosqldb_host: "host01";}}) }) }) }, …)
explanation of the analysis:
cloud components are inherited from IComponent ("application interface of component base class"), including: initializing, starting, closing, name obtaining, type obtaining, attribute obtaining, component activity or not, root component obtaining, parent component setting, parent component obtaining, child component adding and deleting, child component obtaining and all child and grandchild components obtaining and the like; interface materialization class, before the basic method, the fixed prefix ("on _"): the method comprises the following steps that (1) an on _ init () initialization component, an on _ open () opening component and an on _ close () closing component are used; the active components at least comprise methods of on _ run () component thread starting, on _ event () active object event processing, on _ dump () output component attribute and the like; the passive component loads a timer in the on _ open () method, and the calculation process is timed through the timeout event handling function.
The contract type design differentiates operation and query method, basic query and derivative query are separated, each operation method has a priori condition, each query method and posterior condition, and after checking the correct identity of the connected components, the message processing is carried out.
3) Cloud component tree topology map
The cloud component tree topology map is a mapping of 'contractual architecture configuration', is a carrier of public facilities, and the nodes are objects bound by cloud components and connectors.
The cloud component is a computing unit of a packaged PaaS method and comprises an interface, a type, configuration and constraint attributes; after registering in the "cloud component repository," it is interconnected with other components through cloud connectors. "interface" is a contractually designed access interface; "type" is the implementation class of the factory schema; "configuration" is private key value class configuration information of the type; "constraints" include cloud component loading constraints, parameter constraints, numerical constraints, and manual operation constraints. The cloud component interface contract specifies the rights and responsibilities of interface interaction among multiple cloud components, and the implementation class needs to inherit the 'component base class' and the interface declaration.
The cloud connector is used for erecting a bridge for message (event) communication at a message blocking place in the cloud component or between isolated cloud components, so that the cloud components can realize preset functions. The cloud connector is an abstract concept of a cloud component interface, and a communication mode of an event or a message is specified by adopting three methods of contract connection, bus connection and queue connection.
As shown in fig. 1, a root node is an application of a kappalization component, the component name is a micro service name, the root node is an active component, event information broadcast by all active components in the micro service is analyzed, a cloud component loading build operation of the micro service in fig. 3 is supported, and a cloud component initializing an init, starting an open, running a run, or closing a close operation of the micro service in fig. 4 is supported.
The cloud component tree topology graph is an ordered multi-branch tree, the node sequence of the cloud component tree topology graph is specified by 'contractual architecture configuration', leaf nodes are base components or derived components, and other nodes are composite components; as shown in FIG. 1, the nodes connected to the root node are common service nodes.
The micro-service operation process is simply analyzed, the node structures of fig. 3 and 4 are abstracted from fig. 1, and the ordered operation as shown in fig. 3 or fig. 4 can be abstracted according to contracts in the architecture configuration.
In the topological graph, the movable component internally comprises threads and can actively drive the component to run; the passive component does not contain threads and needs to be handed over to the active component for use; the active component manages its subordinate passive components and broadcasts the state information of the relevant components to all active components. As in fig. 1 (node numbers refer to fig. 3 and 4), node 3 is the active component, broadcasting the event, accompanied by the states of the passive nodes 8 and 12 below it; node 4 is the active component, broadcasting the event, accompanied by the status of the passive nodes 9 and 10 thereunder; node 1 is the root node, and is also the active component, which itself monitors the status of nodes 2 and 5. Each active node can subscribe events of other active nodes, and the node 1 uniformly manages all the active nodes.
2. Cloud component combined model
1) Cloud component portfolio model classification
a) And (3) classification of combination modes: a base component, a derived component, a composite component.
b) Functional characteristic classification: movable assembly, passive subassembly.
2) Model base definition
a) A base component: is an atomic computing unit of a packaged PaaS method which cannot be disassembled; the source of the base component is as follows: multiplexing encapsulation (a method of multiplexing a conventional SCADA), a base method (PaaS platform base method), and event management (handling cloud component events).
b) And (3) deriving components: deriving from the existing base component to realize more detailed service function; similarly, implementing class-derived extensions, such as the front-end processor parameter loader component, is derived from the base load component of the parameter library.
c) A composite component: and a plurality of cloud components coordinate to complete more complex functions and encapsulate the components, so that the resource management and service processing functions are realized.
d) A movable component: and packaging the active object class to realize active multithreading: and the active object class automatically starts a working thread, subscribes messages from the cloud connector of the source end, drives calculation to generate a new message body, and sends the new message body to the component cache or the back-end connector.
e) A passive component: the package "reactor mode class", implements a passive process: when the upper active component requests arrive, the processing program of the passive component receives all the requests by a non-blocking thread by using a multi-path distribution strategy, and then dispatches the requests to the passive component of the passive component or the subordinate passive component for distributed computing processing; the calculation result of the passive component is cached in the component, and when the calculation is completed or driven by a timer, the cached data is sent to the requested active component.
3) Cloud component composition model, composition strategy
a) The combination mode is as follows: combining the base components into derivative components; the base assembly, the derived assembly and the composite assembly are combined into a composite assembly.
b) Functional characteristics: the active component or the passive component can be any one of a base component, a derived component and a composite component.
4) Component threads and events
The movable component contains threads and can actively drive the component to run; the passive component does not contain threads and needs to be handed over to the active component for use; the active component manages its subordinate passive components and broadcasts the state information of the related components to all active components in the form of "events".
The event is a message of a JSON structure and comprises the identity of a component and real-time state information of the component; the module identity comprises a module name, an engineering name, a domain name, an init sequence module entity class, an MD5 abstract of an MD5 connection string of a dynamic library, and module state explains the init, open, run and close states of the module; an active component is in a run state and can be identified by other active components; the passive component is an open state and can be recognized by other components.
3. Real-time monitoring public service model
The invention defines the application entity of the public service model on the real-time monitoring service, including but not limited to the composite components of parameter library, value library, producer, consumer, flow calculation, data processor, alarm and object storage, etc., and the bottom layer uses public micro-services of directory service, event service, distributed real-time database, elastic message queue, etc.; or other common or industry customized common development components; together they constitute a common service model. The development component in the common service model is generally used as a sub-component of a root node in the micro service topological graph, and provides common service support for the monitoring or control application component.
1) Producer assembly
The producer component is used for pushing event information generated in the data processing process and processed data into the message queue, and the producer component provides different implementations for different message queue products, such as an Ali MQ component and a Kafka component. The producer component interface (ipriducer) is used to define the external interfaces of the component:
a) send (topoic, key, mesa, partition): and sending the message, namely sending the message to a specified theme in the message queue, and supporting the function of sending the theme partition. The message sent may specify a key value from which automatic partitioning may occur when no partition is specified.
b) flush (): and refreshing the cache, and refreshing and sending the message currently cached in the sending queue.
Producer components are typically used by other components, and the components themselves are not dependent on other components.
2) Consumer assembly
The consumer component is used for acquiring data to be processed from the elastic message queue according to needs, and injecting the data to the streaming data processing pipeline for data processing, such as an Ali MQ component and a Kafka component. The consumer component interface (iconparent) is used to define the external interfaces of the component:
a) start _ stream (stream): starting a data stream, and starting a data stream subscribed and designated from the message queue; after starting the data stream, the data stream starts to process new data; and topic partition data stream subscription is supported.
b) stop _ stream (stream): and stopping the data flow, canceling the subscription of the specified data flow from the message queue, and after the subscription is canceled, the data flow does not process new data any more.
The consumer component will cooperate with the data flow component. And the consumer component acquires the subscription topic information from the data stream component and injects the message obtained through subscription into the data stream component for processing.
3) Stream computation component
The stream computation component is used to abstract the processing of the data sub-streams and to describe the processing logic for a particular data sub-stream. The data sub-stream may correspond to a topic or a topic partition in the message queue. The data flow components are similar to data pipes, and data flows through the data pipes are processed by processing nodes in the pipes, wherein each data processing node corresponds to a data processor component. Data stream component interface (IStream) is used to define the external interfaces of the component:
a) data processing (process): the data processing interface is used for injecting data into the data pipeline represented by the data assembly, and the injected data is processed by each data processor in the process of flowing through the pipeline.
b) Data stream topic name (topic): and obtaining a theme name corresponding to the data stream.
c) Data stream topic partition (partition): and obtaining a theme partition corresponding to the data stream, and using the theme partition when the data stream needs to be statically partitioned.
The data flow component will cooperate with the consumer component and the data processor component. The data flow component will retrieve the required messages via the consumer component and then inject the information into the data pipe for processing by the respective data processor. The data flow component provides a data processing statistic and monitoring function based on the component state information interface so as to know the data processing condition in real time.
4) Data processor assembly
The data processor component is the core of stream computation microservice development and realizes the specific business data processing function. The cloud component model supports the construction of streaming data processing environments, so that application development can separate technical concerns, and focus on business processing logic development, i.e., the development of data processor components.
The cloud component model provides basic class library support for development of application data processors, and the data processors of all applications can be derived based on KPprocessors and developed as subclasses of the KPprocessors; the model supports the orchestration of multiple data processors to form complex data processing flows, such as sequential data flow processors (for implementing sequential processing of all sub-processors, and exception short-circuit return) and branch data flow processors (for implementing conditional branch processing, where different sub-data processor components may be invoked depending on specified conditions). The data processor component interface (IProcessor) is used to define the external interfaces of the component:
a) message processing (process): the message processing interface performs the actual message processing task and each data processor component will implement the specific message processing task through this interface. The input information of the interface function comprises pre-submitted raw data record information and message processing context information, and the message processing context is used for temporarily sharing processing information among different message processors in the same data stream.
The message processing component will cooperate with the parameter repository component, the state repository component, the alert component, or the object storage component.
5) Parameter library component
The parameter library component encapsulates access interfaces of monitoring control parameters of the distributed real-time database, and provides a uniform parameter access mode for the stream processor component and other service processors. The parameter library is designed based on the snapshot of the fragmented memory. The parameter library component supports automatic loading and increment synchronization of background parameters, supports different storage modes of the parameter library, and provides realization of the parameter library component with a cache function and realization of the parameter library component directly acting for back-end storage. The parameter library component interface (IParamDb) is used to define the external interfaces of the component:
a) get _ table (table _ name): and acquiring the specified parameter table object according to the name. And other components can subsequently acquire corresponding table record information through the acquired parameter table object interface.
b) upd _ table (table _ name, IParamTable): and updating the designated parameter table object in the parameter library.
c) list _ table (): and acquiring a name list of all parameter tables in the parameter library.
d) add _ stabilizer (stabilizer): and registering the parameter event listener, registering monitoring callback interface information to the parameter library, and acquiring corresponding change notification information when the parameter library is changed. After the initial loading of the parameters and after the synchronization of the increments, a parameter library change notification is triggered.
e) del _ listener (listener): and (4) logging off the parameter event listener, and the component does not receive the parameter change notification information after logging off.
f) notify _ event (event): and notifying the parameter event, triggering a parameter change notification event, and calling the callback interface function of the currently registered event listener of each component by the function in sequence.
6) Value library assembly
The value base component encapsulates an access interface of the real-time values of the measuring points of the distributed real-time database, and provides a uniform value (telemetering measuring values and remote signaling states) access mode for the stream processor component and other service processors. The value library component provides different implementation modes, meets different application requirements, and comprises the following steps: the realization of a state library component with a cache function and the realization of direct proxy back-end real-time storage. The numerical library component interface (IValueDb) is used to define the external interfaces of the component:
a) get (key): and acquiring the appointed record according to the key value.
b) batch _ get (keys): and acquiring specified records in batches according to the key value list.
c) selection (condition): and setting query conditions according to the attributes of the records to query the records.
d) put (key, value): the specified record is set according to the key value. If the record in the table exists, the original record is overwritten.
e) update (key, value): the specified record is updated according to the key value. When the record in the table already exists, if the attribute of the original record is contained in the updating information, the attribute in the updating information is used for covering the corresponding attribute in the original record; if the attributes of the original record are not included in the update information, the corresponding attributes in the original record remain unchanged. When no record exists in the table, it is equivalent to a put operation.
The numerical library component cooperates with the data back-end storage component, and the reading of initial data and the persistent storage work of the data are completed through the data back-end storage component interface.
7) Warning component
The alarm component is used for providing alarm information required by generation for the data processor in the process of processing the data stream by the data stream component. The alarm component interface (IAlarm) is used for defining an external interface of a component, and the interface is defined as follows:
a) signal (json): and generating an alarm, and generating corresponding alarm information according to the transmitted alarm context information. The alarm context information needs to include information such as alarm classification, alarm object, alarm time, alarm level, alarm description, etc.
b) commit (): and submitting the alarm, and submitting the generated alarm information to an alarm subject in the elastic message queue.
The alarm component pushes the generated alarm information to the alarm subject in the message queue through the producer component.
8) Object storage component
The object storage component is used for providing the object storage and query functions for the data processor in the process of processing the data flow by the data flow component. The objects of the real-time monitoring system can be collected messages, SVG (scalable vector graphics), services, pictures, audio, video and the like, and the access of an object storage interface of a typical commercial cloud service provider, such as Aliskiu OSS, is supported. The object storage component interface (IObjectMgr) is used to define the external interfaces of the component, as follows:
a) put (path): and submitting the object, storing the object in a mode of simulating a linux system file storage path, and storing the path as a full-mark information string stored by the object.
b) post (path): and maintaining the object.
c) get _ list (path): and acquiring a sub-object information list stored in the marked path of the object storage.
d) get (path): the object is queried.
e) delete (path): and deleting the object.
The object storage component cooperates with the storage data processor component, such as collecting message storage, graph mode change storage, real-time numerical value storage, alarm storage and statistical analysis storage.
When the real-time monitoring micro-service is developed, the available composite components are selected from the public service model, or new composite components are developed according to the interface specification, and then the micro-service can be assembled according to the contractual architecture configuration specification. The microservice may use access interfaces that use other common services, such as directory services, event services. The data processor components of different service types integrate other public services, and can support micro-service clusters to be constructed, such as data acquisition, information aggregation, parallel computation, panoramic monitoring, intelligent alarm and the like; the micro-service can be loaded into a container for operation.
4. Real-time monitoring micro-service component management method
The microservice component management model describes the relationship between a cloud component portfolio model, a public service model, and a public utility model. In the cloud component tree topology graph of the public facility model, a root node is an active component and comprises an event manager which can register an event processor and delete the event processor; the root component sequentially calls the registered event processor to drive event processing, completes analysis of the JSON event set and gives abnormal event information; and the root component recognizes the component exception, and the close of the driving component closes the flow and stops the micro service.
The root component analyzes the cloud component event set according to different requirements, and the functions of event monitoring, thread management and trust authentication are realized:
a) event monitoring: the root node is an active component, uniformly manages the events of all the active components, comprises an event manager, and can register an event processor and delete the event processor. The movable component pushes events of subordinate related components to the root component; the root component analyzes the event set, triggers regularly or abnormally, and issues a conclusion of event analysis to the cloud component event theme of the elastic message queue; and other activity components subscribe the event theme of the cloud component, have abnormal events and drive the operation of the activity components.
b) Thread management: it is the analysis of events broadcast by the associated component at the active component node that drives the activity of the subordinate subcomponents. The active component comprises an active object processor and starts a passive component or an active component associated with thread running to run; the event component can simply analyze the event broadcasted by the associated event component to complete the uploading and downloading of the driving event; an abnormal shutdown of a sub-component may trigger the shutdown of its own component and broadcast an exception event.
c) And (3) trust authentication: and the identity authentication of the component is realized by analyzing the event header information of the associated component. The component trust authentication is simplified into event authentication, and the identity of the component is checked through an event (comprising header information { "head": name { "name:" component name "," MD5": MD5 (engineering name. domain name. init order component entity class corresponding to MD5 connection string of the dynamic library)" }) broadcast by the cloud component. During init operation in fig. 3, the component checking method: firstly, md5 strings of a local dynamic library in the microservice are calculated, then md5 strings of related components are connected according to the sequence of figure 3, and then new header information of the components is calculated according to md5 connection protocol in an event header; and finally, matching the event header information with the newly calculated header information, and executing the init only by the matched components, or else, directly closing.
The real-time monitoring micro-service is a service which is deployed in a Docker container and can independently complete a single monitoring or control function, and the name of the service is the name of a tree topology root component. The Docker image contains the public services and utilities involved in the cloud component model. The mirrored file system comprises a cloud component architecture configuration file, a cloud component registration record file, a dynamic library (or script library) file and a cloud component model driving module.
During monitoring control:
the cloud component model drives the search traversal based on the topological graph, and the operations of orderly loading build, initializing init, starting open, running run, closing close and the like of the components in the micro-service are realized:
1) loading build: processing from the leftmost sub-tree of the root node to the right, and adding a sub-cloud component from a sub-tree root node point cloud component downwards; and loading a dynamic library (or script library) corresponding to the cloud component entity class.
2) Initializing init: processing from the leftmost sub-tree of the root node to the right, and initializing a cloud component from a sub-tree leaf node point cloud component to the root node of the sub-tree; the component interface application handle and configuration parameters of the entity class are initialized.
3) And (3) starting open: and after receiving the notification that all the cloud components init are normal, taking a cloud component topological graph, opening link handles of the cloud components one by one according to the sequence of the init, completing initial loading of monitoring control parameters, and establishing a cloud component connection relation.
4) Running run: after the root component receives the notice that all the cloud components open are normal, a cloud component topological graph is taken, and the active components are driven to run in a multithreading mode according to the reverse order of open; the active component manages the passive component downwards; event communication and processing among cloud components are completed by means of a multi-thread communication technology of a message bus.
5) Close: after receiving the abnormal event notification, any cloud component marks the position of the component on the topological graph, and closes the applications and the link handles of the open cloud components one by one according to the reverse order of the open.
Claims (10)
1. A microservice development framework, characterized by: building a cloud component model; the cloud component model is a distributed componentization development model based on cloud technology.
2. The microservice development framework of claim 1, wherein: the cloud component is a distributed application component based on cloud technology, and is an application component for packaging a real-time monitoring PaaS public service interface access method; the cloud component model includes a public facility model, a cloud component portfolio model, and a public service model.
3. The microservice development framework of claim 2, wherein: the public facility model comprises specification, configuration and cloud component warehouse of the cloud component;
the specification of the cloud component comprises an interface specification, an arranging and assembling specification and a driving operation specification;
the configuration is a contract type architecture configuration made according to the standard constraint, and the configuration structure is as follows: [ component name, component type, component configuration, set of subcomponents ]; the configured contract comprises a prior condition, a posterior condition and an invariance, and defines a component access interface; mapping an ordered multi-branch tree type component topological graph based on contractual architecture configuration, wherein nodes in the topological graph are objects bound by cloud components and cloud connectors, and the cloud connectors are used for realizing communication among the cloud components; the topological graph is used as a guide carrier of the micro service, and the loading, initialization, starting, running and closing operations of the micro service are realized by traversing the topological graph.
4. The microservice development framework of claim 3, wherein: the cloud component warehouse comprises a cloud component registration record, a cloud component dynamic library and a cloud component cache manager;
the configuration structure of the cloud component registration record is [ library, types, md5], the library is a dynamic library name corresponding to the cloud component, and the types are an entity class set of the cloud component type;
and when the micro service is loaded, the corresponding dynamic library is retrieved according to the cloud component name and the registration record, and then the dynamic library is opened and loaded to the micro service.
5. The microservice development framework of claim 3, wherein: in the cloud component combination model, the cloud components are divided into the following parts according to the combination mode: a base component, a derived component, and a composite component;
the base component is an atomic computing unit of a packaged PaaS method;
the derived component is a component derived from an existing base component;
the composite component is a component formed by packaging a plurality of cloud components;
in the topological graph, leaf nodes are base components or derivative components, and other nodes are composite components;
the cloud components are divided into: a movable component and a passive component;
the active component encapsulates an active object class to realize active multithreading processing; the active component manages the subordinate passive components of the active component, and broadcasts the state information of the subordinate components to all the active components;
the passive component encapsulates a reactor mode class to realize passive processing;
the active component and the passive component can be any one of a base component, a derived component and a composite component.
6. The microservice development framework of claim 2, wherein: the public service model is used for defining an application entity used in real-time monitoring business and comprises a parameter library component, a numerical library component, a producer component, a consumer component, a flow calculation component, a data processor component, an alarm component and an object storage component; the common service model also includes common and customized common development components; a component in the common service model to provide common service support for monitoring or control;
the bottom layer of the common service model contains the following services: directory services, event services, distributed real-time databases, and elastic message queues.
7. The microservice development framework of claim 6, wherein: the micro-service is a service which is deployed in a Docker container and independently completes a single monitoring or control function; the microservices may be packaged into components that are loaded into a common service model for integration or access by other microservices.
8. A real-time monitoring implementation method is characterized in that: the microservice development framework of claim 5 is based on building microservices for monitoring and enabling component management of microservices.
9. The real-time monitoring implementation method of claim 8, wherein: the component management of the microservice comprises:
a) event monitoring: the root component corresponding to the root node in the topological graph is an active component, and events of all the active components are managed uniformly; the root component is provided with an event manager used for registering the event processor and deleting the event processor; the movable component pushes the events of the subordinate components to the root component; the root component analyzes the event set, and issues a conclusion of event analysis to a cloud component event theme of the elastic message queue at regular time or according to abnormal triggering; other active components except the root component subscribe to the event theme of the cloud component, and drive the operation of the active components when abnormal events exist;
b) thread management: analyzing the events broadcast by the associated components on the active component nodes and driving the activity of the lower sub-components; the active component comprises an active object processor and starts a passive component or an active component associated with thread running to run; the activity component is also used for analyzing the events broadcasted by the associated activity component and finishing the uploading and downloading of the driving events; the abnormal closing of the sub-component can trigger the closing of the self-component and broadcast an abnormal event; when the upper layer active component requests arrive at the passive component, the passive component receives all the requests by a non-blocking thread by using a multi-path distribution strategy, and then dispatches the requests to the passive component of the passive component or the subordinate passive component; the calculation result of the passive component is cached in the component, and when the calculation is finished or is driven by a timer, the cached data is sent to the requested active component;
c) and (3) trust authentication: the events broadcast by the cloud components comprise MD5 strings, and identity authentication of the components is realized by checking the MD5 strings.
10. The real-time monitoring implementation method of claim 8, wherein: the cloud component model drives the search traversal based on the topological graph to complete the operations of loading, initializing, starting, running and closing of the micro-service:
(1) and (3) loading operation: processing rightwards from the leftmost sub-tree connected with the root node of the multi-branch tree, processing each sub-tree along the direction from the root node of the sub-tree to a leaf node, sequentially loading cloud components corresponding to the nodes according to the processing direction, and loading a dynamic library corresponding to the cloud components;
(2) initialization operation: processing rightwards from the leftmost sub-tree connected with the root node of the multi-branch tree, processing each sub-tree in the direction from the leaf node of the sub-tree to the root node of the sub-tree, and sequentially initializing the cloud components corresponding to the nodes along the processing direction;
(3) and (3) starting operation: after the initialization operation is completed, opening the link handles of the cloud components one by one according to the initialization sequence, completing the loading of the monitoring parameters, and establishing the connection relationship of the cloud components;
(4) and (3) operation: after the starting operation is finished, driving the movable components to run in a multithreading mode according to the reverse order during the starting operation, and finishing the event communication and processing among the cloud components by relying on the multithreading communication technology of the message bus;
(5) closing operation: and after receiving the abnormal event notification of the cloud components, closing the cloud components one by one according to the reverse order of the starting operation.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911097910.5A CN110825356B (en) | 2019-11-12 | 2019-11-12 | Micro-service development framework and real-time monitoring implementation method |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201911097910.5A CN110825356B (en) | 2019-11-12 | 2019-11-12 | Micro-service development framework and real-time monitoring implementation method |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN110825356A true CN110825356A (en) | 2020-02-21 |
| CN110825356B CN110825356B (en) | 2023-04-18 |
Family
ID=69554140
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201911097910.5A Active CN110825356B (en) | 2019-11-12 | 2019-11-12 | Micro-service development framework and real-time monitoring implementation method |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN110825356B (en) |
Cited By (10)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111404757A (en) * | 2020-03-26 | 2020-07-10 | 成都云巢智联科技有限公司 | Cloud-based cross-network application integration system |
| CN111443920A (en) * | 2020-03-25 | 2020-07-24 | 北京奇艺世纪科技有限公司 | Frame migration method and device |
| CN111666090A (en) * | 2020-06-10 | 2020-09-15 | 贵州电子商务云运营有限责任公司 | Online updating support system for application system extension assembly |
| CN111949487A (en) * | 2020-08-14 | 2020-11-17 | 杭州溪塔科技有限公司 | Block chain monitoring system and method with dynamically pluggable modules |
| CN112102008A (en) * | 2020-09-25 | 2020-12-18 | 中国建设银行股份有限公司 | Configurable user behavior acquisition method and device |
| CN112559285A (en) * | 2020-12-08 | 2021-03-26 | 中国联合网络通信集团有限公司 | Distributed service architecture-based micro-service monitoring method and related device |
| CN113434382A (en) * | 2021-07-12 | 2021-09-24 | 建信金融科技有限责任公司 | Database performance monitoring method and device, electronic equipment and computer readable medium |
| CN113495724A (en) * | 2020-03-19 | 2021-10-12 | 中国科学院沈阳自动化研究所 | Micro-service-based industrial Internet of things low-code rapid development system and method |
| WO2021217655A1 (en) * | 2020-04-30 | 2021-11-04 | 深圳中砼物联网科技有限公司 | Software development cooperative control method implemented on basis of service, and computer device and storage medium |
| WO2023184241A1 (en) * | 2022-03-30 | 2023-10-05 | 西门子股份公司 | Microservice orchestration method and apparatus, electronic device, and readable medium |
Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004107162A1 (en) * | 2003-05-19 | 2004-12-09 | Thought, Inc. | Dynamic object-driven database manipulation and mapping system |
| CN106060122A (en) * | 2016-05-20 | 2016-10-26 | 北京奇虎科技有限公司 | Docker container uploading/downloading feature control method and device |
| CN106484533A (en) * | 2016-09-21 | 2017-03-08 | 南方电网科学研究院有限责任公司 | A kind of service modeling system and method based on electric power PaaS cloud platform |
| CN106878393A (en) * | 2017-01-16 | 2017-06-20 | 深圳市商沃科技发展有限公司 | A kind of system based on fusion micro services framework |
| CN107612959A (en) * | 2017-07-21 | 2018-01-19 | 哈尔滨工程大学 | A kind of cloud service platform based on cloud micro services Self management |
| CN108681479A (en) * | 2018-05-17 | 2018-10-19 | 中国科学院软件研究所 | A kind of data-oriented excavates the resource regulating method of cloud |
-
2019
- 2019-11-12 CN CN201911097910.5A patent/CN110825356B/en active Active
Patent Citations (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO2004107162A1 (en) * | 2003-05-19 | 2004-12-09 | Thought, Inc. | Dynamic object-driven database manipulation and mapping system |
| CN106060122A (en) * | 2016-05-20 | 2016-10-26 | 北京奇虎科技有限公司 | Docker container uploading/downloading feature control method and device |
| CN106484533A (en) * | 2016-09-21 | 2017-03-08 | 南方电网科学研究院有限责任公司 | A kind of service modeling system and method based on electric power PaaS cloud platform |
| CN106878393A (en) * | 2017-01-16 | 2017-06-20 | 深圳市商沃科技发展有限公司 | A kind of system based on fusion micro services framework |
| CN107612959A (en) * | 2017-07-21 | 2018-01-19 | 哈尔滨工程大学 | A kind of cloud service platform based on cloud micro services Self management |
| CN108681479A (en) * | 2018-05-17 | 2018-10-19 | 中国科学院软件研究所 | A kind of data-oriented excavates the resource regulating method of cloud |
Non-Patent Citations (5)
| Title |
|---|
| 吴海燕,任午令: "网络化制造与ASP应用的标准和规范技术的探讨" * |
| 庞世春;刘淑芬;: "一种领域建模工具的研究与实现" * |
| 张晶;黄小锋;: "一种基于微服务的应用框架" * |
| 杨俊伟;纪鑫;胡强新;: "基于微服务架构的电力云服务平台" * |
| 王盛义;樊国柱;: "SQLite在嵌入式认证授权系统中的应用" * |
Cited By (13)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN113495724A (en) * | 2020-03-19 | 2021-10-12 | 中国科学院沈阳自动化研究所 | Micro-service-based industrial Internet of things low-code rapid development system and method |
| CN111443920A (en) * | 2020-03-25 | 2020-07-24 | 北京奇艺世纪科技有限公司 | Frame migration method and device |
| CN111443920B (en) * | 2020-03-25 | 2023-10-13 | 北京奇艺世纪科技有限公司 | Frame migration method and device |
| CN111404757A (en) * | 2020-03-26 | 2020-07-10 | 成都云巢智联科技有限公司 | Cloud-based cross-network application integration system |
| WO2021217655A1 (en) * | 2020-04-30 | 2021-11-04 | 深圳中砼物联网科技有限公司 | Software development cooperative control method implemented on basis of service, and computer device and storage medium |
| CN111666090A (en) * | 2020-06-10 | 2020-09-15 | 贵州电子商务云运营有限责任公司 | Online updating support system for application system extension assembly |
| CN111666090B (en) * | 2020-06-10 | 2022-09-20 | 贵州电子商务云运营有限责任公司 | Online updating support system for application system extension assembly |
| CN111949487A (en) * | 2020-08-14 | 2020-11-17 | 杭州溪塔科技有限公司 | Block chain monitoring system and method with dynamically pluggable modules |
| CN112102008A (en) * | 2020-09-25 | 2020-12-18 | 中国建设银行股份有限公司 | Configurable user behavior acquisition method and device |
| CN112559285A (en) * | 2020-12-08 | 2021-03-26 | 中国联合网络通信集团有限公司 | Distributed service architecture-based micro-service monitoring method and related device |
| CN112559285B (en) * | 2020-12-08 | 2023-05-30 | 中国联合网络通信集团有限公司 | Micro-service monitoring method and related device based on distributed service architecture |
| CN113434382A (en) * | 2021-07-12 | 2021-09-24 | 建信金融科技有限责任公司 | Database performance monitoring method and device, electronic equipment and computer readable medium |
| WO2023184241A1 (en) * | 2022-03-30 | 2023-10-05 | 西门子股份公司 | Microservice orchestration method and apparatus, electronic device, and readable medium |
Also Published As
| Publication number | Publication date |
|---|---|
| CN110825356B (en) | 2023-04-18 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN110825356B (en) | Micro-service development framework and real-time monitoring implementation method | |
| Sun et al. | An open IoT framework based on microservices architecture | |
| Viennot et al. | Synapse: a microservices architecture for heterogeneous-database web applications | |
| US9184988B2 (en) | Providing configurable workflow capabilities | |
| CN102349056B (en) | Dynamically composing data stream processing applications | |
| CN103336813A (en) | Data integrated management scheme for Internet of Things based on middleware framework | |
| US8443374B2 (en) | Business application integration adapters management system | |
| Gurgen et al. | SStreaMWare: a service oriented middleware for heterogeneous sensor data management | |
| Firouzi et al. | Architecting iot cloud | |
| CN109656963B (en) | Metadata acquisition method, apparatus, device and computer readable storage medium | |
| CN107103064B (en) | Data statistical method and device | |
| CN103338135B (en) | A kind of method for real-time monitoring of cluster storage capacity | |
| CN110908641B (en) | Visualization-based stream computing platform, method, device and storage medium | |
| Akpınar et al. | Thingstore: A platform for internet-of-things application development and deployment | |
| CN103390018A (en) | Web service data modeling and searching method based on SDD (service data description) | |
| CN114153920A (en) | Big data edge platform and method | |
| Kruger et al. | Evaluation of JADE multi-agent system and Erlang holonic control implementations for a manufacturing cell | |
| CN112035466B (en) | External index development framework for block chain query | |
| CN114443599A (en) | Data synchronization method and device, electronic equipment and storage medium | |
| CN106202585B (en) | The more scene Multi-state data systems of electric power and management method | |
| Sakr et al. | Big data processing systems: state-of-the-art and open challenges | |
| Abidi et al. | Towards an Environment for doing Data Science that runs in Browsers | |
| Kajola | IEC 61499 based distributed data collection framework for multivariate time series data | |
| Xiao et al. | NMSTREAM: A scalable event-driven ETL framework for processing heterogeneous streaming data | |
| Yahia | A language-based approach for web service composition |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |