There is a summary of the landing of the micro-front end of the praise industry

In April 2020, the front-end team of Zingye completed the design and migration of Meiye's PC architecture from a single SPA to a micro front-end architecture after 7 months. The PPT was available in June last year, and now I will organize it to form an article and share it with you.

Head Figure

content

• Part 01 "Big talk" micro front end

  • What is a micro frontend

  • background

  • Target

  • achieve value

  • shortcoming

• Part 02 Architecture and Engineering

  • What are the micro front-end solutions

  • Architecture design and selection considerations

  • demand analysis

  • Design Principles

  • Application Architecture Diagram

  • system split

  • Timing diagram

  • Front-end flow chart

• Part 03 Key Technologies

  • List of key technologies

  • Architecture Core

  • Registration Center

  • code reuse

  • sub app

• Part 04 Project Implementation

  • The way of thinking before the project

  • Refer to the micro-frontend information

  • Carry out a PC architecture optimization plan

  • risk

  • Iterative project

  • progress

  • follow-up plan

Part 01 "Big talk" micro front end

Explain the cause and effect of this matter

What is a micro frontend

It is not so difficult to directly give a definition to answer this question, but students who have not been exposed to it may not understand it. So the background needs to be introduced first, and then the explanation will make it easier to understand.

web development 1

This picture shows the three periods of division of labor after the front-end of software development:

1. Monolithic application: In the early stage of software development and some small web site architectures, the front-end and back-end database personnel are in the same team, and everyone's code assets are in the same physical space. With the development of the project, our code assets develop to To a certain extent, it was turned into a boulder.

2. Front-end and back-end separation: The front-end and back-end teams are separated, and the software architecture is also separated. They rely on agreements to collaborate with each other, and everyone's production materials begin to be physically separated.

3. Microservices: The back-end team divides the vertical field according to the actual business. The complexity of a single back-end system is divided and conquered, and the back-end services rely on remote calls to interact. At this time, when the front-end needs to call the back-end service, it needs to add a layer of API gateway or BFF for access.

web development 2

Now the working model of the R&D teams of many Internet companies is closer to this, and the entire product is split into multiple business groups in the amoeba model.
Under this R&D process and organizational model, the back-end architecture has been formed into a split and adjustable form through microservices. If the front-end is still in the monolithic application mode, let alone other things, the front-end architecture has brought a bottleneck to collaboration.
In addition, with the advent of the Web 3.0 era, front-end applications are getting heavier and heavier. With the development and iteration of business and the accumulation of project codes, front-end applications have evolved into a behemoth under the diligent production. Humans have limited ability to pay attention to complexity, and the dimension is probably maintained at around 5~8. There are too many production materials for monomer application polymerization, too many dimensions that bring complexity, and it is easy to cause more problems. In short, traditional SPAs have been unable to cope with the challenges of rapid business development to the underlying technology.
Our product and front-end projects also encountered this problem. How to solve this problem?
In fact, the development of the back-end has given a solution that can be used for reference, and the micro-front-end architecture referring to the micro-service/micro-kernel in concept should emerge from time to time.
To solve this problem, under the guidance of the law of attraction, we encountered the micro-frontend architecture and verified that it really helped us solve this problem.

Now to give our microfrontend such a definition:

Micro frontend is an architecture similar to microkernel, which applies the concept of microservices to the browser side, that is, transforms a web application from a single application to an application that aggregates multiple small front-end applications into one. Multiple front-end applications can also run independently, develop independently, and deploy independently.

background

background

1. As a single application, Meiye PC has experienced 4 years of iterative development. The amount of code and dependencies are huge. According to statistics, there are more than 600,000 lines of pure business code.

2. In terms of engineering, the speed of construction and deployment is extremely slow, the local debugging experience of developers is poor, and the efficiency is low. A simple build + release takes more than 7+8=15 minutes

3. In terms of code, the coupling of business code is serious, and the scope of influence is difficult to converge, which has brought online bugs and failures in the "butterfly effect" style many times.

4. In terms of technology, the cost of changes and regressions brought about by general dependency upgrades is huge, and the daily needs and technical upgrades related to dependency packages such as Zent components and mid-stage components are almost impossible to push.

5. In terms of testing, a single application should be released by multiple people and multiple projects. The total number of single application releases is high and very frequent. Each integration test has the risk of conflict resolution and exposure of new problems.

6. In terms of organization, a single application cannot well cope with the development organization form of the business team, the boundary responsibilities are not clear, and the module development is easy to interfere

