Middleware management method and device

Abstract

The invention discloses a middleware management method and device, relates to the technical field of middleware, and mainly aims to realize unified management and configuration of middleware, reduce the management and maintenance difficulty of the middleware and improve the flexibility and convenience of flow management. According to the main technical scheme, each middleware instance is divided into one or more logic clusters according to operation characteristics of each service, wherein the operation characteristics are used for representing characteristics related to high-reliability operation of the services; general configuration setting is carried out on the one or more logic clusters to obtain global configuration information containing all the logic clusters, and the general configuration setting at least comprises setting of physical mapping and routing strategies of middleware instances docked by all the services in the running process; and respectively issuing the global configuration information to each middleware instance contained in each logic cluster so as to run according to the global configuration information when a service butted with the middleware instance contained in each logic cluster is started. The middleware management method and device are used for middleware management.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of middleware, and in particular to a middleware management method and device. BACKGROUND

[0002] With the rapid development of the Internet and information technology, middleware plays an increasingly important role in modern systems. Middleware is a software layer between application services and data storage, which provides services such as data caching, message passing, database connection, etc. to help application services run more efficiently and reliably. However, as business needs continue to grow and become more complex, the deployment and management of middleware have become increasingly complex.

[0003] Currently, due to the differences in deployment architecture and service distribution of different middleware, the management of middleware relies more on the built-in console or command line operation, which leads to a lack of unified management and configuration of middleware, making the management and maintenance of middleware more difficult and not conducive to traffic governance of middleware. SUMMARY

[0004] In view of the above problems, the present application provides a middleware management method and device, the main purpose of which is to realize unified management and configuration of middleware, reduce the difficulty of middleware management and maintenance, and improve the flexibility and convenience of traffic governance.

[0005] To solve the above technical problems, the present application proposes the following solutions:

[0006] In a first aspect, the present application provides a middleware management method, which comprises:

[0007] dividing each middleware instance into one or more logical clusters according to the running characteristics of each business, the running characteristics being used to represent characteristics related to high reliability operation of the business;

[0008] performing general configuration settings on one or more of the logical clusters to obtain global configuration information containing each of the logical clusters, the general configuration settings at least including setting the physical mapping and routing strategy of the middleware instance interfaced by each business during operation;

[0009] distributing the global configuration information to each middleware instance contained in each of the logical clusters, respectively, so that when the business interfaced by the middleware instance contained in each of the logical clusters is started, it runs according to the global configuration information.

[0010] In a second aspect, the present application provides a middleware management device, which comprises:

[0011] The dividing unit is configured to divide each middleware instance into one or more logical clusters according to operation characteristics of each service, wherein the operation characteristics are used to represent characteristics related to high-reliability operation of the service.

[0012] The configuring unit is configured to perform general configuration setting on the one or more logical clusters obtained by the dividing unit to obtain global configuration information containing each logical cluster, wherein the general configuration setting at least includes setting physical mapping and routing strategy of the middleware instance interfaced by each service during operation.

[0013] The processing unit is configured to respectively distribute the global configuration information obtained by the configuring unit to each middleware instance contained in each logical cluster, so that each middleware instance contained in each logical cluster operates according to the global configuration information when the service interfaced by the middleware instance is started.

[0014] To achieve the above-mentioned purpose, according to a third aspect of the present application, a storage medium is provided, which comprises a stored program, wherein the storage medium controls a device where the storage medium is located to execute the middleware management method of the first aspect when the program is run.

[0015] To achieve the above-mentioned purpose, according to a fourth aspect of the present application, a processor is provided, which is used to run a program, wherein the program executes the middleware management method of the first aspect when the program is run.

[0016] According to the technical solution, the middleware management method and device provided by the present application are used to divide each middleware instance into one or more logical clusters according to operation characteristics of each service when the middleware needs to be managed, wherein the operation characteristics are used to represent characteristics related to high-reliability operation of the service, then perform general configuration setting on the one or more logical clusters to obtain global configuration information containing each logical cluster, wherein the general configuration setting at least includes setting physical mapping and routing strategy of the middleware instance interfaced by each service during operation, and finally respectively distribute the global configuration information to each middleware instance contained in each logical cluster, so that each middleware instance contained in each logical cluster operates according to the global configuration information when the service interfaced by the middleware instance is started. Through the technical solution provided by the present application, each middleware instance can be divided into logical clusters, and unified management and configuration of multiple middleware instances can be realized through general configuration of the logical clusters, which reduces repeated work of configuration of a single middleware instance, and after configuration, the configuration information can be automatically distributed to the corresponding middleware instance, avoiding the tedious process of manual configuration one by one, effectively reducing the difficulty of management and maintenance of the middleware, and improving the flexibility and convenience of traffic management.

[0017] The above description is only a summary of the technical solutions of the present application. In order to enable a more thorough understanding of the technical means of the present application, the present application can be implemented according to the content of the specification, and in order to enable the above and other purposes, characteristics and advantages of the present application to be more obvious and easy to understand, the following specific embodiments of the present application are described. BRIEF DESCRIPTION OF DRAWINGS

[0018] Various other advantages and benefits will become apparent to those of ordinary skill in the art upon reading the following detailed description of the preferred embodiments. The accompanying drawings are included to provide a description of the preferred embodiments and are not meant to limit the present application. Moreover, the same reference numerals in the accompanying drawings indicate the same or similar components. In the drawings:

[0019] Figure 1 A flow chart of a middleware management method provided by an embodiment of the present application is shown;

[0020] Figure 2 A flow chart of another middleware management method provided by an embodiment of the present application is shown;

[0021] Figure 3 A component block diagram of a middleware management device provided by an embodiment of the present application is shown;

[0022] Figure 4 A component block diagram of another middleware management device provided by an embodiment of the present application is shown;

