Cross-application multi-module flow control method and device based on micro-front-end architecture

Abstract

The invention relates to a cross-application multi-module traffic control method and device based on a micro-front-end architecture. The method comprises the following steps that: a Web server receives a resource request, sets request header information for the resource request, and forwards request flow to Istio-proxy; the Istio-proxy configures a VirtualService flow control strategy and a Destination Rule flow control strategy on the basis of the request header and the URL, and then forwards the flow to a corresponding micro module version; the micro-front-end main application and the sub-application respectively receive the forwarding flow from the Istio, return a request resource response and respectively perform page rendering; a user triggers sub-application page rendering, a sub-application resource request is forwarded to a flow control device through a main application page, and the flow control device forwards the obtained sub-application resource request flow to a Web server based on a preset marked flow control strategy. Through the method, cross-application multi-module fine flow control under a micro-front-end architecture can be realized, the flexibility and reliability of a system are improved, and meanwhile, powerful functions are provided for a development team to manage and optimize user experience.

Description

Technical Field

[0001] The present application belongs to the field of traffic control technology, and in particular, relates to a traffic control method, device, computer-readable storage medium, electronic device, and computer program product based on a micro-front-end architecture across multiple application modules. Background Art

[0002] 1. Popularity and Challenges of Micro-frontend Architecture

[0003] With the continuous evolution of front-end technology, micro-front-end architecture has become an important means to solve complex front-end problems. It decouples business logic and optimizes team collaboration by splitting large monolithic applications into multiple small, independent, and reusable modules. However, with the popularity of micro-front-end architecture, enterprises have encountered the following challenges in actual applications:

[0004] Version control and collaborative release: Under the micro-frontend architecture, modules responsible for different teams may need to release new versions at the same time. How to ensure the collaborative work of these modules and avoid version conflicts has become a major problem.

[0005] Traffic control and user experience: In a multi-module, cross-application micro-frontend architecture, how to achieve refined traffic control and ensure the consistency and stability of user experience is a problem that existing technologies need to solve.

[0006] 2. Limitations of existing flow control methods

[0007] Insufficient request header identification information: In traditional monolithic applications or microservice architectures, traffic control usually relies on identification information in the request header. However, in a micro-frontend architecture, since the main application cannot pass the request header identification information when loading the sub-application, traditional control methods are inadequate.

[0008] Single release strategy: Traditional release strategies such as full release and blue-green deployment are difficult to implement fine-grained traffic control under the micro-frontend architecture and cannot meet the needs of modern DevOps culture.

[0009] Grayscale release is difficult to implement: Grayscale release, as a method of gradually launching new versions, is difficult to implement in a micro-frontend architecture, especially in scenarios across multiple applications and modules.

[0010] 3. Traffic control requirements under micro-frontend architecture

[0011] Fine-grained traffic control: Under the micro-frontend architecture, a method is needed to perform fine-grained traffic control for different modules and versions to meet the needs of different user groups.

[0012] Collaborative release across application modules: Under the micro-frontend architecture, the development team needs a flow control device that can achieve collaborative release across application modules to ensure the smooth launch of new features.

[0013] Support for grayscale release: In order to reduce the risk of launching a new version, a traffic control method that supports grayscale release is needed to test the new version in a smaller range and make adjustments based on feedback. Summary of the invention

[0014] In order to address the above problems and application requirements, this application proposes a new traffic control method and device based on a micro-front-end architecture across multiple application modules.

[0015] The present application aims to provide a method and device for cross-application multi-module traffic control based on a micro-frontend architecture. This method can achieve fine traffic control across multiple application modules under the micro-frontend architecture, improve the flexibility and reliability of the system, and also provide the development team with powerful functions to manage and optimize the user experience.

[0016] In order to achieve the above objectives, this application provides the following technical solutions:

[0017] A first aspect of the present application provides a traffic control method across multiple applications and modules based on a micro-frontend architecture, the method comprising:

[0018] The web server receives and forwards request traffic: The resource request is sent to the web server. After the web server receives the request traffic, the virtual service sets the request header information for it and then forwards the traffic carrying the request header information to Istio-proxy.

[0019] Istio configures traffic control policies: Istio-proxy configures VirtualService traffic control policies and DestinationRule traffic control policies based on the request header and URL context information carried by the Web server forwarding traffic, and then forwards the traffic to the corresponding micromodule version according to the VirtualService and DestinationRule traffic control policies;

[0020] Micro-frontend main application and sub-application delivery control strategy: The micro-frontend main application and sub-application respectively receive forwarding traffic from Istio, return request resource responses, and render pages respectively; the user triggers sub-application page rendering, and forwards the sub-application resource request to the traffic control device through the main application page. The traffic control device forwards the obtained sub-application resource request traffic to the Web server based on the preset marking flow control strategy.

[0021] Optionally, in the method of the present application, the Web server receives and forwards request traffic, including:

[0022] Step 11: Determine the user access entry address and configure the virtual service;

[0023] Step 12: The resource request is sent to the Web server. The virtual service configures the front-end and back-end micro-module traffic proxy, which sets specific request header information for the request traffic based on the URL path prefix.

