Container mirror image generation system based on agency-free service grid framework

Abstract

A container mirror image generation system based on an agency-free service grid framework comprises a multi-dimensional rule configuration module, a full-link gray level isolation module, a micro-service strategy injection module, a byte enhancement module and a link unvarnished transmission implementation module. The advantages of a software toolkit (core tools and libraries required for developing, compiling, debugging and running application programs) and a service grid are combined, and non-invasive treatment logic injection, flexible expansibility and efficient performance optimization are provided. The service management in the micro-service architecture is simplified, the observability and safety of the system are improved, and the method has important significance for the modern micro-service environment.

Description

Technical Field

[0001] The present invention relates to a technology in the field of information processing, specifically a container image generation system based on a proxy-free service mesh framework. Background Art

[0002] In today's microservices architecture, applications are usually split into multiple independent services that communicate over a network. The advantage of this architecture is that it can improve the scalability and flexibility of the system. Initially, developers used SDKs to solve these problems by integrating various libraries and tools in the code to achieve service governance. However, as the scale of the microservices architecture continues to expand, this approach gradually shows limitations: it introduces dependencies on specific tools (such as Istio, Linkerd), requires partial adjustment of service code to meet their requirements, and requires services to expose specific metadata or headers to achieve distributed tracing and monitoring, which brings issues of code invasiveness and consistency. To solve these problems, service mesh technology emerged, separating the service governance logic from the application code by introducing a proxy layer between services, achieving better governance and management. However, the introduction of service mesh also brings new challenges: service-to-service communication, configuration complexity, the possibility of overall service paralysis caused by local failures, lack of real-time scheduling and dynamic awareness capabilities, and dependence on specific platforms and frameworks. Summary of the Invention

[0003] In view of the above deficiencies in the prior art, the present invention proposes a container image generation system based on a proxy-free service mesh framework. By leveraging runtime bytecode enhancement technology and combining the advantages of software toolkits (core tools and libraries required for developing, compiling, debugging, and running applications) and service meshes, it provides non-invasive governance logic injection, flexible scalability, and efficient performance optimization. It not only simplifies service governance in the microservices architecture but also enhances the observability and security of the system, which is of great significance for modern microservices environments.

[0004] The present invention is realized through the following technical solutions:

[0005] The present invention relates to a container image generation system based on a proxy-free service mesh framework, including: a multi-dimensional rule configuration module, a full-link gray-scale isolation module, a microservice policy injection module, a bytecode enhancement module, a link pass-through implementation module, and an image generation module, wherein: The multi-dimensional rule configuration module analyzes rule configuration parameters and completes the configuration of the multi-live space according to the multi-live architecture model and traffic scheduling rules in the user system development document, calculates the traffic distribution through a traffic scheduling algorithm, and generates a configuration file; The full-link gray-scale isolation module calculates the instance traffic weight based on the multi-tenant resource and service isolation requirements and dynamically generates a resource isolation configuration according to the multi-live traffic scheduling strategy; The microservice policy injection module uses a dynamic loading mechanism to embed service discovery and link tracing into the bytecode of the application at runtime; The bytecode enhancement module removes redundant logic and performs method inlining optimization on the bytecode; The link pass-through implementation module intercepts service requests and calculates link-internal traffic closed-loop parameters based on an extended pass-through message structure, and generates a complete link configuration file through encapsulation processing; The image generation module integrates the outputs of each module and uses containerization tools to build and generate a deployable container image file. Technical Effects

[0006] The container image generator based on the proxy-free service mesh framework of the present invention finally generates a deployable container image file that meets the requirements according to the system development requirement document provided by the user and multi-dimensional rule configuration parameters. Compared with existing technologies and implementation methods, the present invention directly injects service mesh functions into the application through bytecode operations at runtime, which can reduce these additional network overheads and reduce latency. There is no longer a need to run an additional sidecar proxy, thereby reducing the occupation of CPU, memory, and network resources. At the same time, it simplifies operation and maintenance. By enhancing bytecode operations to achieve a proxy-free mode, all service mesh-related configurations and management can be centralized in the control plane without the need to separately configure sidecar proxies in each service instance, reducing environmental complexity. Since the bytecode enhancement technology is used as the data plane of service governance, it is naturally decoupled from the application and can achieve local upgrades of the data plane. When facing version upgrades and iterations, it can be uniformly managed without relying on the re-packaging and building of user applications. By performing bytecode operations on the application at runtime and directly inserting service mesh-related logic at the bytecode level without the need for developers to modify the source code of the application, it can be compatible with the existing ecosystem, and the service mesh functions can also be flexibly added or removed to adapt to different runtime requirements. And for legacy systems that cannot modify the source code, this method is also an ideal way to integrate modern service mesh functions into old systems and improve their functions and performance. The present invention can enjoy the powerful functions brought by the service mesh while maintaining the stability of the existing system, and is an efficient and flexible solution. Brief Description of the Drawings

[0007] Figure 1 Schematic diagram of the system of the present invention;

[0008] Figure 2 Schematic diagram of the implementation device for the embodiment. Detailed implementation manners

[0009] As Figure 1 shown, this embodiment relates to a container image generation system based on an agentless service mesh framework, including: a multi-dimensional rule configuration module, a full-link gray isolation module, a service policy injection module, a byte enhancement module, a full-link transparent transmission implementation module, and an image generation module.