[0023] Figure 5 An architecture example diagram of another middleware management method provided by an embodiment of the present application is shown. DETAILED DESCRIPTION

[0024] Exemplary embodiments of the present disclosure will be described more fully hereinafter with reference to the accompanying drawings. Although exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided so that the present disclosure can be more thoroughly understood and the scope of the present disclosure can be accurately conveyed to those skilled in the art.

[0025] At present, due to different middleware in deployment architecture and service distribution, the management of middleware relies more on the built-in console or command line operation, and each middleware needs to write a separate operation manual to assist the management personnel in the management of different middleware. This leads to the lack of unified management and configuration of middleware, increases the difficulty of management and maintenance of middleware, and is not conducive to traffic governance.

[0026] The inventor invents, can divide logical clusters in combination with the running characteristics of each middleware, obtain global configuration information by setting the general configuration of the level of logical clusters, and then respectively distribute the global configuration information to each middleware included in each logical cluster, so that each middleware connected by the business runs according to the corresponding configuration information at the business startup. In this way, the unified management and configuration of the middleware instance are realized, the difficulty of management and maintenance of the middleware is effectively reduced, and the flexibility and convenience of traffic management are improved.

[0027] Based on the above considerations, the embodiments of the present application provide a middleware management method, which can realize the unified management and configuration of the middleware, reduce the difficulty of management and maintenance of the middleware, and improve the flexibility and convenience of traffic management. The execution subject of the embodiments of the present application can be a middleware management platform in a micro-service architecture or a distributed system, and the specific execution steps are as shown in Figure 1

[0028] 101. Divide each middleware instance into one or more logical clusters according to the running characteristics of each business.

[0029] ​In this embodiment, it should be noted that the middleware instance refers to the middleware service deployed in the distributed system or microservice architecture for the purpose of achieving the set function, including but not limited to database, cache, message queue, etc. Each middleware instance has its own independent running environment and configuration, and can serve different business applications or different parts of the same business application. For example, a large website can deploy multiple caches to distribute the cache read-write pressure, or deploy multiple databases to implement data multi-active in different places, etc. The running characteristics are used to represent the characteristics related to the high reliability of the business running. Since the high reliability of the business refers to the ability of the business to have high availability and fault tolerance during running, that is, the ability to continuously provide services within a predetermined time, and the ability to continue to perform the expected function when facing errors, that is, no interruption or minimal impact. Therefore, each business can be analyzed in advance to identify the corresponding key running characteristics, including but not limited to feature analysis from the dimensions of role importance, delay sensitivity, and error tolerance, etc. Among them, the role importance is used to represent the importance of the business quantified based on the business level set by the business party or combined with the user usage of each business, and the related running characteristics can be business level, user usage frequency, etc. The delay sensitivity is used to represent the tolerance of the business to the response time, and the related running characteristics can be response time requirement, user churn rate, etc. The error tolerance is used to represent the tolerance degree of the business interruption, and the related running characteristics can be the maximum allowed time required for system recovery, the tolerance range of data loss, etc. Specifically, the specific standards for reliability division can be set in advance, such as threshold, level, etc. Based on the results of the feature analysis, the classification of the running requirements of each business can be achieved, which can be one reliability level corresponding to one running requirement. For example, the running requirements of the high-reliability business: physical cluster deployment in multiple availability zones (such as city dual-active) or cross-region (multi-active in different places), the running requirements of the medium-reliability business: single-availability-zone deployment, or cross-availability-zone but allowing temporary interruption; the running requirements of the low-reliability business: single-availability-zone deployment of the physical cluster without redundancy. After determining the running requirements, the logical cluster is divided in combination with the physical cluster information of each middleware instance. The mapping strategy between the running characteristics and / or the physical cluster information and the logical cluster can also be set in advance through an automated tool or algorithm, and each middleware instance can be automatically classified into the corresponding logical cluster through the set mapping strategy when dividing the logical cluster. For this, the present embodiment is not limited.

[0030] For example, the specific division of the reliability level involved in the role importance, delay sensitivity, and error tolerance is shown in Table 1:

[0031] Table 1

[0032]

[0033]

[0034] It should be noted that for the division of reliability levels, at least two of the role importance, delay sensitivity and error tolerance can meet the conditions to meet the corresponding reliability level, or all of them meet the conditions to meet the corresponding reliability level. For this, the present embodiment is not limited.

[0035] 102. A general configuration setting is performed on one or more logical clusters to obtain global configuration information containing each logical cluster.

[0036] Since in step 101, the logical cluster is determined by the business operation requirement combining the role importance, delay sensitivity and error tolerance, and the middleware instance is classified and divided in combination with the physical cluster information of the middleware instance, one or more logical clusters are obtained. The general configuration setting refers to the configuration operation of each middleware instance in each logical cluster, and the configuration setting operation is used to set the physical mapping, routing strategy, priority, etc. of the middleware instance to which each business is connected in running. In this step, a general configuration template corresponding to the logical cluster can be established, and the general configuration template at least includes the physical mapping and the routing strategy. The physical mapping and the routing strategy are the core configuration contents of the middleware management, and both of them jointly determine how the business interacts with the middleware instance in running. The physical mapping refers to the corresponding relationship between the physical cluster of the middleware instance and the logical cluster where it is located, which is used to map the abstract demand of the logical cluster to the specific physical resource (such as geographical location, hardware performance, network topology, etc.), and ensure the matching of business demand and physical resource. The routing strategy refers to the rule of forwarding business requests between multiple middleware instances, which can be set according to business demand, and specifically includes access mode and access authority. The access mode is used to decide how to distribute requests among middleware instances, including but not limited to direct connection, shunt and local priority.