[0024] Step 13: The web server forwards the traffic carrying the request header information to Istio-proxy.

[0025] Optionally, in the method of the present application, the Istio configuration traffic control policy includes:

[0026] Step 21: Istio-proxy receives forwarded traffic from the web server.

[0027] Step 22: Istio-proxy configures the VirtualService traffic control policy based on the request header and URL context information carried in the forwarded traffic. The VirtualService traffic control policy defines the traffic weights of the main application and sub-application traffic flowing into the corresponding service version;

[0028] Step 23: Istio-proxy matches the service versions of the main application and sub-application based on the request header and URL context information carried in the forwarded traffic, sets the service traffic percentage of the specific version of the micromodule, and configures the DestinationRule traffic control policy;

[0029] Step 24: Forward the traffic to the corresponding micromodule version according to the VirtualService and DestinationRule traffic control policies.

[0030] Optionally, in the method of the present application, the micro-frontend main application and sub-application delivery control strategy includes:

[0031] Step 31: The micro-frontend sub-application receives the forwarded traffic from Istio, returns the requested resource response, renders the sub-application page, and displays the sub-application page;

[0032] Step 32: The micro-frontend main application receives the forwarded traffic from Istio, returns the requested resource response, and renders the main application page. If the user is not logged in, the login page is displayed, and if the user is logged in, the home screen is displayed;

[0033] Step 33: The user selects a sub-application function on the home screen, triggering the rendering of the sub-application page, and forwarding the sub-application resource request to the traffic control device through the main application page;

[0034] Step 34: The flow control device receives the sub-application resource request flow from the main application;

[0035] Step 35: The flow control device matches the fine-grained flow control tag based on the current user attribute;

[0036] Step 36: The flow control device forwards the acquired sub-application resource request flow to the Web server based on the preset marking flow control strategy;

[0037] Step 37: The main application dynamically loads the sub-application resource according to the sub-application resource request URL returned by the traffic control device.

[0038] Optionally, in the method of the present application, the flow control device provides the following two dimensions of custom extensions when performing flow control policy configuration management:

[0039] Dimension 1: Extended definition of microservice version identification based on scenarios: define version identification for different services so that the traffic proxy can forward to the corresponding version identification service;

[0040] Dimension 2: Extended definition of scenario-based microservice flow control identifier: configure the flow control identifier to a specific version of the flow control policy.

[0041] Optionally, the method of the present application further includes: configuring a version identification definition and a flow control identification definition in the flow control device;

[0042] The flow control device generates a resource request URL according to the flow control configuration rules.

[0043] A second aspect of the present application provides a traffic control device across multiple applications and modules based on a micro-frontend architecture, the device comprising:

[0044] Web server module: used to process static resources and act as a forward and reverse proxy;

[0045] Istio-proxy module: used to mediate inbound and outbound traffic of all services in the service mesh;

[0046] destination_rule module: used to define the policy set applied to the service request after routing occurs; the policy set includes: load balancing policy, service instance health check policy and circuit breaker setting policy;

[0047] virtual_service module: used to define the routing of requests to services, while allowing users to configure routing rules, fault injection, and retry strategies;

[0048] Main application module: As the base application of the micro front-end, it is used to carry the scheduling rendering and application routing control of sub-applications;

[0049] Sub-application module: used to convert each functional module in the product into an independent executable front-end application system;

[0050] Traffic control device module: responsible for implementing traffic control strategies across multiple application modules.

[0051] Optionally, in the device of the present application, the traffic control device module supports the extended definition of microservices in two dimensions: version identification and flow control identification, returns the resource request URL according to the defined traffic rules and policies of the control service, dynamically adjusts the traffic flowing into each sub-application module, and realizes grayscale release and A / B testing functions.

[0052] A third aspect of the present application provides an electronic device, comprising: a memory and a processor;

[0053] Memory: used to store computer programs;

[0054] Processor: used to execute the computer program to implement the steps of the aforementioned traffic control method across multiple applications and modules based on the micro-frontend architecture.

[0055] The fourth aspect of the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the aforementioned traffic control method across multiple applications and modules based on a micro-frontend architecture are implemented.

[0056] In summary, this application proposes a method and device for cross-application multi-module traffic control based on a micro-frontend architecture. The method and device of this application have the following advantages:

[0057] (1) Traffic control strategy exclusive to micro-frontend architecture: This application proposes a traffic control strategy suitable for micro-frontend architecture. By establishing a set of traffic control devices between the main application and the sub-application, fine control of the traffic of the micro-frontend main application requesting to load sub-application resources is achieved.

[0058] (2) Collaborative release across application modules: The traffic control device of this application can realize collaborative release across application modules, ensuring that the new version is launched simultaneously in multiple modules, thereby improving release efficiency.

[0059] (3) Grayscale release and user experience optimization: Through this application traffic control method, the development team can easily implement grayscale release and gradually expand the user coverage of the new version while minimizing the impact on the production environment and ensuring user experience.

[0060] (4) Flexible adaptation to various release scenarios: The traffic control method and device of this application support various release scenarios, including full release, blue-green deployment, grayscale release, etc., which can meet different business needs.