[0010] The multi-dimensional rule configuration module includes: a rule parsing unit, a traffic allocation unit, a resource weight calculation unit, and a configuration generation unit, where: the rule parsing unit parses key rule information according to the multi-live architecture model, traffic scheduling rules, and domain name configuration parameters provided by the user, extracts the configuration items and traffic allocation logic of the multi-live space, and obtains the basic rule data for calculation; the traffic allocation unit calculates and processes the traffic distribution according to the traffic allocation logic provided by the rule parsing unit and the multi-live space definition, combined with the real-time traffic monitoring data, and obtains the allocation ratio of the traffic in different multi-live units and the path planning result; the resource weight calculation unit calculates and dynamically adjusts the resource weight of each instance according to the traffic ratio calculated by the traffic allocation unit and the resource availability index of the instance, and obtains the resource allocation result among multi-tenants; the configuration generation unit performs dynamic generation processing of the configuration file according to the weight data generated by the resource weight calculation unit and the traffic allocation path planning result, and obtains the multi-dimensional rule configuration file for service mesh scheduling for subsequent modules to call and deploy.

[0011] The traffic allocation means: allocating an initial weight W i to each data center DC i . Regularly obtain the health status H i of each data center through the monitoring system: H i =1 indicates normal, H i =0 indicates a fault (traffic is no longer allocated to this node), and then dynamically adjust the weight according to the following metrics: response time R i , load ratio L i (current load / maximum tolerable load), dynamic weight where: W' i represents the adjusted weight, L max represents the maximum load of a single data center, and distribute the traffic according to the ratio of W' i . The amount of the total traffic T allocated to DC i is: The requests are assigned to each data center one by one through the weighted round-robin method, following the weight ratio, and finally checking H regularly i When i H i = 0, remove DC i from the round-robin queue; when H

[0012] = 1, rejoin and initialize the weights. i ) and update the weights: where: α is the smoothing factor used to control the fusion ratio of new and old load information. On this basis, the deep deterministic policy gradient algorithm is incorporated, embedding the deep learning algorithm into the system. In a dynamic environment, it can not only adaptively adjust the traffic weights through a simple feedback formula but also learn long-term rewards, including future performance impacts, etc., reducing local load imbalance or system bottleneck problems.

[0013] The deep deterministic policy gradient algorithm described above includes: defining the state space where: C i represents the CPU usage rate of the i-th server, T i represents the average response time of the i-th server, and Q i represents the current queue length of the i-th server; defining the action, i.e., the adjustment ratio space A t = {ΔW 1 , ΔW 2 , …, ΔW n} of the weights of each server; defining the reward function, i.e., the efficiency of traffic allocation needs to be measured where: Var is the variance of traffic allocation, and the smaller it is, the more balanced. λ 1 , λ 2 are hyperparameters used to balance the balance and response time.

[0014] The training process of the deep deterministic policy gradient algorithm described above is as follows: The Actor network generates the action A t (i.e., weight adjustment), and the Critic network is used to evaluate the value Q(S t , A t ) of the state-action pair. Update the Critic network according to the Temporal Difference (TD) target: y t = R t + γQ(S t+1 , A t+1 ), Update the Actor network through the policy gradient method: The overall dynamic weight adjustment algorithm then becomes: 1) Initialize the Actor and Critic networks and their parameters. 2) Use Experience Replay (ReplayBuffer) to store state transitions (S t , A t , R t , S t+1 ). 3) Randomly sample a small batch of data to train the network. 4) Update the target network every certain number of steps.

[0015] The full - link gray - scale isolation module described above includes: a multi - tenant isolation unit, a traffic rule import unit, an instance traffic allocation unit, and a version management unit. Among them: The multi - tenant isolation unit performs isolation processing of resources and services between tenants according to the business attributes, resource usage requirements, and isolation policies of tenants, and obtains a multi - tenant isolation solution that ensures the complete independence of data and traffic of different tenants; The traffic rule import unit performs rule parsing and import processing according to the traffic allocation rules configured by users (such as user attributes, geographical locations, and business characteristics, etc.), and obtains traffic scheduling rules applicable to different tenants and business scenarios; The instance traffic allocation unit performs traffic allocation calculation and path planning processing through sticky filters, label filters, and load - balancing filters based on the responsibility chain according to the results of the traffic rule import unit and the real - time status of each instance in the system, and obtains the traffic allocation ratio and execution plan for each instance; The version management unit runs microservices of different versions in independent lanes according to business logic requirements and system upgrade strategies, performs version isolation and dynamic management, and obtains a flexible upgrade solution that supports scenarios such as blue - green deployment and canary release.

[0016] The multi - tenant isolation mentioned above means: Through virtualization technology, independent partitions of computing, storage, and network resources are realized. Combining multi - tenant identity separation and access permission control ensures that resources between different users do not interfere with each other. At the same time, through Virtual Private Cloud (VPC), encrypted transmission, traffic - limiting strategies, and refined permission management, data protection and service stability are strengthened, resource contention and data leakage are prevented, and security and high - performance operation in a multi - tenant environment are guaranteed.

[0017] The sticky filter based on the responsibility chain mentioned above uses hash allocation based on session identification to ensure that requests from the same user are always routed to a fixed instance to maintain session consistency. Specifically: Instance = Hash(SessionID) mod N, where: Instance represents the target instance, SessionID represents the session identification of the user request (such as Cookie, Token, etc.), and N represents the number of backend instances.

[0018] The label filter mentioned above uses a strategy of priority routing with multi - dimensional matching to route traffic to the instance set with the highest priority. Specifically: where: w i represents the weight, i.e., the priority of each tag; Tag i represents the i-th tag carried by the request; Rule i represents the matching tag rule; Match is a boolean function that returns 1 (matched) or 0 (not matched).

[0019] The load balancing filter mentioned above realizes optimized traffic distribution through weighted round-robin, specifically: where: P(i) represents the allocation probability of instance i; W i represents the weight of the instance.

