A common architectural model for microservices 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 the API gateway design?

Version 1.0

Direct service penetration to the extranet. API layer is just a shell, add authentication, middleware. The return value is determined by the service.

  • Direct client-to-microservice communication, strong coupling. I don’t dare to refactor, and the client collapses when I change the structure.
  • Multiple requests are required, and the client aggregates the data, resulting in huge workload and high latency.
    • If a page is composed of multiple services, such as products, coupons, related recommendations, reviews. The client requests multiple interfaces, with different naming conventions.
    • Some interfaces succeed, and some interfaces fail. The client needs to perform degradation by itself.
  • Protocol is not conducive to unification. Different departments have different protocols, which require client compatibility.
  • End-oriented API adaptation, coupled to internal services.
    • Each service needs adaptation code for a different device.
  • Multi-terminal compatibility logic complex, each service needs to deal with.
  • Unified logic cannot converge, such as security authentication and traffic limiting.

This leads to client, server are tired to death, who do not please.

Version 2.0

Architecture is layer upon layer.

Backend for Forntend added a BFF layer for adaptation.

Provide an interface for the page, such as the product page, only one interface, and then the BFF layer to call multiple services, here do degrade, such as coupon service does not return is not displayed.

The client communicates only with the BFF layer, which handles adaptation, protocol, compatibility, and customization. The client feels good.

The server only provides the basic data, does not care about the business logic, does not care about adaptation, what interface structure is returned. The server is also great.

BFF layer only does data clipping, compatibility and other logic, light is not easy? It’s easy, too.

Question:

  • BFF single order. That is, all the traffic will go to this layer, if there is a flood or a bug in the code, the whole shutdown.

Version 3.0

Split the BFF according to the business, such as one view item, one order page. Such a hang does not affect the overall situation.

The problem

  • A lot of cross-sectional logic, such as security authentication, log monitoring, current-limiting circuit breakers, etc. Over time, the code gets more complex and the technical debt piles up.

Have you found:

Long divided, long united, long divided. Separate there can not be unified, merged will be a single point of failure.

Version 4.0

The common logic is made into the API gateway layer, and the BFF layer focuses on business logic.

The API layer uses highly available software such as Nginx, which basically does not hang and can be restarted. Logic such as flow limiting and load is implemented in modules to facilitate deployment. This layer is completely unrelated to business.

conclusion

When the coupling is too high, a layer is added as a buffer. When the merge has a single point, it separates. When the separation cannot be unified, it is merged.

Try to get special people to do special things. Reduce coupling of business to technology.

Related reading:

  • I heard you don’t know Conway’s Law?
  • [Microservice Theory] Practical application of CQRS
  • 【 Microservice Theory 】 How to divide microservices
  • How can a small company launch micro-services
  • [Micro-service landing] Communication mode between services: introduction to gRPC
  • API + BFF no longer worries about compatibility and adaptation
  • [Microservice Theory] Overview of microservices