[0061] (5) The method and device of this application support all micro-frontend solutions, and provide a new solution for traffic control under the micro-frontend architecture, which helps enterprises cope with the rapidly developing software development needs, improve software quality, reduce release risks, and achieve continuous iteration and optimization of business. In the current highly competitive environment of the Internet industry, the technology of this application has broad application prospects and significant market value.

[0062] Other features and advantages of the present application will be described in the following description, and partly become apparent from the description, or understood by practicing the present application. The purpose and other advantages of the present application can be realized and obtained by the techniques indicated in the description, claims and drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0063] In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, a brief introduction is given below to the drawings required for use in the embodiments or the description of the prior art. Obviously, the drawings described below are some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without paying any creative work.

[0064] Figure 1 A structural diagram of a traffic control device based on a micro-frontend architecture across multiple application modules provided in one embodiment of the present application.

[0065] Figure 2 A schematic diagram of a micro-frontend system architecture provided for an embodiment of the present application.

[0066] Figure 3 An overall flow chart of a traffic control method across multiple modules of an application based on a micro-frontend architecture is provided for an embodiment of the present application.

[0067] Figure 4 This is a flowchart for implementing step 1 in a method for cross-application multi-module traffic control based on a micro-frontend architecture according to an embodiment of the present application.

[0068] Figure 5 This is a flowchart for implementing step 2 in a method for cross-application multi-module traffic control based on a micro-frontend architecture according to an embodiment of the present application.

[0069] Figure 6 A schematic diagram of the delivery process of a micro-frontend main application and sub-applications in a traffic control method across multiple modules of a micro-frontend architecture provided in an embodiment of the present application. DETAILED DESCRIPTION

[0070] In order to make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme in the embodiments of the present application will be clearly and completely described below in conjunction with the drawings in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application.

[0071] As used herein, the term “including” and its variations are open inclusions, ie, “including but not limited to”; the term “based on” means “based at least in part on”; and the term “one embodiment” means “at least one embodiment”.

[0072] It should be noted that the modifications of "one" and "plurality" mentioned in the present application are illustrative rather than restrictive, and those skilled in the art should understand that unless the context clearly indicates otherwise, it should be understood as "one or more".

[0073] Explanation of terms

[0074] SGUI: The full name of SGUI is Airline Selling GUI, which is the airline sales front end. SGUI is a SAT service interface provided by the managed service software in the field of PSS product sales. It integrates the workflow of actual business scenarios such as ticket control, sales processing, query statistics, etc. for air tickets and their additional services, and provides a graphical management and operation interface to airline sales staff and sales management personnel.

[0075] Micro-frontends: Micro-frontends is an architecture similar to microservices. It applies the concept of microservices to the browser side, that is, it transforms the Web application from a single monolithic application to an application that aggregates multiple small front-end applications. Each front-end application can also run, develop, and deploy independently. Micro-frontends are not just front-end frameworks or tools, but a set of architecture systems.

[0076] Qiankun: Alibaba's open source micro-frontend solution is currently the most widely used and most complete. It is encapsulated based on single-spa.

[0077] MicroApp: JD.com's open source micro-frontend solution draws on the idea of ​​WebComponent and is the lowest-cost solution for accessing micro-frontends on the market.

[0078] Apache (Web server): Apache is an open source Web server software used to process requests from clients. In this application, Apache can be used as a server for one or more micro-frontend modules, processing static resources or acting as a forward and reverse proxy.

[0079] Istio: is an open source service mesh that provides network layer abstraction for distributed microservice architecture, making communication between services more secure and reliable. Here are some terms related to Istio:

[0080] (1) Envoy: Envoy is a high-performance C++ distributed proxy for the data plane in the service mesh. It is the default proxy of Istio, hereinafter referred to as istio-proxy, which is used to mediate the inbound and outbound traffic of all services in the service mesh.

[0081] (2) VirtualService: VirtualService defines how to route requests to services. It allows users to configure routing rules, fault injection, and retry strategies, etc.

[0082] (3) DestinationRule: DestinationRule defines the set of policies applied to service requests after routing occurs, including load balancing policies, health checks of service instances, and circuit breaker settings.

[0083] Main application: As the base application of the micro front-end, it is the entrance to the entire application and is responsible for scheduling and rendering sub-applications and application routing control.

[0084] Sub-application: An executable front-end application. Usually each functional module in the product is treated as an independent application system.

[0085] Traffic control device: SGUI's self-developed traffic controller is the core component of this application and is responsible for implementing traffic control strategies across multiple application modules. It supports extended definitions of microservices in multiple dimensions such as version identification and flow control identification, controls the traffic rules and strategies of services according to the definition, returns resource request URLs, dynamically adjusts the traffic flowing into each sub-application module, and implements grayscale release, A / B testing and other functions.

[0086] Figure 1 The figure shows a flow control device based on a micro-frontend architecture across multiple application modules proposed in this application. Figure 2 The micro-frontend system architecture proposed in this application is shown.