[0020] The version management mentioned above refers to: realizing efficient iteration and reliable deployment of versions through a combination of centralization and automation. The system supports multi-version coexistence and gray release mechanisms to ensure the gradual verification of the stability and performance of the new version without affecting the existing services. By integrating the continuous integration / continuous delivery (CI / CD) tool chain, version management covers links such as code compilation, functional testing, environment adaptation, and automatic deployment, and combines the version rollback mechanism to ensure the controllability and security of the upgrade process and meet the high-availability requirements.

[0021] The service policy injection module mentioned above includes: a policy adaptation unit, a control plane unit, a registry synchronization unit, and a byte enhancement unit. Among them: The policy adaptation unit performs policy parsing and configuration processing according to the rule information input by the user (including: routing policies, authorization policies, retry policies, circuit breaker policies, etc.) to obtain a dynamic policy configuration solution that adapts to the mainstream service framework; The control plane unit performs elastic enhancement, event bus configuration, synchronization policy implementation, working log recording, and system telemetry data opening according to the system operation status and business requirements to obtain a service control plane with real-time monitoring, elastic expansion, and event-driven capabilities; The registry synchronization unit ensures the consistency of service status across multiple data centers or regions by synchronizing the service information of each registry in real time, provides technical support for cross-region load balancing and disaster recovery backup, and synchronizes the health status, online / offline information, and metadata changes of service instances in real time to ensure that cross-region load balancing can make decisions based on the latest service status; The byte enhancement unit performs enhancement processing on the target application using bytecode operation technology according to the service policy and dynamic loading requirements to obtain a high-performance service instance injected with the required policy logic.

[0022] The described event bus configuration means: receiving real-time events through the data input layer and configuring a unified message body parsing rule to generate a unified context object; using filtering operators and enrichment operators in the data processing layer for data parsing, filtering, enrichment, and transformation; distributing the processed data to different message queues or storage systems through the data output layer; and quickly supporting new data sources or targets through the connector mechanism while configuring custom scripts to dynamically adjust the operator logic without frequently restarting the service.

[0023] The described filtering operator screens the input data through predefined rules, retains the data that meets the conditions, and discards the data that does not meet the conditions. Its core is a conditional boolean determination: Y = {x ∈ X | P(x) = true}, where: X is the set of input data, P(x) is the predicate function that defines the filtering condition. Y represents the set of output data, containing only the data that satisfies P(x) = true. The enrichment operator supplements or enhances the input data by introducing external data sources or calculation logic to provide more context information for downstream processing. Specifically: Y = {(x, E(x)) | x ∈ X}, where: X is the set of input data, E(x) represents the enrichment function that defines how to supplement or enhance the data x, and Y represents the set of output data, which is the enriched data. In the event bus, the filtering operator and the enrichment operator usually work together in the form of a responsibility chain: first, the filtering operator screens out invalid or irrelevant events to reduce the data processing pressure, and for the retained data set, the enrichment operator further enhances its context, and finally the responsibility chain outputs.

[0024] The implementation of the described synchronization strategy specifically includes:

[0025] i) Dynamic grouping and routing planning: mapping the business logic group G to a specific resource group (such as a server or a topic queue), specifically: G = f(U, T), where: G represents the group, U represents the available resource units, such as: servers, service nodes, etc., and T represents the task or topic.

[0026] For high-load scenarios, the priority-based degradation strategy ensures that critical events are processed first, specifically: the priority function P(x) = α 1 ·W(x) + α 2 ·R(x), where: P(x) represents the priority, W(x) represents the weight, R(x) describes the resource occupancy ratio, α 1 α 2 represents an adjustable coefficient.

[0027] ii) Through the responsibility chain mode, layer by layer filtering, parsing, and distributing messages to achieve real-time monitoring and link optimization. The data processing at each step is implemented by the operator function: Y i+1 = f i (X i), where: X i is the input data, f i is the operator logic, Y i+1 is the processed output data.

[0028] iii) Use a bi - directional or multi - directional communication protocol (such as gRPC, MQTT) to ensure data consistency between different systems. Specifically: the synchronization window W s = max(T d - T r , 0), where: W s represents the synchronization delay window, T d represents the data generation time, T r represents the data reception time.

[0029] The described working - day log record and system telemetry data opening are implemented through open standards, supporting multiple monitoring protocols (such as OpenTelemetry, Prometheus), providing end - to - end tracing, performance metric collection, and real - time analysis. The log record adopts a hierarchical design, covering multi - dimensional information such as key events, errors, traffic, resource utilization, etc., and supports dynamic configuration of log levels and output formats to meet different debugging requirements. Through seamless integration with external log systems (such as ELK, Fluentd), efficient log storage, query, and alarm are achieved, helping to locate problems in real - time and optimize system performance.

[0030] The described byte enhancement module includes: a code interception unit, a modification point location unit, an instruction set operation unit, and a code re - loading unit. Among them: the code interception unit reads and pre - processes the target code file according to the binary file or intermediate representation file information during program loading to obtain the program intermediate representation for analysis; the modification point location unit selects specific code segments to be enhanced (such as function entry or specific calls) according to the code information provided by the interception unit, combined with the enhancement requirements, and determines the modification points that meet the enhancement conditions to obtain a list of target modification points; the instruction set operation unit performs instruction insertion, replacement, or deletion processing according to the list of target modification points, injecting the required bytecode logic (including: entry enhancement, exit enhancement, and behavior rewriting) to obtain the enhanced instruction set; the code re - loading unit performs a re - loading process according to the modified instruction set, covering the enhanced code into the running environment to obtain the high - performance program logic with enhanced completion.