7. In terms of architecture, the front-end cannot form a corresponding domain application development model with the back-end, which is not conducive to the sinking of the business, nor can it support the servitization of front-end capabilities and the evolution dependence on the technology stack.

In general, the bloated monolithic application model brings unbearable difficulties to developers, and brings a big bottleneck to quickly supporting the business, and there is no confidence in the continued expansion of the next business. It is very urgent and valuable to adjust the architecture of the Meiye PC

Target

1. At the business structure level, focusing on the business form, project structure and development trend of Meiye PC, the front-end application developed by large-scale multi-team collaborative development is regarded as a combination of functions produced by multiple independent teams.

2. At the technical architecture level, large-scale front-end applications are decoupled and divided into base applications, micro-front-end kernels, registration centers, and several independently developed and deployed subsystems to form a centralized governance system of distributed systems.

3. In terms of software engineering, ensure the gradual migration and transformation, and ensure the normal operation of new and old applications.

achieve value

business value

• The atomization of products with front-end dimensions is realized. If new services are integrated, sub-applications can be quickly integrated by other services

• Divided by business areas, multi-person collaboration on projects under organizational structure adjustment has clearer responsibilities and lower costs, and adapts to organizational structure adjustment

• Slow down the entropy increase of the system and pave the way for business development.

Engineering value

• The independent development and deployment of business sub-applications is realized, and the waiting time for construction and deployment is reduced from 15 minutes to 1.5 minutes

• Supports a progressive architecture, the dependencies between the system sub-applications are independent, and the dependencies can be upgraded individually, the technology stack allows inconsistencies, and there is more room for technical iterations

• Front-end capabilities can serve the output

• Flexible architecture, new business can grow and expand freely without increasing the cognitive burden of existing business developers

shortcoming

The design of an architecture is actually a trade-off and trade-off for the whole. In addition to its value and advantages, it also brings some impacts that need to be considered.

shortcoming

Part 02 Architecture and Engineering

Grasp the results from a global perspective

What are the micro front-end solutions

1. Reverse proxy to multiple applications using HTTP server

2. Design communication and loading mechanisms on top of different frameworks

3. Build a single application by combining multiple independent applications and components

4. Using iFrames and custom messaging

5. Build Apps with Pure Web Components

6. Build with Web Components

micro frontend

Each solution has its own advantages and disadvantages. Our brother team adopts the most primitive gateway forwarding configuration similar to Nginx configuration reverse proxy, and combines the system from the perspective of the access layer, but every new addition and adjustment needs to be implemented in operation. Dimension level to configure.

And iframe nesting is the simplest and fastest solution, but the drawbacks of iframe are unavoidable.
The Web Components solution requires a lot of renovation costs.
The combined application routing distribution solution has a moderate transformation cost and meets most needs without affecting the experience of front-end terminal applications. It was a relatively advanced solution at that time.

Architecture design and selection considerations

• How to reduce the complexity of the system?

• How to ensure the maintainability of the system?

• How to ensure the scalability of the system?

• How to ensure the availability of the system?

• How to ensure the performance of the system?

After the comprehensive evaluation, we chose the combined application routing distribution scheme, but there is still an overall architectural blueprint and engineering implementation to design.

demand analysis

1. Sub-apps run/deploy independently

2. Central control loading (service discovery/service registration)

3. Sub-application common part multiplexing

4. Standardize access to sub-applications

5. Dock application routing and container management

6. Build supporting infrastructure

Design Principles

1. Support gradual migration, smooth transition

2. The splitting principle is unified, and try domain division to decouple

Application Architecture Diagram

Application Architecture Diagram

system split

system split

There are three points to note here:

• Independent deployment (service registration): uploading application resource packages (packaged files) to the Apollo configuration platform is a finishing touch

• The difference between service and npm package plug-in is that it does not need to be integrated through parent application building, independent of each other, independent of release, and more flexible/reliable

• At the same time, Apollo carries the function of the registration center, which can save this layer of the web server of the sub-application and simplify the architecture.

Timing diagram

Timing diagram

Front-end flow chart

flow chart

## Part 03 Key Technologies

What are the technical details worth mentioning in the landing

List of key technologies

We structured the description by project split, including four articles: architecture core, registration center, sub-application, and code reuse.
It includes these technical points:

1. Apollo

2. Apollo Cli

3. Version Manage

4. Sandbox

5. RouterMonitor

6. MicroPageLoader

7. Shared Menu

8. Shared Common