[0037] Direct connection refers to that the business application directly establishes connection with a specific middleware instance for communication, which is used to ensure high availability, especially in the scene where the delay sensitivity is not high but the reliability requirement is extremely high. For example, in an online bank transaction system, some key operations (such as account balance inquiry) need extremely high reliability guarantee, at this time, it may be selected to be directly connected to the database instance cluster configured with the highest redundancy level, so as to ensure that even in the case of network fluctuation or other abnormal conditions, the user's query request can be quickly responded without interruption.

[0038] Shunting is a method of distributing business application requests to multiple middleware instances through certain algorithms (such as polling, least connections, etc.) to achieve load balancing, avoid single node overload, and improve the overall performance and stability of the system. For example, in a large e-commerce platform cache system, in order to cope with high concurrency read and write operations, user requests can be dispersed to multiple cache servers through shunting, which not only reduces the pressure on a single server, but also speeds up data reading and improves user experience.

[0039] Local priority, on the other hand, is a strategy designed to reduce network latency, which first attempts to connect to the middleware instance closest in geographical location or within the same data center. It is particularly suitable for scenarios where response time is extremely sensitive, such as an international bank providing online foreign exchange trading services to customers around the world. Due to the volatility and real-time nature of the foreign exchange market, there is a high demand for response speed for trading requests. Any delay can cause customers to miss the best trading opportunity or suffer unnecessary losses. Therefore, when a customer initiates a foreign exchange trading service or request, it first attempts to send the request to the data center closest to the customer's physical location for processing.

[0040] Access permissions are controls about who is allowed to do what, such as defining different roles or service access levels to middleware instance resources, including but not limited to read-only, write-only, and read-write, to ensure data security and operational compliance.

[0041] In addition, in order to reflect the priority of the configuration, the general configuration template can also include the deployment level of the middleware instance connected by each business runtime, such as setting the default level, service level, and project level. The priority of the project level is the highest, the priority of the service level is the second, and the priority of the default level is the lowest. The present embodiment is not limited in this regard.

[0042] To improve the efficiency of the configuration, the step can also pre-develop a configuration generator to automatically generate corresponding configuration information according to the running characteristics of the logical clusters and the corresponding business requirements, to ensure the standardization and consistency of the global configuration information. Specifically, the running characteristics of different logical clusters and the corresponding business requirements are determined, and the business requirements refer to the specific performance of the running characteristics, that is, the configuration requirements of the business to the middleware instance. Based on the running characteristics and the corresponding business requirements, a series of predefined configuration templates are created, which cover all possible scenario combinations and contain preferred configuration suggestions for certain business requirements. The configuration suggestions can be suggestions for which running characteristic combinations the business requirements are applicable to. For example, Template A (high role importance + low delay sensitivity): resource allocation: high CPU / memory quota, dedicated node; network strategy: local priority routing, high bandwidth guarantee; fault tolerance mechanism: multi-redundant redundancy, automatic fault switching. Template B (low role importance + high delay tolerance): resource allocation: shared resource pool, dynamic scaling; network strategy: low-cost routing, relaxed bandwidth limit; fault tolerance mechanism: single-replica deployment, regular backup. The configuration generator can be implemented through a scripting language (such as Python), a configuration management tool (such as Ansible, Terraform), or a specially developed application.

[0043] 103. The global configuration information is respectively distributed to each middleware instance contained in each logical cluster, so that when the business connected by the middleware instance contained in each logical cluster is started, it runs according to the global configuration information.

[0044] Since the execution subject of the embodiment is a middleware management platform in a micro-service architecture or a distributed system, in this step, ETCD or Spring Cloud Config can be used as the configuration center of the micro-service architecture or the middleware management system to store the global configuration information generated in step 102, so as to ensure centralized management and version control of the configuration. The configuration center can distribute corresponding configuration information to each middleware instance. Specifically, a unique identity such as UUID, instance ID, etc. can be assigned to each middleware instance, which is automatically generated and registered to the configuration center when the middleware instance is initialized or deployed. The corresponding part of the configuration information of each middleware instance is filtered from the global configuration information through the identity, and is distributed to the corresponding middleware instance, so that each middleware instance included in each logical cluster can run according to the global configuration information when the business connected by the middleware instance is started. The filtering process can be realized by writing a script or using the filtering query function provided by the configuration center, and the distribution process can be realized by determining the current state and location information of the middleware instance through the physical cluster information of the middleware instance. It should be noted that the configuration center also needs to support real-time push configuration update, so that when the global configuration information changes, the related middleware instance can be immediately notified to apply the updated configuration information.

[0045] In order to reduce the influence of configuration information issuing and updating on service performance, and guarantee the continuity and response speed of the service. In this step, a corresponding lightweight network agent can be selected or customized in advance according to the requirements of each service. The lightweight network agent is located between the service and the middleware instance, and each middleware instance corresponds to one or a group of lightweight agents. When the lightweight network agent starts, it registers itself with the configuration center mentioned above through the identity, and pulls the part of configuration information corresponding to the middleware instance from the configuration center. When a service request of a certain service is monitored, the lightweight network agent startup forwards the service request to the specific middleware instance according to the pulled part of configuration information, the middleware instance processes the service request and returns the response, and the lightweight network agent startup returns the response to the service. Since the configuration information contains the physical mapping of the middleware instance to which each service is connected in runtime, routing strategy and the like, when the service starts, the lightweight network agent is automatically injected through an automatic script, so that the dynamic routing, traffic control and fault switching functions can be realized through the lightweight network agent, further improving the high availability of the service. The lightweight network agent is separately deployed, including but not limited to Envoy, Linkerd or Nginx, etc. Each agent mainly serves a specific one or a group of middleware instances, and the target service usually does not directly communicate with the middleware instance, but indirectly accesses these services through the lightweight network agent, that is, the lightweight network agent listens to the request of the target service to the target middleware instance, and forwards the request to each middleware instance connected by the service, so that each middleware instance runs according to the global configuration information.

