From the function of API Gateway, see the evolution of Web architecture

This article summarizes the evolution of Web service architecture from start-ups to large enterprises based on my own past work experience. These experiences come from practices in different companies and different levels of project complexity. These architectures come from practical experience in work, may not be complete, and there may be omissions or inaccuracies. Welcome to discuss and exchange, so that we can learn and progress together.

Monolithic architecture, a handy Swiss army knife

A new project or a start-up company, the most common Web architecture is monolithic architecture. It can still be seen in many small teams in the company. As the name suggests, in this architecture, all functions and components are packaged into a single, tightly integrated program and run in a process space. Strictly speaking, there is no API Gateway service here, all requests will be forwarded to the same Server through NGINX or Apache's reverse proxy.

Monolithic architecture has the following characteristics:

1. Tightly integrated components: In a monolithic application, all functions and components are tightly integrated. They may interact through function calls, library references, and other mechanisms.

2. Simple deployment: Since it is a monolithic application or service, deployment is usually relatively simple. Just need to start an application or service, in the early days when virtualization technology has not yet appeared, simple deployment and startup reduce the complexity of the project.

3. Scalability issues: As the application scale and complexity grow, it is easy to produce monolithic applications, and the application becomes difficult to maintain and expand. Especially when horizontal expansion is needed, we can only deploy the entire application to multiple servers, rather than deploying the bottleneck part.

4. Fault isolation: Since all functions are in one application, a component failure may cause the entire application to crash, affecting the integrity of the entire application.

5. Technology stack restrictions: In a monolithic application, usually use a technology stack or framework. If you need to introduce a new technology stack or framework, you often need to do a complete reconstruction.

6. Continuous integration/continuous deployment: As the complexity and volume of the application increase, building, testing, and deployment may become slower.

Monolithic architecture has been very popular in early Internet companies and has long dominated the mainstream. Therefore, we often hear about deploying a service to a 48C, 48G server. However, with the rise of containerization technology, this kind of monolithic application gradually disappeared in the long river of history. We now hear more about deploying a service to a 2C, 2G server, and then supporting more traffic and services through horizontal expansion.

The embryonic form of microservices, splitting monolithic applications into multiple small services

In response to the various problems encountered by monolithic applications, we have split the monolithic applications according to functions, which is usually judged by the independence of business logic or data. For example, user management, order processing, inventory management, etc. can be regarded as independent services. Next, we need to set up a service gateway, such as NGINX, to handle all requests and responses. The main responsibility of the service gateway is to forward the request to the corresponding service according to the path of the request. For example, all requests starting with /user are forwarded to the user management service, and all requests starting with /order are forwarded to the order processing service.

This method splits the original monolithic application, isolates according to different functions, reduces the complexity and maintenance cost of the application, increases the scalability and robustness of the application, and to a certain extent solves the problems brought by the previous monolithic application.

But this Web architecture also has some problems of its own.

1. Direct communication between the client and the microservice, strong coupling between the Server and the client. The subsequent iteration and upgrade of the Server are difficult, and the compatibility of old applications needs to be considered.

2. Part of an application often involves multiple services, requires multiple requests, and then aggregates data at the client level. The workload of the client increases, and the delay may increase due to the increase in the number of requests. Generally speaking, if our application wants to iterate quickly, it needs to be light in the front and heavy in the back. The front end mainly handles UI display logic, and the iteration speed is fast. If there is a lot of front-end logic, it will affect the delivery speed of the business.

3. It is not conducive to the unification of protocols. Because of the direct communication between the client and the server, the server needs to adapt to multiple ends. A function needs to provide different APIs for the client and the web end, and the complexity of API docking increases.

4. The compatibility of the client is coupled to the internal service, making the server need to handle complex compatibility logic.

5. Unified logic cannot converge, such as authentication, flow control, circuit breaking, etc., it is very difficult to handle scattered in various Servers.

BFF, the appearance of the savior

In order to solve the above problems, we follow the first principle of Internet engineering, that is, if the problem cannot be solved, add a layer on it. Therefore, we added an isolation layer in the middle:

By adding a layer of service directly facing the customer, the Server and the client are isolated. We do data aggregation and processing in this layer of service, provide APIs and data for front-end business scenarios. The underlying microservices use the same protocol for data export, only need to provide coarse-grained APIs. Facing the front end and the client, Node.js has a natural advantage, so the Node.js ecosystem has also become popular with this business architecture. This layer of service is the BFF (Backend for frontend) layer we are familiar with today.

There are many advantages after joining BFF:

1. Lightweight interaction: Each service only needs to consider the intranet interface and provide coarse-grained APIs. The protocol has been simplified.

2. Decoupling and rapid iteration: The work of data trimming and aggregation is placed in the BFF layer, and the API is customized for end users. The underlying microservices do not need to consider the end-user scenario, can iterate quickly and upgrade dynamically, only need to ensure the compatibility of the original interface and system.

3. The improvement of communication efficiency, the cooperation mode evolves into Web Server + Core Server.

BFF split, increase the robustness of the application

Using a single BFF layer as the only exit has an unavoidable problem, which is easy to cause single point failure. To solve this problem, we split BFF according to business scenarios, split into different BFFs, and are responsible by different teams, such as Order BFF, User BFF, Item BFF.

Many horizontal functional logics, such as security authentication, log monitoring, flow control, circuit breaking, etc., can be aggregated into a new gateway layer. Here we introduce a new API Gateway gateway layer, which sinks all common horizontal functions such as routing, authentication, flow control, and security.

API Gateway plays a crucial role, it realizes the decoupling and separation of a single BFF, so that each business line team can independently develop and deliver their own microservices. The common horizontal logic has been transferred from BFF to the gateway, so that BFF developers can focus more on the delivery of business logic, achieving separation of concerns (Separation of Concerns).

The actual business flow has also evolved into:

Client/Browser -> NLB -> API Gateway -> BFF -> Microservice

According to Conway's law, organizational structure will affect software architecture, and software architecture reflects organizational structure. At this stage, the engineering team is usually split into: Gateway Team, BFF Web Server Team, and Core Server Team.

Summary

There is no silver bullet in this world, the appearance and existence of each architecture has its specific advantages and disadvantages. Blindly choosing the most complex architecture is not always the best choice. According to the complexity and scenario of the business, as well as the human resources and engineering capabilities of the team, choosing the most suitable architecture is the optimal solution. As the business grows, we should gradually evolve the technical architecture and choose the architecture that is most suitable for the current situation.