[0031] The described registry synchronization includes: policy service execution, service controller governance, and context synchronization service coordination based on strong consistency - related, adopting a synchronization mechanism based on log replication combined with strong consistency synchronization based on vector clocks. Specifically: L i ={l 1 , l 2 ,.., ln}, the status of the registration center is determined by the log sequence: S i = f(L i ), and the log synchronization rule is: L follower = L leader , where L leader = max(L follower ), where: f represents the status generation function. In actual business stress testing, it is found that when the main node has high pressure, is prone to single-point failure and requires strong consistency, the synchronization delay is extended, and the cost of consistency is relatively high.

[0032] In the strong consistency synchronization described above, each node maintains a vector VC[i], which represents the timestamp of the global event observed by node i. Among them: the number of elements of the vector clock VC is equal to the number of nodes, and each element VC[i] is the local time of node i. Each registration center R i initializes the vector clock VC i , and the elements are 0. When a service instance is registered or deregistered, the registration center R i increases its local vector clock: VC i [i] ← VC i [i] + 1, where: the service status change is represented by the event E i , which includes the vector clock VC i and the change content. The synchronization process is as follows: the registration center R i sends the event E i to other registration centers R j , and the receiving party R j merges the vector clocks: Determine whether to apply the change according to the event timestamp. If multiple events conflict, use the vector clock sorting rule: Therefore, it can be ensured that events are processed in the same order on all nodes, eliminating inconsistent states.

[0033] The health status of the synchronized service instance refers to: the periodic health check is based on Ping, HTTP status code, and business-level heartbeat detection. The health status is calculated through a sliding window, and the status data is updated in real time to avoid interference from old data in judgment: if the health status of the i-th instance at time t is 1. However, in actual applications, it is found that the sliding window method has stronger real-time performance, but still cannot predict potential problems in advance.

[0034] The health status described above is preferably predicted by a time series prediction algorithm, specifically: using the ARIMA model (Autoregressive Integrated Moving Average) to predict indicators with strong trends and periodicities: Where: p represents the order of the autoregressive (AR) part, q represents the order of the moving average (MA) part, and ∈t represents white noise. First, check the stationarity of the sequence (such as unit root test), perform differencing on non-stationary sequences, and use the AIC / BIC criterion to select the optimal P and q values. Fit the ARIMA model and calculate the parameters φ, θ, and c. Use this to predict future time series points X t+h . When facing high-dimensional, non-linear, and complex health status data, the LSTM model (long short-term memory network) can also be combined.