[0046] Based on the above Figure 1 It can be seen from the implementation mode that the middleware management method provided by the application is that when the middleware needs to be managed, first, the middleware instances are divided into one or more logical clusters according to the running characteristics of each service, the running characteristics are used to represent the characteristics related to the high reliability running of the service, then the one or more logical clusters are subjected to general configuration processing to obtain global configuration information containing each logical cluster, the general configuration processing at least includes the physical mapping of the middleware instance to which each service is connected in runtime and the routing strategy, and finally the global configuration information is issued to each middleware instance contained in each logical cluster, so that when the service connected by the middleware instance contained in each logical cluster starts, it runs according to the global configuration information. Through the technical solution provided by the application, each middleware instance can be divided into logical clusters, and the unified management and configuration of multiple middleware instances can be realized through the general configuration of the logical clusters, which reduces the repeated work of the configuration of the single middleware instance, and after the configuration, the configuration information can be automatically issued to the corresponding middleware instance, avoiding the tedious process of manual configuration one by one, effectively reducing the difficulty of management and maintenance of the middleware, and improving the flexibility and convenience of traffic management.

[0047] Further, the preferred embodiment of the present application is a detailed description of the process of middleware management based on the above Figure 1 The specific steps are shown in 201-208. Figure 2

[0048] 201. Determine the running requirements of each middleware instance according to the role importance, delay sensitivity, and error tolerance of each service.

[0049] In this step, the role importance can be determined by the service level set by the service party, or the importance of the role can be quantified using a scoring system (such as 1-5 points) combined with the user frequency of each service. For example, services are divided into core services, important services, and general services, the highest resource guarantee is allocated to core services to ensure their stable operation, important services follow, and general services are the last.

[0050] For delay sensitivity, the business process can be analyzed to identify the tolerance of the service to response time requirements, i.e., to identify which links have strict requirements for response time, such as real-time transactions and instant messaging services. The response time requirement is negatively correlated with the delay sensitivity. That is, the higher the service requirement for response time, the lower the delay sensitivity, and vice versa. The user's perception of delay can also be understood through questionnaires or user feedback to set an acceptable response time range, and the tolerance of the service to response time can be divided by the response time range, such as the transaction system requiring low delay, which has a higher requirement for response time, i.e., a low tolerance for response time requirements, while data analysis can accept higher delay, which has a lower requirement for response time, i.e., a high tolerance for response time requirements.

[0051] For error tolerance, the maximum allowed time required for system recovery or the tolerance range of data loss can be analyzed and combined with SLA settings, i.e., to determine the maximum allowed time required for system recovery and the tolerance range of data loss to quantify the tolerance of the service to interruption, and based on this tolerance, different services are set with service level agreement (SLA) to clearly define error tolerance and recovery requirements. The interruption tolerance is positively correlated with the error tolerance. That is, the higher the tolerance of the service to error, the higher the tolerance of the service to interruption, and vice versa. For example, a key service requires high error tolerance, i.e., zero tolerance, while a non-key service requires low error tolerance, i.e., a short interruption.

[0052] ​After determining the role importance, delay sensitivity, and error tolerance of each service, the numerical values of the specific features included in each service can be compared with the corresponding division threshold values set for each service. Based on the comparison results, the corresponding reliability level is determined, and the corresponding operation requirements are determined accordingly. The operation requirements are used to represent the specific needs and expected behavior standards of the middleware instance during service operation, such as the need to set up several caches, databases, and other similar types of caches, to achieve city dual-active, multi-active, and other similar architectures, to ensure that they can efficiently and stably support service operation.

[0053] For example, in Table 1, the operation requirements and configuration strategies of the middleware instance of an e-commerce platform are taken as an example:

[0054] In an e-commerce platform, the reliability requirements of different business modules for middleware are significantly different. For the payment system (core business), the role importance is the highest (5 points), and it needs to be guaranteed 7x24 hours available, the response time requirement is <100ms, and the error tolerance is zero (RTO <1 minute). Therefore, the payment system can use a city dual-active MySQL cluster and a multi-active Kafka cluster in different regions, combined with the local priority strategy and cross availability zone disaster recovery switching, to ensure the strong consistency and high availability of transaction data. The commodity recommendation system (important business) has a medium role importance (3 points), the response time is allowed to be <500ms, and the disaster recovery time is <5 minutes. It can be configured as a single availability zone Redis cache (direct connection strategy) and a single availability zone MongoDB replica set, allowing short-time fault recovery and cache backup to balance performance and cost. The log aggregation system (general business) has the lowest reliability requirement (1 point), tolerates >1s delay and data loss within 30 minutes, and can use a single availability zone Elasticsearch and RabbitMQ without redundant deployment, only retaining basic monitoring. It should be noted that the partitioning standards for high, medium, and low descriptions involved in role importance, delay sensitivity, and error tolerance can be set according to industry standards or customized according to needs. This embodiment does not limit this.

[0055] For example, for custom settings:

[0056] Role importance: high: business income proportion >50%, user coverage rate >90%; medium: business income proportion 10%-50%, user coverage rate 50%-90%; low: business income proportion <10%, user coverage rate <50%.

[0057] Delay sensitivity: high: users are sensitive to delay perception (such as real-time video call delay >1 second, which is complained); medium: users have moderate delay perception (such as web page loading delay >3 seconds, which leads to an increase in bounce rate); low: users have low delay perception (such as background task delay does not affect user experience).

