Picture from pixabay.com
1 Introduction
BFF (Backend for Frontend) and Gateway are two important concepts in the microservice architecture. These two concepts are relatively new, and some developers and even architects do not understand it.
This article uses a hypothetical company case + icon to explain what BFF and gateway are and how they evolved. Hope to inspire architects to design and implement microservice architecture.
2. Service Architecture V1
Let's push the time back to roughly 2011. Suppose there is an e-commerce company CoolShop with a certain business volume. At this point in time, it has completed the deconstruction of the single-block application and the internal SOA service has been initially completed. At this time, its wireless application has not yet started. The front-end user experience layer is mainly a traditional server-side Web application. The overall service-oriented architecture V1 is shown in the following figure.
3. Service-oriented architecture V2
It's time to come to the beginning of 2012, and domestic wireless applications began to take off. CoolShop also closely followed the market trend and developed its own wireless native app. In order to be able to go online as soon as possible, the company's architect proposed the following V2 architecture to let the App directly call internal services:
This architecture has the following problems:
- Wireless apps and internal microservices are strongly coupled, and changes on one side may affect the other.
- The wireless app needs to know the details such as the address of the internal service.
- The wireless App needs to develop a lot of aggregation cutting and adaptation logic:
- Aggregation: A certain function needs to call several back-end APIs for combination at the same time. For example, if the home page needs to display classification and product details, it is necessary to call the classification API and product API at the same time.
- Clipping: Payload returned by back-end services is generally more general. App needs to be clipped according to the device type. For example, the screen of the mobile phone is small, and some unnecessary content needs to be cut off. The screen of the Pad is relatively large, and some content can be cut off.
- Adaptation: A common adaptation scenario is format conversion. For example, some background services are older and only support the old SOAP / XML format, but do not support the new JSON format. The wireless app needs to adapt to handle different data formats.
- With the increase of device types (iPhone / Android / iPad / WindowsPhone), the development of aggregate cutting and adaptation logic will cause a lot of duplication of work on the device side.
3. Service-oriented architecture V2.1
The V2 architecture has too many problems and has not been developed and implemented. To solve the above problems, the architect decided to introduce a new role ~ Mobile BFF between external devices and internal microservices.
The so-called BFF is actually the abbreviation of Backend for Frontend. The Chinese translation is the backend developed for the frontend. It is mainly developed by the frontend team (backend microservices are generally developed by the backend team). BFF can be considered as an adaptation service, which adapts the back-end microservices (mainly including logic such as aggregation and formatting and format adaptation), and exposes friendly and unified APIs to the wireless end devices to facilitate wireless devices to access the back end service.
The new V2.1 architecture is as follows:
The advantages of this architecture are:
- The wireless App and internal microservices are not coupled. By introducing the BFF layer indirectly, the two sides can be independently changed:
- If the back-end changes, through the BFF shield, the front-end equipment can be unaffected.
- If the front-end changes, through the BFF shielding, the back-end microservices can remain unchanged.
- When there are new requirements for wireless apps, the shielding of BFF can reduce the communication and coordination costs of the front-end and back-end teams. Many front-end teams can get their own needs on the BFF.
- The wireless App only needs to know the address of the Mobile BFF, and the service interface is unified, and does not need to know the address and details of the internal complex microservices.
- The aggregation, cutting and adaptation logic are implemented on Mobile BFF, and the wireless App can greatly simplify weight loss.
4. Service Architecture V3
The V2.1 architecture was relatively successful, and the implementation of the implementation supported CoolShop ’s early wireless business growth. With the further growth of business volume, the number of wireless R & D teams is also increasing, and the V2.1 architecture has gradually exposed the following problems:
- At first there was only one Mobile BFF, which was a single block, but the wireless R & D team was constantly increasing, corresponding to multiple business lines. According to Conway's law, there is a mismatch between a single wireless BFF and multiple teams. The cost of communication and coordination between the teams is high, and the delivery efficiency is low.
- Mobile BFF not only includes aggregation / cutting / adaptation of various business lines and business logic, but also introduces a lot of cross-section logic, such as security certification, log monitoring, and current limiting fuse. Over time, the code became more and more complex, the technical debt piled up more and more, the development efficiency continued to decline, and the number of defects continued to increase.
- The Mobile BFF cluster is a Single Point of Failure. Serious code defects or traffic floods may cause cluster downtime and all wireless applications are unavailable.
In order to solve the above problem, the architect decided to introduce a new role ~ API Gateway between the external device and the internal BFF after thinking. The new architecture V3 is shown in the following figure:
The new architecture V3 has the following adjustments:
- BFF is decoupled and split according to teams or business lines, and is split into several BFF microservices. Each business line can develop and deliver its own BFF microservices in parallel.
- The gateway (usually operated and maintained by an independent framework team) focuses on cross-cutting functions (Cross-Cutting Concerns), including:
- Routing, routing requests from wireless devices to a microservice BFF cluster in the back end.
- Authentication, centralized authentication and authentication for API access involving sensitive data.
- Monitoring, performance monitoring of API calls.
- Current limiting and fusing, when there is a traffic peak, or there is a delay or failure in the back-end BFF / micro service, the gateway can actively carry out current limiting and fusing, protect the back-end services, and keep the front-end user experience acceptable.
- Secure anti-climbing, collect access logs, analyze malicious behavior through the background, and block malicious requests.
- The gateway introduces another layer of indirection between the wireless device and the BFF, allowing the two sides to change independently, especially when the background BFF is being upgraded or migrated, so that the user-side applications are not affected.
In the new V3 architecture, the gateway assumes an important role. It is a weapon for decoupling, splitting, and subsequent upgrade and migration. With the cooperation of the gateway, the single block BFF realizes decoupling and splitting, and each business line team can independently develop and deliver their own microservices, which greatly improves the research and development efficiency. In addition, after the cross-sectional logic is stripped from the BFF to the gateway, BFF developers can focus more on business logic delivery and achieve architectural separation of concerns (Separation of Concerns).
5. Service Architecture V4
Business is constantly evolving, and the technical architecture also needs to be constantly adjusted to respond to changes in demand. In recent years, the technical team of CoolShop has ushered in new business and technical needs, mainly:
- Open up internal business capabilities and build the CoolShop Open API platform. With the help of third-party community developers, innovate on the CoolShop platform to further expand the application and business form of CoolShop.
- Abandon the traditional server-side Web application model, introduce the front and rear separation architecture, and the front-end adopts technologies such as H5 single page to provide users with a better experience.
In order to meet business needs, the architect has expanded and upgraded the service-oriented architecture. The new V4 new architecture is shown in the following figure:
The overall idea of V4 is similar to V3, except that it has expanded new access channels:
- Introduce BFF layer and supporting gateway for third-party open API to support third-party developers to develop applications on CoolShop Open API platform.
- Introduce the BFF layer for H5 applications and supporting gateways to support front-back separation and H5 single-page application mode.
V4 is a relatively complete modern microservice architecture, which is divided into the following from the outside to the inside: end user experience layer-> gateway layer-> BFF layer-> microservice layer. The entire architecture has clear levels and clear responsibilities. It is a flexible evolutionary architecture that can support continuous business innovation.
6 Conclusion
- In the microservices architecture, BFF (Backend for Frontend) is also called the aggregation layer or adaptation layer. It mainly undertakes an adaptation role: adapting the internal complex microservices to various user experiences (wireless / Web / H5 / Third party etc.) Friendly and unified API. Aggregate tailoring is the main responsibility of BFF.
- In the microservices architecture, the gateway focuses on cross-cutting logic, including routing, security, monitoring, and current limiting fuse. On the one hand, the gateway is a weapon for splitting and decoupling, and at the same time, developers can focus on the realization of business logic and achieve separation of concerns in architecture.
- End user experience layer-> gateway layer-> BFF layer-> microservice layer is a typical layered way of modern microservice architecture. This architecture can flexibly respond to changes in business needs and is an evolutionary architecture that supports innovation.
- Technology and business are constantly changing. Architects must constantly adjust the architecture to respond to these changes. Both BFF and gateways are products of architecture evolution.
- Bobo recently cooperated with Geek Time to launch a video course called "Microservice Architecture 160 Lectures". The third module (expected to be launched in June) will introduce the architecture and practice of Netflix's newly launched microservice gateway Zuul2. For an in-depth analysis, everyone's attention is welcome.
· END ·