[Architecture Core] Message Communication

News communication

Information communication 1

Information communication 2

Information communication 3

[Architecture Core] Route Distribution

route distribution

When the path of the browser changes, the router of the base is the first to receive the change, and all routing changes are managed by the base router RouterMonitor, because it will hijack all operations that cause url changes to obtain the timing of route switching. . If it is the apps/xxx/#previous change, it will only intercept and prevent the browser from re-initiating the web page request and will not send it. If the url change before # is not involved, it will be sent to the sub-application, and the sub-application routing will take over.

[Architecture Core] Application Isolation

It is mainly divided into JavaScript execution environment isolation and CSS style isolation.

JavaScript execution environment isolation: Whenever the JavaScript of the sub-application is loaded and run, its core is actually the modification of the global object window and the change of some global events. For example, after the js of JQuery runs, it will be mounted on the window A window.$ object, for other libraries React, Vue is no exception. To this end, it is necessary to eliminate such conflicts and influences as much as possible while loading and unloading each sub-application. The most common approach is to use the sandbox mechanism SandBox.
The core of the sandbox mechanism is to allow the local JavaScript runtime to control the access and modification of external objects, that is, no matter how the internal operation is performed, the external objects will not be affected. Usually, the vm module can be used on the Node.js side, while for the browser, the with keyword and the window.Proxy object need to be combined to implement the browser-side sandbox.

CSS style isolation: When the base application and sub-applications are rendered on the same screen, some styles may contaminate each other. If you want to completely isolate CSS contamination, you can use CSS Module or namespace to give each sub-application module a specific prefix , to ensure that they will not interfere with each other, you can use the postcss plugin of webpack to add a specific prefix when packaging.
For the CSS isolation between sub-applications and sub-applications, it is very simple. Every time the application is loaded, all link and style content of the application will be marked. After the app is uninstalled, synchronize the corresponding link and style on the uninstall page.

[Architecture core] Core flow chart

We put route distribution, application isolation, application loading, and general business logic into the second-party package of the micro-frontend kernel, which is used for multiplexing of various business lines, and a unified agreement is reached internally.

kernel flow chart

[Registration Center]Apollo

In fact, most companies do not have the concept of a so-called registration center when they implement the micro-front-end solution. Why does our micro front end also have the concept and actual existence of the registry? The thinking point of selection also mainly comes from our back-end microservice architecture.

Registration Center

Why did you choose to introduce a registry to increase the complexity of the overall architecture?

Two reasons:

1. Although there is no need for communication between our sub-applications, there is also a case where the base application needs resource information of all sub-applications to maintain the mapping of the resource addresses of the sub-applications corresponding to the routes. When most companies land, they hard-code the address information of the sub-application into the base. In this way, when the application is added, deleted, or modified, the base application needs to be redeployed, which goes against our original intention of decoupling. The registry strips this mapping file from the base, allowing the architecture to have better decoupling and flexibility.

2. It should be known that the product entry of our sub-application is the hashed JS file uploaded to the CDN, and at the same time, it is necessary to publish the base application to avoid the release of the sub-application. There are two solutions. One is to add a web server of the sub-application, which can get the latest static resource files through a fixed HTTP service address. One is to increase the registration center, and the sub-application release is to push the new JS address to the registration center, and the structure of the sub-application can be thinner.

If we need a registration center, we also have two options. One is to develop a micro-front end that serves our own. Although it can be more suitable and focused, as a registration center, the low-level requirements of high-availability technology are downgraded by circuit breakers. Such mechanisms are essential, and these research and development are difficult and costly. Another is to directly apply mature open source projects that provide registry capabilities or rely on the company's existing technical facilities components.

In the end, we determined that the Apollo project, which uses the company's in-house technical infrastructure, has two advantages.

1. The project itself is open source and has a high degree of maturity. It has done a good job in functional aspects such as multi-environment, immediacy, version management, grayscale release, permission management, open API, support terminal, and simple deployment. It is a reliable high-availability project. configuration center.

2. The company has made privatization customization and deployment internally, which is more suitable for business, and is stable and used in Java and Node scenarios, with maintenance personnel on duty.

apollo-basic

Packaging and building experience for sub-apps

1. Positioning: After a sub-application is built, it is a static resource with a hash, waiting to be loaded by the base.

2. How to do it:

   1. Package a single entry static resource while exposing global methods to the base

   2. Generate entry app.js with hash for each build

   3. Get the packaged output to generate the upload configuration

   4. Upload to apollo based on environment parameters