[0058] Error tolerance: High: Allowable interruption time ≤ 5 minutes, data loss ≤ 1 minute; Medium: Allowable interruption time ≤ 30 minutes, data loss ≤ 5 minutes; Low: Allowable interruption time ≤ 24 hours, data loss ≤ 1 hour.

[0059] 202. Obtain the physical cluster information of each middleware instance.

[0060] In this step, automated tools such as Zabbix and Prometheus are used to monitor middleware instances and obtain corresponding physical cluster information. Specifically, a detailed configuration management database can be maintained to record information such as the physical location, hardware configuration, software version, and network configuration of each middleware instance. At the same time, the instances are tagged with tags such as geographical location, hardware specifications, and business line to which they belong, which serve as the physical cluster information for each middleware instance.

[0061] 203. Based on operational requirements and physical cluster information, divide each middleware instance into one or more logical clusters.

[0062] In step 201 above, the operational requirements for each service have been specifically defined, therefore,

[0063] In this step, logical clusters can be divided based on the operational requirements of each service and the specific conditions of the physical clusters. Specifically, cluster information for each physical cluster can be obtained, including but not limited to cluster ID, middleware type, environment, domain / availability zone, data center / region, hardware configuration, network configuration, and status information. After obtaining the cluster information, each middleware instance can be divided into one or more logical clusters according to the operational requirements. For example, for high-reliability services, multiple physical clusters capable of achieving dual-active operation within the same city or multi-active operation across different locations can be deployed to ensure disaster recovery across availability zones / regions. These physical clusters can be selected with high-performance hardware (such as SSDs and 10 Gigabit Ethernet cards) and redundant network links. For medium-reliability services, logical clusters can be deployed with physical clusters in a single availability zone or across availability zones, and these physical clusters have medium-performance hardware (such as SAS hard drives and gigabit Ethernet cards). For low-reliability services, physical clusters in a single availability zone can be deployed without redundancy, and these physical clusters can be selected with low-cost hardware (such as HDDs and 100 Mbps Ethernet cards). This multi-active architecture associates physical clusters of the same middleware type distributed across different domains or availability zones into a single logical cluster, enabling fine-grained middleware traffic management and high availability. In the specific logical cluster partitioning process, technologies such as Kubernetes tags and AWS ECSTAsk Definitions can be used to logically group middleware instances, resulting in logical clusters.

[0064] 204. Perform general configuration processing on one or more logical clusters to obtain global configuration information containing each logical cluster.

[0065] This step combines the description of step 102 in the above method, and the same content will not be repeated here. It should be noted that in this step, the routing policy includes access methods and access permissions. Access methods include direct connection, traffic splitting, and local priority, and access permissions include read-only, write-only, and read-write.

[0066] 205. For each middleware instance contained in each logical cluster, obtain the identity identifier of each middleware instance.

[0067] In this step, when the middleware instance starts for the first time, an initialization script or configuration management tool such as Ansible or Chef can automatically generate and register a unique identifier, such as a UUID or instance ID, in the configuration center. Simultaneously, tags and metadata, such as service name, version number, environment (production / test), and region, can be attached to each middleware instance to facilitate the filtering of partial configuration information corresponding to each middleware instance in step 206.

[0068] 206. Filter the global configuration information according to the identity identifier, and distribute the filtered configuration information to each middleware instance according to the identity identifier, so as to serve as the running configuration information of each middleware instance, so that when the business connected to each middleware instance starts, it runs according to the running configuration information corresponding to each middleware instance.

[0069] In this step, since the corresponding middleware instance can be identified through its identity, one or more configuration templates can be maintained in the configuration center to quickly filter out the parts corresponding to each middleware instance from the global configuration information. These templates contain variable types that can be dynamically populated based on the identity. Alternatively, configuration fragments matching the identity and the additional tags or metadata mentioned in step 205 can be extracted from the global configuration information; these are the partial configuration information corresponding to each middleware instance. Furthermore, partial configuration information can be encrypted to ensure the security of the transmission process when pushing it to the corresponding middleware instance. During the distribution process, the current status and location information of the middleware instance can be determined from the physical cluster information, and partial configuration information can be pushed to the corresponding middleware instance based on the location information.

[0070] Further, before steps 205-206, in order to realize the refinement of middleware management, the general configuration further includes the deployment level of the relevant middleware instance at runtime of each service. The global configuration information is filtered according to the identity, and the filtered part of the configuration information is distributed to each middleware instance according to the identity, including: obtaining the priority order corresponding to the deployment level; according to the priority order, the global configuration information is filtered according to the identity, and the filtered part of the configuration information is distributed to each middleware instance according to the identity.

[0071] In this step, the deployment level is used to represent the priority order of the configuration settings of the middleware instance interfaced by each service at runtime in different environments or application scenarios, which at least includes the default level, the service level and the project level. Among them, the default level is the basic configuration, which is applicable to all services and projects, and contains the most common settings, such as the basic format of log recording, the default timeout, etc. The service level covers the configuration of a specific service, with a higher priority than the default level, and is used to define the behaviors specific to the service, such as database connection strings, inter-service communication protocols, etc. The project level has the highest priority, is customized for a specific project, and covers or supplements the service level and default level configurations to meet the unique needs of the project, such as specific API keys, environment variables, etc.

[0072] And for the part of the configuration information of each middleware instance filtered from the global configuration information according to the priority order and the identity, different levels of configuration can be stored in the configuration center, each level of configuration maintains one or more sets of configuration templates, and each level of configuration has a clear namespace or label to distinguish, the association relationship between the identity and the deployment level is pre-built, the corresponding level of configuration is found through the association relationship, and the template is used to dynamically fill in the corresponding variable to obtain the filtered part of the configuration information. Specifically, the identity is associated with the corresponding configuration in advance, and the configuration center is allocated with independent namespace or label for different levels of configuration. After the identity of each middleware instance is determined, the corresponding configuration level, i.e. the default level, the service level or the project level, can be determined through the association relationship, so as to determine the priority order of each middleware instance. According to the priority order, the part of the configuration information of each middleware instance can be filtered from the global configuration information through the identity.