[0087] The device of the present application includes: Apache module, Istio-proxy module, destination_rule module, virtual_service module, main application module, sub-application module, and flow control device module. By integrating the above modules, fine flow control across multiple application modules is achieved under the micro-front-end architecture, which improves the flexibility and reliability of the system, and also provides the development team with powerful functions to manage and optimize the user experience.

[0088] Figure 3 The present application provides a method for cross-application multi-module flow control based on a micro-frontend architecture, comprising the following steps:

[0089] Step 1 (shown as process 1 in the figure): Apache receives and forwards request traffic.

[0090] Figure 4 The following figure shows the implementation process of step 1. The resource request is sent to Apache. After Apache receives the request traffic, the virtual service sets the request header information for it and then forwards the traffic carrying the request header information to Istio-proxy, including:

[0091] (1) Determine the user access entry address and configure the virtual service;

[0092] (2) The virtual service configures the front-end and back-end micro-module traffic proxy, which sets specific request header information and forwards the traffic carrying the request header information to the specific micro-module service.

[0093] Step 2 (shown as process 2 in the figure): Istio configures traffic control policy.

[0094] Figure 5 The figure shows the implementation process of step 2. Istio-proxy configures the VirtualService traffic control policy based on the request header and URL context information carried by the Apache forwarding traffic, then matches the service version based on the request header and URL context information, sets the service traffic percentage, configures the DestinationRule traffic control policy, and then forwards the traffic to the corresponding micromodule version according to the configured policy, including:

[0095] (1) Istio-proxy receives proxy forwarding traffic from Apache;

[0096] (2) Based on the request header and URL context information carried by the forwarded traffic, configure the VirtualService and DestinationRule traffic control policies, and forward the traffic to the specific micromodule version according to the configured policies (policy granularity: can be classified by request header and URL context information, and set the service traffic percentage of a specific micromodule version).

[0097] Step 3: Micro-frontend main application and sub-application delivery control strategy.

[0098] Figure 6 The figure shows the delivery process of the micro-frontend main application and sub-application in this embodiment, including:

[0099] (1) The micro-frontend sub-application receives traffic forwarded by Istio, returns a resource request response, renders the sub-application page, and displays the sub-application page;

[0100] (2) The micro-frontend main application receives the traffic forwarded by Istio, returns the requested resource response, and renders the main application page. If the user is not logged in, the login page is displayed, and if the user is logged in, the home screen is displayed;

[0101] (3) The user selects a menu or page function (sub-application function) of interest on the home screen, triggering sub-application page rendering, and the sub-application resource request is forwarded to the traffic control device;

[0102] (4) The flow control device receives resource request flow from the main application;

[0103] (5) The flow control device matches the fine-grained flow control tag based on the current user attribute and the tag flow control strategy preset by the flow control device, and forwards the sub-application resource request traffic to Apache.

[0104] In order to better understand the technical solution of the present application, the key steps in the implementation process of the method of the present application are further described in detail with examples of the following business scenarios.

[0105] 1. Apache receives and forwards request traffic

[0106] Configure the virtual service name: example.domain.com, configure the micromodule traffic proxy under this virtual service, set specific request header information for the proxy, and forward the traffic carrying the request header information to the specific micromodule service.

[0107] Note: Set the request header according to the URL path prefix.

[0108] Configuration example:

[0109] <VirtualHost*:80>

[0110] ServerName example.domain.com

[0111] DocumentRoot" / path / to / website"

[0112] #Define the proxy, here configure the istio_proxy cluster ip

[0113] <Proxy balancer: / / mycluster>

[0114] BalancerMember http: / / istio_proxy_ip1:80

[0115] BalancerMember http: / / istio_proxy_ip2:80

[0116] BalancerMember http: / / istio_proxy_ip3:80

[0117] ProxySet stickysession=ROUTEID

[0118]

[0119] #==========Main application proxy forwarding rules==================

[0120] ProxyPass / main-app balancer: / / mycluster /

[0121] ProxyPassReverse / main-app balancer: / / mycluster /

[0122] ProxyPass / sub-app1 balancer: / / mycluster / sub-app1

[0123] ProxyPassReverse / sub-app1 balancer: / / mycluster / sub-app1

[0124] ProxyPass / sub-app2 balancer: / / mycluster / sub-app2

[0125] ProxyPassReverse / sub-app2 balancer: / / mycluster / sub-app2

[0126] #===========Sub-application v1 version proxy forwarding rules=============

[0127] #Define proxy delivery rules for sub-application 1

[0128] ProxyPass / v1 / sub-app1 balancer: / / mycluster / sub-app1

[0129] ProxyPassReverse / v1 / sub-app1 balancer: / / mycluster / sub-app1

[0130] #Define the proxy transfer rules for sub-application 2

[0131] ProxyPass / v1 / sub-app2 balancer: / / mycluster / sub-app2

[0132] ProxyPassReverse / v1 / sub-app2 balancer: / / mycluster / sub-app2

[0133] #===========Sub-application v2 version proxy forwarding rules=============

[0134] #Define proxy delivery rules for sub-application 1

[0135] ProxyPass / v2 / sub-app1 balancer: / / mycluster / sub-app1

[0136] ProxyPassReverse / v2 / sub-app1 balancer: / / mycluster / sub-app1