[0035] The long short-term memory network learns the long-term dependencies of time series through the recurrent neural network (RNN) architecture: Forget gate: f t = σ(W f ·[h t-1 , x t +b f ), Input gate: i t = σ(W i ·[h t-1 , x t +b i ), Cell state update: Output gate: o t = σ(W o ·[ht-1, x t +b o ), h t = o t ⊙tanh(C t ), where: x t is the current input; h t-1 is the hidden state at the previous moment; C t is the current cell state. Organize the health status indicators X t into sequence data of a sliding window, construct an LSTM network, input the sequence {X t-n , X t-n+1 ,..., X t}, and output the prediction X t+1 , and use this to roll and predict the future health status.

[0036] The described time series prediction algorithm is specifically implemented in the following way: Collect historical health status metrics of the service, such as response time, CPU usage rate, error rate, etc., and perform data preprocessing: smooth the time series, remove noise and trends. Conduct a stationarity check and determine the optimal p, d, q parameters through AIC or BIC. In a distributed scenario, use ARIMA to capture the linear trend, obtain the residual sequence, use LSTM to perform non-linear modeling on the residual sequence, convert the residual sequence into a time step format, receive the sequence data, and construct a multi-layer LSTM to capture time series dependencies at once. Obtain the superposition result of the two: The parallel model simultaneously inputs the time series into two models, ARIMA and LSTM, and fuses the prediction results of the two through weights: This method combines the linear prediction ability of ARIMA and the non-linear modeling ability of LSTM, and adds an Attention mechanism to LSTM to dynamically focus on key time points. Utilize the sliding window technology to continuously update the prediction model to adapt to the dynamic changes in the health status, and achieve accurate prediction and early warning of the service health status, thereby enhancing the robustness of the health status prediction.

[0037] The on-demand loading of the described class management service means that: Through lazy loading and dynamic loading technologies, the class loading process is optimized, system resource occupancy is reduced, and the service startup efficiency and runtime flexibility are improved. It includes the full life cycle management of classes and the optimization of class instantiation loading. The present invention uses a custom class loader to dynamically load classes, realizing fine-grained management of classes from creation, loading, initialization, to use and unloading. By isolating the class loading environments of different modules, the class loading conflict problem is avoided. Combining the factory pattern or proxy pattern, the instantiation of classes is delayed to ensure that the relevant logic is loaded only when actually called. And the on-demand loading mechanism is combined with the plug-in design of the present invention, enabling plug-in modules to be dynamically loaded and unloaded at runtime.

[0038] The specific implementation of the policy service refers to: through steps such as dynamic rule loading, real-time status awareness, policy execution and synchronization, and multi-region consistency guarantee, to achieve strong consistency cross-region service governance. First, load policy rules during the service startup phase and monitor rule changes, and parse them into a unified policy model and store it in memory. Secondly, through the registry, real-time sense the health status, online / offline information, and metadata changes of service instances, and dynamically update local decisions, including weight adjustment, flow limit threshold setting, and routing optimization. Then, broadcast the policy execution results to all nodes through the event bus or registry, and ensure the consistency of the synchronization results in combination with version control; if conflicts are detected during synchronization, use the master-slave mechanism or voting method to solve them, and roll back to the previous version if necessary. Finally, optimize the multi-region synchronization efficiency through incremental synchronization, batch processing, and transaction mechanisms, while maintaining state consistency, supporting multi-protocol adaptation, and ensuring error-free policy synchronization in heterogeneous systems.

[0039] The governance of the service controller refers to: through fine-grained control and policy-based management, to ensure the efficient, stable, and reliable service calls in the multi-active architecture, including: functions such as service routing, load balancing, flow limiting, and degradation, to achieve service quality guarantee and efficient resource utilization. The service controller distributes requests to eligible service instances through dynamic routing rules, and real-time senses the service status to adjust the routing; uses dynamic weight update combined with load balancing algorithms such as round-robin, weighted random, or least connections to optimize resource allocation; sets flow limit rules through the token bucket algorithm, limits the request rate according to QPS or TPS, and configures emergency strategies to handle over-limit situations; when the service is unavailable, execute the degradation strategy based on trigger conditions, such as returning a default response or calling an alternative service.

[0040] The context synchronization service coordination is used to ensure the consistency of context information of cross-node services in a distributed multi-active architecture. Through this mechanism, services on different nodes can share key context data, so as to achieve global visibility and consistent processing of the request link. Context information is propagated between nodes through an efficient serialization and network transmission mechanism. Through the synchronization protocol, ensure the consistency of state data between nodes, support the eventual consistency and strong consistency models, and the specific choice depends on the requirements of the business scenario.

[0041] For the strong consistency scenario, commonly used distributed consistency protocols such as Paxos or Raft are used. Nodes record context changes in the form of logs to ensure that the majority of nodes receive the same change log L: L commit ={L 1 ,L 2 ,…,L n},if Majority(L i )=True, that is, if the log L iConfirmed by a majority of nodes, the change is submitted. And the heartbeat mechanism H is used to ensure the existence of the leader: Compress the context data using Huffman coding or the LZ algorithm: C compressed = f compress (C), where: f compress is a compression function that can significantly reduce the amount of data transmitted. This provides strict consistency guarantees and is suitable for critical context synchronization across data centers.

[0042] The full-link pass-through implementation module described above includes: a message interception unit, a pass-through message definition unit, a data aggregation and encapsulation unit, and a link closed-loop unit. Among them: The message interception unit performs request interception and metadata extraction processing based on the interaction request information between the service consumer and the provider, and obtains the original data of the pass-through message containing the request identifier, context information, etc.; The pass-through message definition unit performs message format parsing and normalization processing according to the predefined extended pass-through message structure, and obtains a standardized pass-through message that meets the requirements of link tracing and traffic management; The data aggregation and encapsulation unit performs data aggregation and encapsulation processing according to the standardized pass-through message, and obtains a pass-through data packet containing complete link information; The link closed-loop unit performs in-link traffic closed-loop calculation and path optimization processing according to the encapsulated pass-through data packet, combined with the service unit and the lane rules, and obtains the execution plan of the closed-loop link.

[0043] As Figure 2 shown, the implementation device of the container image generation system based on the above agentless service mesh framework in this embodiment includes: an upper-layer application, a container image generation system, and an external data layer.

[0044] The functions of the upper-layer application described above include rule input, policy injection result feedback, multi-active model visualization, and service retrieval. Rule input can use Spring Boot to implement RESTful APIs and gRPC interfaces, and receive rules in JSON or YAML format; Parse the rule content through an ANTLR parser, and use Javassist or ByteBuddy to dynamically enhance the responsibility chain to inject the rules in real time, which can take effect without restarting; The policy injection feedback uses Prometheus to collect execution data, uses a Kafka or RabbitMQ event bus to transmit the results, and notifies the upper-layer application through a Webhook callback; The multi-active model visualization integrates OpenTelemetry or a custom probe to collect node and traffic data, uses Redis for data aggregation, pushes data updates through WebSocket, and combines ECharts to dynamically render the topology view; The service retrieval module Consul or Eureka synchronizes service instance information, uses Elasticsearch to build a distributed index, and provides efficient multi-dimensional query and real-time update services.

[0045] The data layer operates with external data sources through a persistence layer interface and a transaction management framework (Seata), etc. It directly operates on the database using the standard JDBC (Java Database Connectivity) interface, or simplifies database operations through ORM frameworks such as MyBatis and Hibernate, and combines database transactions and business logic to ensure data integrity. When processing data such as document type, time series, and key-value, it can cooperate with non-relational databases with the help of a distributed cache system or a message queue (such as Kafka).

[0046] The service policy injection in the container image generation system specifically includes: when a service instance starts, it sends a registration request to the Nacos registration center of the governance policy module, providing instance meta-information (service name, address, running status, etc.). The service discovery module dynamically resolves the registry according to the call request and returns a list of service instances that meet the conditions. The configuration management function realizes dynamic configuration distribution through the subscribe-publish mode. After the service instance starts, it subscribes to relevant configuration update topics, and the combination of dynamic configuration data and service discovery affects the call priority and routing behavior of the service. Combined with dynamic configuration, when the traffic exceeds the threshold or the service performance decreases, the module automatically triggers the degradation and rate-limiting mechanisms to ensure system stability. The module regularly calls the health check interface of the service instance to actively check the health status, and automatically marks abnormal service instances by analyzing real-time data of service calls (such as error rate, latency, etc.). In the overall service call chain, the module synchronizes call contexts (such as Trace ID, user tags) to ensure consistent call information across services.

[0047] After specific actual experiments, in a complex business scenario of high concurrency and multi-tenancy, when this device is started and run with configuration parameters of 1000 TPS (transactions per second) traffic pressure, 50 microservice instances, and 10 multi-active spaces, the experimental data that can be obtained are as follows: the overall system processing delay is stable within 30 milliseconds, the global synchronization time after the traffic scheduling rule is adjusted is less than 1 second, the multi-tenant resource isolation accuracy rate reaches 99.9%, and the execution success rate of service policy injection and dynamic enhancement is 98.7%. In the simulation experiment, the platform successfully achieved accurate traffic distribution and complete link tracking. The test window supporting blue-green deployment and canary release shows that the failure rate of version switching is reduced to 0.05%.

[0048] As shown in Table 1, theoretical analysis shows that through the collaborative work of modules, such as the multi-dimensional rule configuration module, the full-link gray isolation module, the service policy injection module, and the full-link transparent transmission implementation module, the platform can efficiently manage the diversity in complex systems and achieve dynamic resource scheduling, real-time monitoring, and system elastic expansion in high-concurrency scenarios. This indicates that the device can not only operate stably but also has new functions to support rapid business iteration, flexible expansion, and performance optimization, providing comprehensive guarantee for the enterprise's multi-tenant architecture and modern microservice management.

[0049] Table 1 Comparison of Technical Characteristics

[0050] Compared with the prior art, in terms of flexibility, the multi-dimensional rule configuration module in the present invention supports dynamic rule construction, real-time loading and adjustment based on scenarios, and adopts a micro-kernel architecture to only retain necessary modules such as basic communication and plugin management. Other extended functions are independently implemented in the form of modules or plugins. This design reduces the complexity of the core, improves the stability and maintainability of the system. Modules and plugins support on-demand loading or unloading, and can flexibly adjust functions according to business requirements, providing traffic policies such as sticky routing (ensuring that the same user request is always routed to the same instance) and tag routing (determining the routing path according to tag fields). The full-link gray isolation module supports service isolation, multi-tenant environment and refined traffic management. The bytecode enhancement module allows dynamic insertion of functions or fixing of problems at runtime, eliminating the trouble of restarting the service. It is especially suitable for scenarios with high availability requirements to avoid service interruption. In terms of reliability, the service policy injection module detects the health status of service instances by combining active detection and passive monitoring, including resource utilization, network latency, response time, etc. When the health of an instance is poor, the traffic will be switched to a healthy standby instance in real time to ensure the continuity of the service. The design of multi-live traffic scheduling enables dynamic scheduling between different regions or availability zones to achieve fault isolation. Through intelligent routing strategies, the distribution is adjusted according to traffic pressure and resource usage to avoid single-point overload. Event bus coordination and strong synchronization guarantee. In scenarios with high requirements for policy consistency, distributed transactions or strong consistency algorithms are used to ensure synchronization reliability. In terms of adaptability, flexible traffic scheduling rules are provided, such as splitting traffic by priority, gray release, user grouping, etc., to meet the needs of various business models, support common load balancing algorithms (such as round-robin, minimum response time, hash routing, etc.), and allow developers to customize algorithms to adapt to special requirements. Routing rules can be dynamically adjusted without interrupting the service, ensuring service flexibility and real-time performance. The system natively supports common communication protocols and allows extension of new protocols, widely adapting to existing service architectures. In terms of portability, all modules define functions through interfaces, allowing modules to be independently implemented in different languages or frameworks, enhancing cross-language compatibility. Modules automatically adapt to the running environment during loading, and unloaded modules do not affect the performance and stability of the core service. The framework is suitable for both complex microservice systems and can play a role in monolithic architectures, facilitating smooth transition. And it natively integrates the service discovery, automatic scaling and container orchestration capabilities of Kubernetes to improve containerized deployment efficiency. It is multi-cloud compatible, facilitating migration between different cloud environments while avoiding vendor lock-in.

[0051] The above specific implementation can be locally adjusted by those skilled in the art in different ways without departing from the principles and purposes of the present invention. The protection scope of the present invention is subject to the claims and is not limited by the above specific implementation. All implementation solutions within its scope are subject to the constraints of the present invention.

Claims

1. A container image generation system based on an agentless service grid framework, characterized in that: include: Multi-dimensional rule configuration module, full-link grayscale isolation module, microservice policy injection module, byte enhancement module, link transparent transmission implementation module and image generation module, among which: the multi-dimensional rule configuration module parses the rule configuration parameters and completes the configuration of the multi-active space according to the multi-active architecture model and traffic scheduling rules in the user system development document, calculates the traffic distribution through the traffic scheduling algorithm, and generates a configuration file; the full-link grayscale isolation module is based on the resource and business isolation requirements of multiple tenants, calculates the instance traffic weight according to the multi-active traffic scheduling strategy, and dynamically generates resource isolation configuration; the microservice policy injection module uses the dynamic loading mechanism to embed service discovery and link tracking into the bytecode of the application at runtime; the byte enhancement module removes redundant logic and method inline optimization of the bytecode; the link transparent transmission implementation module intercepts service requests and calculates the closed-loop parameters of the traffic within the link based on the extended transparent transmission message structure, and generates a complete link configuration file through encapsulation processing; the image generation module integrates the outputs of each module and uses containerization tools to build a deployable container image file.

2. The container image generation system based on the agentless service grid framework according to claim 1 is characterized in that: The multi-dimensional rule configuration module includes: a rule parsing unit, a traffic allocation unit, a resource weight calculation unit and a configuration generation unit, wherein: the rule parsing unit parses key rule information according to the multi-active architecture model, traffic scheduling rules and domain name configuration parameters provided by the user, extracts the configuration items and traffic allocation logic of the multi-active space, and obtains basic rule data for calculation; the traffic allocation unit calculates and processes the traffic distribution according to the traffic allocation logic and multi-active space definition provided by the rule parsing unit, combined with real-time traffic monitoring data, to obtain the distribution ratio and path planning results of the traffic in different multi-active units; the resource weight calculation unit calculates and dynamically adjusts the resource weight of each instance according to the traffic ratio calculated by the traffic allocation unit and the resource availability index of the instance, and obtains the resource allocation result among multiple tenants; the configuration generation unit dynamically generates and processes the configuration file according to the weight data and traffic allocation path planning result generated by the resource weight calculation unit, and obtains a multi-dimensional rule configuration file for service grid scheduling, which is used for subsequent module calling and deployment.

3. The container image generation system based on the agentless service grid framework according to claim 1 is characterized in that: The full-link grayscale isolation module includes: a multi-tenant isolation unit, a traffic rule import unit, an instance traffic distribution unit and a version management unit, wherein: the multi-tenant isolation unit isolates resources and services between tenants according to the tenants' business attributes, resource usage requirements and isolation strategies, and obtains a multi-tenant isolation solution that ensures that different tenants' data and traffic are completely independent; the traffic rule import unit performs rule parsing and import processing according to the traffic distribution rules configured by the user (such as user attributes, geographic location and business characteristics, etc.), and obtains traffic scheduling rules suitable for different tenants and business scenarios; the instance traffic distribution unit performs traffic distribution calculation and path planning processing based on the adhesion filter, label filter and load balancing filter based on the result of the traffic rule import unit and the real-time status of each instance in the system, and obtains the traffic distribution ratio and execution plan of each instance; the version management unit runs different versions of microservices in independent lanes according to business logic requirements and system upgrade strategies, performs version isolation and dynamic management, and obtains a flexible upgrade solution that supports scenarios such as blue-green deployment and canary release.

4. The container image generation system based on the agentless service grid framework according to claim 1 is characterized in that: The service policy injection module includes: a policy adaptation unit, a control plane unit, a registration center synchronization unit and a byte enhancement unit, wherein: the policy adaptation unit performs policy analysis and configuration processing according to the rule information input by the user, and obtains a dynamic policy configuration solution that adapts to the mainstream service framework; the control plane unit performs elasticity enhancement, event bus configuration, synchronization policy implementation, work log recording and system telemetry data opening according to the system operation status and business needs, and obtains a service control plane with real-time monitoring, elastic expansion and event-driven capabilities; the registration center synchronization unit ensures the consistency of service status in multiple data centers or multiple regions by synchronizing the service information of each registration center in real time, provides technical support for cross-regional load balancing and disaster recovery, and synchronizes the health status, online and offline information and metadata changes of service instances in real time to ensure that cross-regional load balancing can be based on the latest service status decisions; the byte enhancement unit uses bytecode operation technology to enhance the target application according to the service policy and dynamic loading requirements, and obtains a high-performance service instance that has been injected with the required policy logic.

5. The container image generation system based on the agentless service grid framework according to claim 1 is characterized in that: The byte enhancement module includes: a code interception unit, a modification point positioning unit, an instruction set operation unit and a code reloading unit, wherein: the code interception unit reads and preprocesses the target code file according to the binary file or intermediate representation file information when the program is loaded, and obtains the intermediate representation of the program that can be analyzed; the modification point positioning unit selects the specific code fragments that need to be enhanced according to the code information provided by the interception unit and the enhancement requirements, and determines the modification points that meet the enhancement conditions to obtain a target modification point list; the instruction set operation unit inserts, replaces or deletes instructions according to the target modification point list, injects the required bytecode logic, and obtains the enhanced instruction set; the code reloading unit reloads according to the modified instruction set, overwrites the enhanced code into the running environment, and obtains the enhanced high-performance program logic.

6. The container image generation system based on the agentless service grid framework according to claim 1 is characterized in that: The full-link transparent transmission implementation module includes: a message interception unit, a transparent transmission message definition unit, a data aggregation and encapsulation unit and a link closed-loop unit, wherein: the message interception unit performs request interception and metadata extraction processing according to the interactive request information between the service consumer and the provider, and obtains the original data of the transparent transmission message including the request identifier, context information, etc.; the transparent transmission message definition unit performs message format parsing and normalization processing according to the predefined extended transparent transmission message structure, and obtains a standardized transparent transmission message that meets the requirements of link tracking and traffic management; the data aggregation and encapsulation unit performs data aggregation and encapsulation processing according to the standardized transparent transmission message, and obtains a transparent transmission data packet containing complete link information; the link closed-loop unit performs intra-link traffic closed-loop calculation and path optimization processing according to the encapsulated transparent transmission data packet, combined with the service unit and lane rules, and obtains the execution plan of the closed-loop link.

7. The container image generation system based on the agentless service grid framework according to claim 2 is characterized in that: The resource weight calculation is: based on real-time load feedback (such as the current CPU usage C i ), update the weights: Among them: α is a smoothing factor, which is used to control the fusion ratio of new and old load information; then through the deep deterministic policy gradient algorithm, in a dynamic environment, the traffic weight can be adaptively adjusted not only through a simple feedback formula, but also through the deep deterministic policy gradient algorithm, which includes: defining the state space Where: C i represents the CPU usage of the ith server, T i represents the average response time of the i-th server, Q i Indicates the current queue length of the i-th server; defines the action, that is, the adjustment ratio space A of the weight of each server t ={ΔW1, ΔW2,…, ΔW n }; Define the reward function, which is to measure the efficiency of traffic distribution Where: Var is the variance of traffic distribution, the smaller the better the balance; λ1 and λ2 are hyperparameters used to balance balance and response time.

8. The container image generation system based on the agentless service grid framework according to claim 4 is characterized in that: The registration center synchronization includes: based on strong consistency related policy service execution, service controller governance and context synchronization service coordination, using a synchronization mechanism based on log replication combined with strong consistency synchronization based on vector clock, specifically: L i ={l1,l2,…,l n }, the registry status is determined by the log sequence: S i =f(L i ), the log synchronization rule is: L follower = l leader ,whereL leader =max(L follower ), where: f represents the state generation function. Actual business stress testing found that the master node is under great pressure and is prone to become a single point of failure. When strong consistency is required, the synchronization delay is extended, and the consistency cost is high; In the strong consistency synchronization described above, each node maintains a vector VC[i], which represents the timestamp of the global event observed by node i. Among them: the number of elements of the vector clock VC is equal to the number of nodes, each element VC[i] is the local time of node i, and each registration center R i Initialize vector clock VC i , element is 0, when the service instance is registered or deregistered, the registration center R i Increase its local vector clock: VC i [i]←VC i [i]+1, where: service status change event E i Indicates that it contains the vector clock VC i and change content, the synchronization process is as follows: Registration Center R i Event E i Send to other registries R j , the receiver R j Merging vector clocks: Determine whether to apply changes based on event timestamps. If multiple events conflict, use vector clock sorting rules: This ensures that events are processed in the same order on all nodes, eliminating inconsistent states.

9. The container image generation system based on the agentless service grid framework according to claim 8 is characterized in that: The policy service execution specifically refers to: achieving strong consistency in cross-region service governance through steps such as dynamic rule loading, real-time status perception, policy execution and synchronization, and multi-region consistency assurance. First, load policy rules and monitor rule changes during the service startup phase, and parse them into a unified policy model and store them in memory. Secondly, the registration center perceives the health status, online and offline information, and metadata changes of service instances in real time, and dynamically updates local decisions, including weight adjustment, current limiting threshold setting, and route optimization. Then, the policy execution results are broadcast to all nodes through the event bus or the registration center, and the consistency of synchronization results is ensured in combination with version control. If a conflict is detected during synchronization, it is resolved using a master-slave mechanism or voting, and rolled back to the previous version if necessary. Finally, the efficiency of multi-region synchronization is optimized through incremental synchronization, batch processing, and transaction mechanisms, while maintaining state consistency, supporting multi-protocol adaptation, and ensuring correct policy synchronization in heterogeneous systems. The service controller governance mentioned above means: ensuring efficient, stable and reliable service calls under the multi-active architecture through fine-grained control and strategic management, including: service routing, load balancing, current limiting, degradation and other functions to achieve service quality assurance and efficient resource utilization. The service controller distributes requests to qualified service instances through dynamic routing rules, and senses the service status in real time to adjust the routing; optimizes resource allocation by using dynamic weight updates combined with load balancing algorithms such as polling, weighted random or minimum number of connections; sets current limiting rules through the token bucket algorithm, limits the request rate according to QPS or TPS, and configures emergency strategies to handle over-limit situations; executes degradation strategies based on trigger conditions when the service is unavailable, such as returning a default response or calling a backup service; The context synchronization service coordination is used to ensure the consistency of context information across node services in a distributed multi-active architecture. Through this mechanism, services on different nodes can share key context data, thereby achieving global visibility and consistent processing of request links. Context information is propagated between nodes through efficient serialization and network transmission mechanisms. Through the synchronization protocol, the consistency of state data between nodes is ensured. Eventual consistency and strong consistency models are supported. The specific choice depends on the requirements of the business scenario.

10. A device for implementing a container image generation system based on an agentless service grid framework according to any one of claims 1 to 9, characterized in that: include: Upper-layer applications, container image generation systems, and external data layers; The upper-layer application functions include rule input, policy injection result feedback, multi-active model visualization and service retrieval. The rule input can use SpringBoot to implement RESTfulAPI and gRPC interface to receive JSON or YAML format rules; the rule content is parsed by ANTLR parser, and the responsibility chain is dynamically enhanced with Javassist or ByteBuddy, and the rules are injected in real time, which can take effect without restart; the policy injection feedback uses Prometheus to collect execution data, uses Kafka or RabbitMQ event bus to transmit results, and notifies the upper-layer application through Webhook callback; the multi-active model visualization integrates OpenTelemetry or custom probes to collect node and traffic data, uses Redis for data aggregation, pushes data updates through WebSocket, and combines ECharts to dynamically render topology views; the service retrieval module Consul or Eureka synchronizes service instance information, uses Elasticsearch to build distributed indexes, and provides efficient multi-dimensional query and real-time update services; The data layer operates with external data sources through the persistence layer interface and the transaction management framework, uses the standard JDBC interface to directly operate the database, or simplifies database operations through the ORM framework, combines database transactions and business logic to ensure data integrity, and can collaborate with non-relational databases with the help of distributed cache systems or message queues when processing document-type, time series, key-value and other data; The service policy injection in the container image generation system specifically includes: when the service instance is started, it sends a registration request to the registration center Nacos of the governance policy module to provide instance meta information. The service discovery module dynamically parses the registration table according to the call request and returns a list of qualified service instances. The configuration management function implements dynamic configuration distribution through the subscription-publish mode. After the service instance is started, it subscribes to the relevant configuration update topic. The dynamic configuration data is combined with service discovery to affect the call priority and routing behavior of the service. Combined with dynamic configuration, when the traffic exceeds the threshold or the service performance is reduced, the module automatically triggers the degradation and current limiting mechanism to ensure system stability. The module regularly calls the health check interface of the service instance to actively check the health status. By analyzing the real-time data of the service call, the abnormal service instance is automatically marked. In the overall service call chain, the module synchronizes the call context to ensure that the call information across services is consistent.

Images