[0073] 207、When the startup feedback of the target service is monitored, the lightweight network agent is automatically integrated into the target service.

[0074] In this step, the target service refers to the specific service that is currently intended to be deployed, managed and optimized. When the startup feedback of the target service is monitored, a lightweight agent can be declared in the Dockerfile or the Kubernetes Pod definition as a sidecar to be deployed with the service, i.e., the lightweight network agent is automatically integrated into the target service, so that each service has a corresponding lightweight network agent. The lightweight network agent includes but is not limited to Envoy, Linkerd or Nginx, etc. Among them, the target service calls the target middleware instance to which it is connected through a request, and the lightweight network agent listens to the request of the target service to the target middleware instance and forwards the request to the target middleware instance, so that the target middleware instance runs according to the target running configuration information corresponding to the target middleware instance.

[0075] 208、Determine the target middleware instance connected to the target service, call the lightweight network agent to listen to the request of the target service to the target middleware instance, and forward the request to the target middleware instance, so that the target middleware instance runs according to the target running configuration information corresponding to the target middleware instance.

[0076] In this step, the lightweight agent can automatically discover the target middleware instance that needs to be proxied corresponding to the target service through DNS or service registry, etc. According to the target running configuration information, the lightweight agent dynamically adjusts its proxy behavior, such as routing specific types of requests to specified middleware instances, etc. Thus, through the lightweight network agent, functions such as dynamic routing, traffic control and fault switching are realized, further improving the high availability of the service.

[0077] Further, before listening to the request of the target service to the target middleware instance through the lightweight network agent and forwarding the request to the target middleware instance, so that the target middleware instance runs according to the target running configuration information corresponding to the target middleware instance, the method further comprises: if it is perceived that the configuration change of the target running configuration information is pushed to the lightweight network agent, the target middleware instance runs according to the updated target running configuration information.

[0078] Since there are often updates of services in a distributed system or microservice architecture, the corresponding logical cluster and general configuration also need to be changed accordingly, that is, the global configuration information may be updated irregularly. The configuration center supports real-time configuration pushing, that is, the configuration center is responsible for storing and managing the configuration information of all services, and supports real-time updating and pushing mechanism. Therefore, in order to ensure that the lightweight network agent can dynamically, safely and efficiently respond to changes in running configuration information, and ensure service continuity and stability, the lightweight network agent can dynamically perceive the configuration change pushing of the related running configuration information. If it is perceived, the lightweight network agent runs according to the updated running configuration information, and determines that the target business is running according to the latest running configuration information each time it starts.

[0079] In combination with the implementation of the method embodiments described above Figures 1-2 The embodiments of the present application provide a specific example of a middleware management method, as shown in Figure 5 which contains multiple components and services, such as webhook, sidecar, SDK, server, mesh server, etcd and SRE. Among them, webhook injects configuration when business service is deployed, realizing non-intrusive initialization. SDK provides initialization function, interacts with sidecar, and supports runtime traffic governance. Sidecar is responsible for initialization detection (such as readiness state), sending middleware call request, and cooperating with SDK / server. Server registers service, pulls initialization configuration, reports heartbeat regularly, and calls middleware service to return result. Mesh server listens to etcd configuration change, dynamically pushes configuration to server. Etcd stores full configuration, supports registration listening and change event notification. SRE generates and writes configuration through page operation, and drives system dynamic adjustment.

[0080] In the embodiments of this application, etcd stores the physical cluster information of middleware instances and generates logical cluster configurations through SRE page operations. SREs create logical clusters through the management console based on the importance of business roles, latency sensitivity, and error tolerance, thus dividing physical clusters into logical clusters. etcd stores global configuration information, including: physical mapping: the binding relationship between logical and physical clusters; routing policies: supporting policies such as local priority and traffic splitting; and access permissions: configuring permissions at the business service granularity. The SDK / sidecar filters the corresponding runtime configuration from the global configuration based on identity identifiers. The control plane (mesh server) listens for configuration changes in etcd and dynamically pushes updates to the sidecar / SDK to ensure real-time configuration effectiveness. A webhook injects the sidecar / SDK during business service deployment, automatically integrating a lightweight network proxy. The sidecar / SDK listens for business requests, forwards requests to the target physical cluster according to the configuration policy, and applies access control. If the SRE updates the configuration on the management console, etcd triggers a change event, and the mesh server pushes the new configuration to the sidecar / SDK, achieving seamless switching.

[0081] Furthermore, as a response to the above Figures 1-2 The implementation of the method embodiment shown in this application provides a middleware management device. This device is used to achieve unified management and configuration of middleware, reducing the difficulty of middleware management and maintenance, and improving the flexibility and convenience of traffic governance. The embodiment of this device corresponds to the foregoing method embodiment. For ease of reading, this embodiment will not repeat the details of the foregoing method embodiment, but it should be clear that the device in this embodiment can implement all the contents of the foregoing method embodiment. Specifically, as shown... Figure 3 As shown, the device includes:

[0082] The partitioning unit 31 is used to partition each middleware instance into one or more logical clusters according to the operational characteristics of each business. The operational characteristics are used to characterize features related to the high reliability of business operation.

[0083] Configuration unit 32 is used to perform general configuration settings on one or more logical clusters obtained by the partitioning unit to obtain global configuration information containing each logical cluster. The general configuration settings include at least setting the physical mapping and routing strategy of the middleware instance that each service connects to during runtime.