[0137] #Define the proxy transfer rules for sub-application 2

[0138] ProxyPass / v2 / sub-app2 balancer: / / mycluster / sub-app2

[0139] ProxyPassReverse / v2 / sub-app2 balancer: / / mycluster / sub-app2

[0140] #Define the Location block here to match a specific path (regular matching is supported) and set the header.

[0141] <Location" / v1 / server">

[0142] Header set version "v1"

[0143]

[0144] <Location" / v2 / server">

[0145] Header set version "v2"

[0146]

[0147]

[0148] 2. Istio configuration traffic control policy

[0149] (1)Configure DestinationRule

[0150] Define the target service version. This configuration file can be automatically generated and applied according to the version generation rules based on the deployed application version. The following defines the available service versions of the main application and sub-application respectively.

[0151] Configuration example:

[0152] apiVersion:networking.istio.io / v1beta1

[0153] kind:DestinationRule

[0154] metadata:

[0155] name:main-app

[0156] namespace:sgui

[0157] spec:

[0158] host:main-app.sgui.svc.cluster.local

[0159] subsets:

[0160] -labels:

[0161] version:1-0-0

[0162] name:1-0-0

[0163] -labels:

[0164] version:1-0-1

[0165] name:1-0-1

[0166] -labels:

[0167] version:1-0-2

[0168] name:1-0-2

[0169] #Define the target service version of the sub-application sub-app1

[0170] apiVersion:networking.istio.io / v1beta1

[0171] kind:DestinationRule metadata:

[0172] name:sub-app1

[0173] namespace:sgui

[0174] spec:

[0175] host:sub-app1.sgui.svc.cluster.local subsets:

[0176] -labels:

[0177] version:1-0-0

[0178] name:1-0-0

[0179] -labels:

[0180] version:1-0-1

[0181] name:1-0-1

[0182] -labels:

[0183] version:1-0-2

[0184] name:1-0-2

[0185] #Define the target service version of the sub-application sub-app2 apiVersion:networking.istio.io / v1beta1kind:DestinationRule metadata:

[0186] name:sub-app2

[0187] namespace:sgui

[0188] spec:

[0189] host:sub-app2.sgui.svc.cluster.local subsets:

[0190] -labels:

[0191] version:1-0-0

[0192] name:1-0-0

[0193] -labels:

[0194] version:1-0-1

[0195] name:1-0-1

[0196] -labels:

[0197] version:1-0-2

[0198] name:1-0-2

[0199] (2)Configure VirtualService

[0200] Based on the request URL and request header information, define the traffic weights of the main application and sub-application traffic flowing into the corresponding version.

[0201] Configuration example:

[0202] kind:"VirtualService"

[0203] metadata:

[0204] name:"sgui"

[0205] namespace:"sgui"

[0206] spec:

[0207] gateways:

[0208] -"new-istio-system / sgui"

[0209] hosts:

[0210] -"sgui.travelsky.com.cn"

[0211] http:

[0212] #===========Official version routing rule configuration==========

[0213] #Sub-application sub-app1 routing rules, version points to Release version

[0214] -match:

[0215] -uri:

[0216] prefix:" / sub-app1"

[0217] name:"Release"

[0218] route:

[0219] -destination:

[0220] host:"sub-app1.sgui.svc.cluster.local"

[0221] subset:"1-0-0"

[0222] headers:

[0223] response:{}

[0224] weight:100

[0225] #Sub-application sub-app2 routing rules, version points to Release version

[0226] -match:

[0227] -uri:

[0228] prefix:" / sub-app2"

[0229] name:"Release"

[0230] route:

[0231] -destination:

[0232] host:"sub-app2.sgui.svc.cluster.local"

[0233] subset:"1-0-1"

[0234] headers:

[0235] response:{}

[0236] weight:100

[0237] #============Public beta version v1 routing rule configuration========== #Sub-application sub-app1 routing rules, version points to Beta version - match:

[0238] -headers:

[0239] Version:

[0240] exact:"v1"

[0241] uri:

[0242] prefix:" / sub-app1"

[0243] name:"Beta"

[0244] route:

[0245] -destination:

[0246] host:"sub-app1.sgui.svc.cluster.local"

[0247] subset:"1-0-0"

[0248] headers:

[0249] response:{}

[0250] weight:100

[0251] #Sub-application sub-app2 routing rules, version points to Beta version - match:

[0252] -headers:

[0253] Version:

[0254] exact:"v1"

[0255] uri:

[0256] prefix:" / sub-app2"

[0257] name:"Beta"

[0258] route:

[0259] -destination:

[0260] host:"sub-app2.sgui.svc.cluster.local"

[0261] subset:"1-0-1"

[0262] headers:

[0263] response:{}

[0264] weight:100

[0265] #===========Beta version v2 routing rule configuration========== #Sub-application sub-app1 routing rules, version points to Alpha version - match:

[0266] -headers:

[0267] Version:

[0268] exact:"v2"

[0269] uri:

[0270] prefix:" / sub-app1"

[0271] name:"Beta"

[0272] route:

[0273] -destination:

[0274] host:"sub-app1.sgui.svc.cluster.local"

[0275] subset:"1-0-0"

[0276] headers:

[0277] response:{}

[0278] weight:100

[0279] #Sub-application sub-app2 routing rules, version points to Alpha version - match:

[0280] -headers:

[0281] Version:

[0282] exact:"v2"

[0283] uri:

[0284] prefix:" / sub-app2"

[0285] name:"Beta"

[0286] route:

[0287] -destination:

[0288] host:"sub-app2.sgui.svc.cluster.local"

[0289] subset:"1-0-1"

[0290] headers:

[0291] response:{}

[0292] weight:100

[0293] #===You can expand other versions according to your application, and configure the same routing rules as v1 and v2===

[0294] #Main application main-app routing rules, the version points to the Release version

[0295] -match:

[0296] -uri:

[0297] prefix:" / "

[0298] name:"Release"

[0299] route:

[0300] -destination:

[0301] host:"main-app.sgui.svc.cluster.local"

[0302] subset:"1-0-0"

[0303] headers:

[0304] response:{}

[0305] 3. Micro-frontend main application and sub-application delivery control strategy

[0306] (1) Flow control device (in this embodiment, the flow controller) Flow control policy configuration management Flow control device provides customization and expansion in two dimensions

[0307] The first dimension is: scenario-based microservice version identification extension definition

[0308] This dimension requires synchronous configuration of Apache. For details, please refer to the (Apache receives and forwards request traffic) section. Define version identifiers for different services so that the traffic proxy forwards to the corresponding version identifier service. The following table shows examples of version identifiers for different scenarios:

[0309]

[0310]

[0311] The second dimension is: scenario-based microservice flow control identifier extension definition

[0312] The following table shows the flow control strategy for configuring the flow control identifier of the flow control device to a specific version:

[0313]

[0314] (2) The flow control device generates a resource request URL according to the flow control rules

[0315] Scenario example: User A is a product staff member. The running version of the production sub-application sub-app1 is 1.0.0. The product staff member needs to verify whether the functions of version 1.0.1 of the sub-application sub-app1 to be put into production meet business requirements.

[0316] In this scenario, we make the following configuration in the flow control device:

[0317] Configure version identification definition: classify version 1.0.0 of the sub-app1 service as the Release version, configure the context of the Release version URL as / , classify version 1.0.1 as the Alpha version, and configure the context of the Alpha version URL as / v2.

[0318] Configure the flow control identifier definition: Configure the default configuration. When there is no specific flow control identifier configuration, the traffic is directed to the Release version of the service sub-app1. Set the flow control identifier for the sub-app1 service: User A, and the traffic is directed to the Alpha version of the service sub-app1.

[0319] The flow control device returns the resource request URL according to the flow control configuration rules: The flow control device receives the / sub-app1 / sources resource request and returns the resource request rule url: / v2 / sub-app1 / sources according to the flow control configuration rules.

[0320] Code example:

[0321] @RestController

