For microservices, the common architecture model is API gateway + service.
- The API gateway implements common entry logic such as authentication, load balancing, and middleware.
- Services implement specific business functions.
So, what are the pitfalls in API gateway design?
Version 1.0
Directly penetrate the service to the external network.
The API layer is just a shell, with authentication and middleware added. The specific return value is determined by the service.
- The client communicates directly with the microservice, with strong coupling. I didn't dare to refactor at all, and the client would collapse as soon as the structure was changed.
- Multiple requests are required, and the client aggregates data, which requires a huge workload and high latency.
- If a page is composed of multiple services, such as products, coupons, related recommendations, and reviews. The client needs to request multiple interfaces, and the naming rules are still different.
- Some interfaces succeed, and some interfaces fail, and the client needs to downgrade by itself.
- The agreement is not conducive to unification, there are differences between various departments, and the client is required to be compatible.
- API adaptation for the "end" is coupled to internal services.
- Each service must make adaptation codes for different devices.
- Multi-terminal compatibility logic is complex, and each service needs to be processed.
- Unified logic cannot converge, such as safety authentication and current limiting.
This results in the client and server being exhausted, and no one is pleased.
Version 2.0
The architecture is layer by layer.
Added a BFF layer, backend for forntend, specifically for adaptation.
Provide an interface for the page, such as a product page, just one interface, and then the BFF layer calls multiple services, and downgrades here, for example, the coupon service does not return without displaying it.
The client only communicates with the BFF layer, and all adaptations, protocols, compatibility, and customization are all done at this layer. The client feels very good.
The server only needs to provide basic data, and does not care about business logic, and does not care about adaptation and the structure of the returned interface. The server is also very cool.
The BFF layer only does data trimming, compatibility and other logic, is it easy? It's easy too.
problem:
- BFF single order. That is, all traffic will go to this layer. If there is a traffic peak or a code has a bug, the entire system will be down.
Version 3.0
Split BFF according to business, such as viewing one product and one order page. Such a link will not affect the overall situation.
problem
- Many cross-cutting logics, such as security authentication, log monitoring, current limiting fuse, etc. Over time, the code became more and more complex, and the technical debt piled up.
Did you find:
If you divide for a long time, you must unite, and if you are together, you must divide.
If they are separated, there will be areas that cannot be unified, and if they are combined, there will be a single point of failure.
Version 4.0
The general logic is implemented in the API gateway layer, and the BFF layer focuses on business logic.
The API layer uses high-availability software such as Nginx, which basically does not hang, and restarts when it hangs. The logic of current limiting and load is implemented by modules, which is convenient for deployment.
This layer has nothing to do with business at all.
to sum up
When the coupling is too high, add a layer as a buffer.
When there is a single point in the merger, separate it. When the divisions cannot be unified, they are merged.
Try to let specialized people do specialized things. Reduce the coupling of business to technology.