[0084] The processing unit 33 is used to distribute the global configuration information obtained by the configuration unit to each middleware instance contained in each logical cluster, so that when the service connected to the middleware instance contained in each logical cluster starts, it runs according to the global configuration information.

[0085] Further, as shown in Figure 4 The division unit 31 comprises:

[0086] The determination module 311 is configured to determine the running requirements of each middleware instance according to the role importance, delay sensitivity and error tolerance of each service;

[0087] The first acquisition module 312 is configured to acquire the physical cluster information of each middleware instance;

[0088] The division module 313 is configured to divide each middleware instance into one or more logical clusters based on the running requirements obtained by the determination module 311 and the physical cluster information obtained by the first acquisition module 312.

[0089] Further, as shown in Figure 4 The routing strategy comprises an access mode and an access permission, the access mode comprises direct connection, shunting and local priority, and the access permission comprises read-only, write-only and read-write.

[0090] Further, as shown in Figure 4 The processing unit 33 comprises:

[0091] The second acquisition module 331 is configured to acquire the identity of each middleware instance contained in each logical cluster respectively;

[0092] The delivery module 332 is configured to filter the global configuration information according to the identity obtained by the second acquisition module 331, and deliver the filtered part of the configuration information to each middleware instance according to the identity, as the running configuration information corresponding to each middleware instance, so that each middleware instance runs according to the running configuration information corresponding to each middleware instance when the service connected to each middleware instance is started.

[0093] Further, as shown in Figure 4 The general configuration setting further comprises setting the deployment level of each service to the related middleware instance when running; and the delivery module 332 is specifically configured to:

[0094] Acquire the priority corresponding to the deployment level;

[0095] Filter the global configuration information according to the identity according to the priority, and deliver the filtered part of the configuration information to each middleware instance according to the identity.

[0096] Further, as shown in Figure 4 The processing unit 33 comprises:

[0097] The agent module 333 is configured to automatically integrate the lightweight network agent into the target service when the start feedback of the target service is monitored.

[0098] The first processing module 334 is configured to determine a target middleware instance to which the target service is connected, to call the lightweight network agent obtained by the agent module 333 to listen to a request of the target service to the target middleware instance, and to forward the request to the target middleware instance, so that the target middleware instance is operated according to the target operation configuration information corresponding to the target middleware instance.

[0099] Further, as shown in Figure 4 the device further comprises:

[0100] The second processing module 335 is configured to, before the first processing module 334, if it is perceived that the configuration change of the target operation configuration information is pushed to the lightweight network agent, the target middleware instance is operated according to the updated target operation configuration information.

[0101] Further, the embodiment of the present application further provides a storage medium, the storage medium is used to store a computer program, wherein the computer program is operated to control a device where the storage medium is located to execute the middleware management method in the foregoing Figures 1-2 .

[0102] Further, the embodiment of the present application further provides a processor, the processor is used to operate a program, wherein the program is operated to execute the middleware management method in the foregoing Figures 1-2 .

[0103] In the foregoing embodiments, the description of each embodiment has its own focus, and the part not described in detail in a certain embodiment can be referred to the related description of other embodiments.

[0104] It can be understood that the related features in the foregoing method and device can be mutually referred. In addition, the "first", "second" and the like in the foregoing embodiments are used to distinguish the embodiments, and do not represent the advantages and disadvantages of the embodiments.

[0105] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system, device and unit described above can refer to the corresponding process in the foregoing method embodiments, which will not be described here.

[0106] The algorithms and displays presented herein are not inherently related to any particular computer, virtual system, or other apparatus. Various general purpose systems can be used with programs in accordance with the teachings herein, or it can prove convenient to construct more specialized apparatus to perform the required method steps. The required structure for a variety of these systems will be apparent from the description above. In addition, the present application is not described with reference to any particular programming language. It will be appreciated that a variety of programming languages can be used to implement the teachings of the application as described herein, and any particular language should not be construed as limiting the scope of the application.

[0107] Moreover, the storage can include non-transitory storage such as a system memory, like random access memory (RAM) and / or nonvolatile memory, e.g., read-only memory (ROM) or flash, including at least one memory chip.

[0108] As will be appreciated by one of ordinary skill in the art, embodiments of the present application can be embodied as a method, system, or computer program product. Accordingly, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, and the like) embodying computer readable program code.

[0109] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other processing device to cause a series of operational steps to be performed on the computer, other programmable apparatus or other processing device to produce a computer implemented process such that the instructions which execute on the computer or other programmable apparatus provide processes for implementing the functions specified in the flowchart block or blocks. Figure 1 The flowchart and / or block diagram in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each flowchart block and / or block in the Figures can represent a module, segment, or portion of code, which comprises one or more executable Figure 1 The flowchart and / or block diagram in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each flowchart block and / or block in the Figures can represent a module, segment, or portion of code, which comprises one or more executable

[0110] These computer program instructions can also be stored in a computer- readable memory that can direct a computer or other programmable data processing apparatus to function in a particular manner, such that the instructions stored in the computer-readable memory produce an article of manufacture including instructions which implement the Figure 1 The flowchart and / or block diagram in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each flowchart block and / or block in the Figures can represent a module, segment, or portion of code, which comprises one or more executable Figure 1 The flowchart and / or block diagram in the Figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each flowchart block and / or block in the Figures can represent a module, segment, or portion of code, which comprises one or more executable

[0111] These computer program instructions can also be loaded into a computer or other programmable data processing apparatus to cause a series of operational steps to be performed on the computer or other programmable apparatus to produce a computer-implemented process such that the instructions which execute on the computer or other programmable apparatus provide steps for implementing the functions specified in the flowchart block or blocks. Figure 1 Figure 1

[0112] In one typical configuration, the computing device includes one or more processors (CPUs), input / output interfaces, network interfaces, and memory.