[0322] public class AppController {

[0323] / / Inject the base URL in the configuration file

[0324] @Value("${app.base-url}")

[0325] private String baseUrl;

[0326] / / Assume this is a method to get the user's application configuration from a database or other storage

[0327] Private Map<String,String> getControlRulesFromLabls({

[0328] / / Get the current user information

[0329] User current_user=currentUserProvider.getCurrentUser();

[0330] / / In actual application, according to the current user attributes, query the database to obtain the flow control configuration rules, and match the rule priority from high to low with the least privilege

[0331] / / For example: the flow control identifier is configured with user, role, airline, and agent, and the rule priority matching is: user>role>agent>airline

[0332] / / Here returns a sample flow control configuration rule

[0333] Map<String,String> rules = new HashMap<>();

[0334] / / Assume that we have a specific rule based on the user ID

[0335] rules.put(" / sub-app1 / sources"," / v2 / sub-app1 / sources");

[0336] return rules;

[0337] }

[0338] / / Define the AppConfig class to represent application configuration

[0339] public static class AppConfig{

[0340] private String name;

[0341] private String activeRule;

[0342] private String entry;

[0343] public AppConfig(String name, String activeRule, String entry) {

[0344] this.name = name;

[0345] this.activeRule = activeRule;

[0346] this.entry = entry;

[0347] }

[0348] / / Getters and Setters

[0349] public String getName() {

[0350] return name;

[0351] }

[0352] public String getActiveRule() {

[0353] return activeRule;

[0354] }

[0355] public String getEntry() {

[0356] return entry;

[0357] }

[0358] }

[0359] / / API endpoint for getting sub - application resource information of the current user

[0360] @GetMapping(" / api / getUserAppsApi")

[0361] public ResponseEntity<List <appconfig>>getUserAppsApi(@Request Header("user-id")String userId,

[0362] @RequestParam("resource")String resource){

[0363] if(userId==null||userId.isEmpty()){

[0364] return ResponseEntity.status(401).build();

[0365] }

[0366] / / Get the flow control configuration rules for the current user

[0367] Map<String,String> flowControlRules=getFlowControlRules(userId);

[0368] / / Get the rule URL based on the resource request

[0369] String ruleUrl=flowControlRules.getOrDefault(resource,"");

[0370] / / If there is a corresponding flow control rule, return the corresponding AppConfig

[0371] List <appconfig>userApps=new ArrayList<>();

[0372] if(!ruleUrl.isEmpty()){

[0373] userApps.add(new AppConfig("SubApp1",ruleUrl,baseUrl+ruleUrl));

[0374] }

[0375] return ResponseEntity.ok(userApps);

[0376] }

[0377] }

[0378] (3) The main application dynamically loads sub-application resources

[0379] The main application dynamically loads the sub-application resources according to the sub-application request resource URL returned by the flow control device.

[0380] Code example:

[0381] / / Get the sub-application resource information of the current user from the backend service

[0382] const apps=await getUserAppsApi();

[0383] / **

[0384] * Load sub-applications based on routing information

[0385] *@param{string}path routing path information

[0386] * /

[0387] const activationHandleChange=async(path)=>{

[0388] / / Make sure apps is an array and each element has activeRule and name properties if (!Array.isArray(apps) || !apps.every(app=>app.hasOwnProperty('activeRule')&&app.hasOwnProperty('name'))) {

[0389] console.error('Apps configuration is invalid.');

[0390] return;

[0391] }

[0392] / / Check if the current path matches any sub-application activation rules

[0393] const activeRules=apps.map(app=>app.activeRule);

[0394] const isMicro=activeRules.some(rule=>path.startsWith(rule));

[0395] / / If the current path does not match any sub-application activation rules, return directly

[0396] if(!isMicro)return;

[0397] / / Find the sub-application configuration that matches the current path

[0398] const conf=apps.find(app=>path.startsWith(app.activeRule));

[0399] / / If no matching configuration is found, return directly

[0400] if (!conf) return;

[0401] / / Update the displayed sub-application name

[0402] showAppName.value=conf.name;

[0403] / / Load the sub-application

[0404] const micro=loadMicroApp({

[0405] ...conf,

[0406] container:`#${containerPre}-${conf.name}`

[0407] });

[0408] / / Store the loaded sub-applications in microList

[0409] microList[conf.name]=micro;

[0410] / / Wait for repeated calls to the sub-application loading function

[0411] await repeatedCallsMicro(micro, loadingInstance);

[0412] };

[0413] The flow chart and block diagram in the accompanying drawings illustrate the possible architecture, function and operation of the device, method and computer program product according to various embodiments of the present application. In this regard, each square box in the flow chart or block diagram can represent a module, program segment or a part of code, and the module, program segment or a part of code contains one or more executable instructions for realizing the specified logical function. It should also be noted that each square box in the block diagram and / or flow chart, and the combination of the square boxes in the block diagram and / or flow chart can be realized by a special hardware-based system that performs the specified function or operation, or can be realized by a combination of special hardware and computer instructions.

[0414] The names of messages or data exchanged between multiple modules in the implementation manner of the present application are only used for illustrative purposes and are not used to limit the scope of these messages or data.

[0415] Furthermore, an embodiment of the present application also discloses an electronic device, including: a memory and a processor;

[0416] The memory is used to store a computer program, and the processor is used to run the computer program to implement the steps of the above-mentioned traffic control method based on a micro-front-end architecture across multiple applications and modules.

[0417] It is understandable that, in addition to the memory and the processor, the electronic device may also include an input device such as a keyboard, an output device such as a display, and a communication module. The input device, the output device, and the communication module communicate with the processor via an I / O interface (i.e., an input / output interface).

[0418] Computer program code for performing the operations of the present application may be written in one or more programming languages ​​or a combination thereof, including, but not limited to, object-oriented programming languages, such as Java, Smalltalk, C++, and conventional procedural programming languages, such as "C" or similar programming languages. The program code may be executed entirely on the user's computer, partially on the user's computer, as a separate software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0419] Furthermore, the present application also discloses a computer-readable storage medium. When the instructions in the computer-readable storage medium are executed by a processor of an electronic device, the electronic device can execute the various steps of the traffic control method based on a micro-front-end architecture across multiple applications and modules disclosed in the present application.

[0420] In the context of the present application, a computer-readable storage medium may be a tangible medium, more specific examples of which would include a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), optical fiber, a portable compact disk read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing.

[0421] In particular, according to an embodiment of the present application, the process described in the flowchart can be implemented as a computer software program. For example, an embodiment of the present application includes a computer program product, which includes a computer program carried on a non-transitory computer-readable medium, and the computer program contains a program code for executing the flow control method based on a micro-frontend architecture across multiple application modules disclosed in the present application. In such an embodiment, the computer program can be downloaded and installed from the network through a communication device, or installed from a storage device, or installed from a ROM. When the computer program is executed by a processing device, the above-mentioned functions defined in the method of the embodiment of the present application are executed.

[0422] Although several specific implementation details are included in the above discussion, these should not be interpreted as limiting the scope of the present application. The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of disclosure involved in the present application is not limited to the technical solutions formed by a specific combination of the above technical features, but also should cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above public concept.

[0423] Those skilled in the art should also understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein; and these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application.< / appconfig> < / appconfig>