3. How was the experience

   Very lightweight, no need to publish, just build

How does the sub-application push the packaged cdn address to Apollo

apollo page

1. Get the JSON of the packaged product, get the Hash of the entry file, and the basic information of the current project.

2. Generate content based on the above configuration, and then call the API open on the Apollo platform to upload to Apollo.

How to carry out multi-environment publishing and service chain collaboration

Micro application release

1. The environment is mainly divided into testing, pre-release, and production.

2. After the packaging is complete, specify the environment according to the micro-frontend construction platform.

3. When pushing the configuration, just specify the environment cluster corresponding to Apollo.

4. When the base application is running, it interacts with Apollo according to the environment and corresponds to the registry information of the environment cluster.

[Code reuse] How to reuse common libraries between sub-applications

1. Add shared as a remote warehouse

git remote add shared http://gitlab.xxx-inc.com/xxx/xxx-pc-shared.git

2. Add shared to the report project

git subtree add --prefix=src/shared shared master

3. Pull the shared code

git subtree pull --prefix=src/shared shared master

4. Submit local changes to shared

git subtree push --prefix=src/shared shared hotfix/xxx

Note: If it is a newly created sub-application 1-2-3-4; if it is to modify a sub-reference 1-3-4

[Code reuse] What to pay attention to when using shared

1. Modified the shared components, need to push the changes to the shared warehouse

2. If a component in a shared is frequently updated by a sub-application, consider removing the component from the shared and internalizing it into the sub-application

[Sub-application] How to access the sub-application

First, we need to understand our positioning of the sub-application:

After a sub-application is built, it is a static resource with a hash, waiting to be loaded by the base, and then rendering the view in the center, while having its own sub-route

The first step is to create a new warehouse based on our template and place the code of the corresponding sub-application

Sub-application directory structure

The second step is to access shared and modify a series of configuration files

The third step is to carry out the forwarding configuration required for development

The fourth part, run, and try to package and deploy

[Sub-application] Can a sub-application be modulated independently? How to apply joint debugging on the base?

1. Open base, ports and resources are mapped to local reprogramming

2. Zan-proxy

3. Local Nginx forwarding

[Sub-application] Sub-application development experience

development experience

Part 04 Project Implementation

The tortuous road that a problem has taken from its appearance to its solution

1. The mentality before the project is established

1. After reading the concept of micro front-end, I feel bells and whistles, playing with nouns, and forcibly creating new concepts.

2. Have a general perception of the current problems of the project (is a problem)

3. Starting from the business, using the existing knowledge background to think about the solution (almost no solution)

4. Recalling the concepts and scenarios of the micro front-end architecture, I feel that the two are compatible (if life is just like the first time)

5. Referring to the industry's solution confirmation, I decided to use the micro front-end to take off the burden of expansion (it turned out to be dismantled)

6. First, optimize the front-end architecture of the project, and output the architecture diagram (the project as a whole explores the path)

7. Next, sort out the dependencies of each business module and see what are there (sub-application analysis)

8. A large number of chats, understandings, and discussions with different people to obtain information that supports technology selection (external experts)

9. Determine the basic model of the micro front-end architecture in the US industry (basic architecture)

10. Carry out outline technical design (materialization)

11. Explicit iteration range

12. technical review

13. gang up / division of labor

14. kickoff

15. But the story is just beginning...

2. Refer to the micro front-end information

Micro frontend data

3. Carry out PC architecture optimization plan

PC Architecture Optimization Plan 1

PC Architecture Optimization Plan 2

PC Architecture Diagram

4. Risk

foreknowledge

1. Insufficient developer commitment

2. Technical Uncertainty Comes More Duration Risks

3. The technical realization of the details needs to be polished and takes more time than expected

4. Some functions are difficult to achieve

Accident

1. Inaccurate understanding of project architecture

2. Task splitting and boundary understanding are not in place

3. Insufficient investment of testers

4. Collaborative friction

5. Iterative project approval

kickoff

6. Progress

1. PC micro front-end base application has been launched

2. Splitting PC data into sub-applications has been launched

3. Coordinated the front-end of the middle and Taiwan to extract the core of Meiye Micro front-end

4. Visualization of common tool methods and enumerations

5. With the Apollo platform, a registration center for front-end application resources is formed

6. Sub-application access document output

7. Optimization of several front-end technology systems

7. Follow-up plans

afterplan

About this article

Author: Border Town to this Moruo

https://segmentfault.com/a/1190000040106401