[0113] The memory can include non-persistent memory and / or volatile memory, such as random access memory (RAM) about which the processor can execute instructions. The memory can also include non-volatile memory, such as read only memory (ROM), electrically programmable read only memory (EPROM), electrically erasable programmable read only memory (EEPROM), flash memory, or other memory technologies, CD-ROM, digital versatile disc (DVD), or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to store information for access by a computing device. In no case does the medium include a transitory signal.

[0114] Computer readable media includes permanent and non-permanent, removable and non-removable media implemented in any method or technology for storage of information such as 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 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, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transitory medium that can be used to store information accessible by a computing device. According to the definition herein, computer readable media does not include transitory media such as modulated data signals and carrier waves.

[0115] It should also be noted that the terms "comprising," "including," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements recited, but can also include other elements not expressly listed or inherent to such process, method, article, or apparatus. Without limitation, an element preceded by "comprises a" does not, without more constraints, foreclose the existence of additional identical elements in the process, method, article, or apparatus that comprises the element.

[0116] ​​Those skilled in the art will appreciate that embodiments of the present application can be devised for a method, a system, or a computer program product. Accordingly, the present application can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment combining software and hardware aspects. Furthermore, the present application can take the form of a computer program product on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROMs, optical storage devices, etc.) embodying computer-readable program code thereon for use by or in connection with an instruction execution system. For the purposes of this description, a computer-usable or computer readable storage medium can be any apparatus that can contain, store, communicate, propagate, or transport the program for use by or in connection with the instruction execution system, apparatus, or device.

[0117] The foregoing is merely illustrative of the embodiments of this application, and is not intended to limit the application. Numerous variations and modifications can be possible to the embodiments without departing from the spirit and scope of the application. Any equivalent modifications or variations, made within the spirit and scope of the application, should be considered within the scope of the application.

Claims

1. A middleware management method characterized by comprising: The method comprises: dividing the middleware instances into one or more logical clusters according to the running characteristics of each service, the running characteristics being used to represent characteristics related to high-reliability running of the services; performing general configuration setting on the one or more logical clusters to obtain global configuration information containing each logical cluster, the general configuration setting at least including setting physical mapping and routing strategies of the middleware instances to which each service is connected during running; respectively issuing the global configuration information to each middleware instance contained in each logical cluster, so that when a service connected to each middleware instance in each logical cluster is started, the service is run according to the global configuration information.

2. The method of claim 1, wherein, The method of dividing the middleware instances into one or more logical clusters according to the running characteristics of each service comprises: determining running requirements of each middleware instance according to the role importance, delay sensitivity and error tolerance of each service; obtaining physical cluster information of each middleware instance; dividing each middleware instance into one or more logical clusters based on the running requirements and the physical cluster information.

3. The method of claim 1, wherein: the routing strategy includes an access mode and an access permission, the access mode including direct connection, shunting and local priority, and the access permission including read-only, write-only and read-write.

4. The method of claim 1, wherein, The method of respectively issuing the global configuration information to each middleware instance contained in each logical cluster, so that when a service connected to each middleware instance in each logical cluster is started, the service is run according to the global configuration information, comprises: for each middleware instance contained in each logical cluster, obtaining an identity corresponding to each middleware instance; screening the global configuration information according to the identity, and issuing the screened part of the configuration information to each middleware instance according to the identity as running configuration information corresponding to each middleware instance, so that when a service connected to each middleware instance is started, the service is run according to the running configuration information corresponding to each middleware instance.

5. The method of claim 4, wherein, The general configuration setting further includes setting a deployment level of the middleware instances to which each service is connected during running; and the method of screening the global configuration information according to the identity, and issuing the screened part of the configuration information to each middleware instance according to the identity, comprises: obtaining a priority corresponding to the deployment level; screening the global configuration information according to the identity according to the priority, and issuing the screened part of the configuration information to each middleware instance according to the identity.

6. The method of claim 4, wherein, The method of, when a service connected to each middleware instance is started, running according to the running configuration information corresponding to each middleware instance, comprises: when a start feedback of a target service is monitored, automatically integrating a lightweight network agent into the target service; determining a target middleware instance connected to the target service, calling the lightweight network agent to listen to a request of the target service to the target middleware instance, and forwarding the request to the target middleware instance, so that the target middleware instance is run according to target running configuration information corresponding to the target middleware instance.

7. The method of claim 4, wherein, Before the lightweight network proxy is invoked to listen to a request of the target service to the target middleware instance and forward the request to the target middleware instance, so that the target middleware instance runs according to the target running configuration information corresponding to the target middleware instance, the method further comprises: If it is perceived that the configuration change of the target running configuration information is pushed to the lightweight network proxy, the target middleware instance runs according to the updated target running configuration information.

8. A middleware management apparatus characterized by comprising: The apparatus comprises: A division unit configured to divide each middleware instance into one or more logical clusters according to running characteristics of each service, the running characteristics being used to represent characteristics related to high-reliability running of the service; A configuration unit configured to perform general configuration setting on one or more logical clusters obtained by the division unit to obtain global configuration information containing each logical cluster, the general configuration setting at least including setting physical mapping and routing strategy of a middleware instance to which each service is connected during running; A processing unit configured to respectively distribute the global configuration information obtained by the configuration unit to each middleware instance contained in each logical cluster, so that each middleware instance contained in each logical cluster runs according to the global configuration information when a service connected to the middleware instance is started.

9. A storage medium, characterized by The storage medium comprises a stored program, wherein the program controls a device in which the storage medium is located to perform the middleware management method according to any one of claims 1 to 7 when the program is running.

10. A processor, comprising: The processor is used to run a program, wherein the program performs the middleware management method according to any one of claims 1 to 7 when the program is running.

Images