Claims

1. A traffic control method across multiple application modules based on a micro-frontend architecture, characterized in that: The method comprises: The web server receives and forwards request traffic: The resource request is sent to the web server. After the web server receives the request traffic, the virtual service sets the request header information for it and then forwards the traffic carrying the request header information to Istio-proxy. Istio configures traffic control policies: Istio-proxy configures VirtualService traffic control policies and DestinationRule traffic control policies based on the request header and URL context information carried by the Web server forwarding traffic, and then forwards the traffic to the corresponding micromodule version according to the VirtualService and DestinationRule traffic control policies; Micro-frontend main application and sub-application delivery control strategy: The micro-frontend main application and sub-application respectively receive forwarding traffic from Istio, return request resource responses, and render pages respectively; the user triggers sub-application page rendering, and forwards the sub-application resource request to the traffic control device through the main application page. The traffic control device forwards the obtained sub-application resource request traffic to the Web server based on the preset marking flow control strategy.

2. The method according to claim 1, characterized in that: The web server receives and forwards request traffic, including: Step 11: Determine the user access entry address and configure the virtual service; Step 12: The resource request is sent to the Web server. The virtual service configures the front-end and back-end micro-module traffic proxy, which sets specific request header information for the request traffic based on the URL path prefix. Step 13: The web server forwards the traffic carrying the request header information to Istio-proxy.

3. The method according to claim 1, characterized in that The Istio configuration traffic control policy includes: Step 21: Istio-proxy receives forwarded traffic from the web server. Step 22: Istio-proxy configures the VirtualService traffic control policy based on the request header and URL context information carried in the forwarded traffic. The VirtualService traffic control policy defines the traffic weights of the main application and sub-application traffic flowing into the corresponding service version; Step 23: Istio-proxy matches the service versions of the main application and sub-application based on the request header and URL context information carried in the forwarded traffic, sets the service traffic percentage of the specific version of the micromodule, and configures the DestinationRule traffic control policy; Step 24: Forward the traffic to the corresponding micromodule version according to the VirtualService and DestinationRule traffic control policies.

4. The method according to claim 1, characterized in that The micro-frontend main application and sub-application delivery control strategy includes: Step 31: The micro-frontend sub-application receives the forwarded traffic from Istio, returns the requested resource response, renders the sub-application page, and displays the sub-application page; Step 32: The micro-frontend main application receives the forwarded traffic from Istio, returns the requested resource response, and renders the main application page. If the user is not logged in, the login page is displayed, and if the user is logged in, the home screen is displayed; Step 33: The user selects a sub-application function on the home screen, triggering the rendering of the sub-application page, and forwarding the sub-application resource request to the traffic control device through the main application page; Step 34: The flow control device receives the sub-application resource request flow from the main application; Step 35: The flow control device matches the fine-grained flow control tag based on the current user attribute; Step 36: The flow control device forwards the acquired sub-application resource request flow to the Web server based on the preset marking flow control strategy; Step 37: The main application dynamically loads the sub-application resource according to the sub-application resource request URL returned by the traffic control device.

5. The method according to claim 1, characterized in that The flow control device provides the following two dimensions of custom extensions when performing flow control policy configuration management: Dimension 1: Extended definition of microservice version identification based on scenarios: define version identification for different services so that the traffic proxy can forward to the corresponding version identification service; Dimension 2: Extended definition of scenario-based microservice flow control identifier: configure the flow control identifier to a specific version of the flow control policy.

6. The method according to claim 1, characterized in that The method further includes: configuring a version identification definition and a flow control identification definition in a flow control device; The flow control device generates a resource request URL according to the flow control configuration rules.

7. A traffic control device based on a micro-frontend architecture across multiple application modules, characterized in that: The device comprises: Web server module: used to process static resources and act as a forward and reverse proxy; Istio-proxy module: used to mediate inbound and outbound traffic of all services in the service mesh; destination_rule module: used to define the policy set applied to the service request after routing occurs; the policy set includes: load balancing policy, service instance health check policy and circuit breaker setting policy; virtual_service module: used to define the routing of requests to services, while allowing users to configure routing rules, fault injection, and retry strategies; Main application module: As the base application of the micro front-end, it is used to carry the scheduling rendering and application routing control of sub-applications; Sub-application module: used to convert each functional module in the product into an independent executable front-end application system; Traffic control device module: responsible for implementing traffic control strategies across multiple application modules.

8. The device according to claim 7, characterized in that The flow control device module supports the extended definition of microservices in two dimensions: version identification and flow control identification. According to the defined flow rules and policies of the control service, it returns the resource request URL, dynamically adjusts the flow flowing into each sub-application module, and realizes grayscale release and A / B testing functions.

9. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by the processor, the steps of the traffic control method across multiple applications and modules based on a micro-frontend architecture are implemented as described in any one of claims 1-8.

10. An electronic device, characterized in that: include: Memory and processor; Memory: used to store computer programs; Processor: used to execute the computer program to implement the steps of the traffic control method based on micro-frontend architecture across applications and multiple modules as described in any one of claims 1-8.

Images