Microservices Architecture

An application that is split into several small services is called a microservice architecture

Core elements of microservices

Examples of microservices architecture

We take an e-commerce loan scenario (such as JINGdong Baitiao) as an example to divide micro-services for the following description. The purchase scenario includes the following key services.

  • Account service: responsible for managing user basic information, such as name, gender, ID card, etc
  • Quota service: the quota that a user can use.
  • Payment service: responsible for completing the payment operation.
  • Billing service: generates bills to users at specified times.
  • Risk control service: Manages user operation rights through data analysis.

We initially designed the service architecture as shown below:

Comparative microservice criteria: conformance to standalone deployment; Process independence; Communication between services uses RPC, which is lightweight.

Focusing on one thing seems to fit, but we combine two practical processes:

Payment process:

Registration process:

We can see that in addition to the logic of micro-services themselves, in the specific process, some micro-services also need to consider how to connect with other services. That is to say, the original logic layer does not disappear, but is scattered to each micro-service, and the responsibility is not single!

Thus architectural evolution:

Advantages and disadvantages of microservices

Five years ago, when HE joined Tencent, he used the typical logic-Server architecture. Later, micro services became the new leading role like prairie fire. The subsequent experience of listed foreign companies, ONE of the TMD, micro services are also popular. I often think about the need for microservices.

Advantages of micro-service:

  1. Module is small and independent, convenient for newcomers to start;
  2. Only corresponding microservices are released to reduce dependency and error checking costs.
  3. Because the breakdown is relatively detailed, it is not easy to carry too much technical debt when refactoring.
  4. In the new microservices, new technologies can be used boldly, not restricted by the existing modules.

disadvantages

  1. Easy to focus only on their own acres of land, lack of overall grasp.
  2. The real difficulty of microservices lies in the division. If the division is not proper, then there is coupling of services, such as some state information, which is managed by service B, but is very needed by service A. In this case, both notification and polling are very troublesome.
  3. A complete data may need to be retrieved repeatedly from multiple services, and if hierarchical relationships exist, a single request may result in dozens of RPCS.
  4. In the background development, every other service is not trusted and needs to do error handling. At this time, if the aggregation layer successfully calls five domain services and fails in one domain, throwing errors or degrading services, it is also a problem for people to think about in detail.

experience

experience

  • For registration and other data initialization scenarios, only synchronous calls can be made. Take the above loan scenario as an example. If the account amount initialization fails, there will be problems in payment. So a step wrong must return an error to the front end. Consider rollback at this point, but rollback costs are too high and distributed transactions are a difficult and heavy scenario to resolve. The scenario where users must try again to register can be solved by relying on interface reentrant.
  • For asynchronous scenarios, try to be as asynchronous as possible, such as payment completion, bill entry, bill does not need to be real-time, then can be pushed through the message queue.
  • Don’t over-divide, the cost of dealing with more than a dozen services is much bigger than you think. The granularity can be slightly larger at the beginning and divided later.

conclusion

  1. The biggest contribution of micro services, I think in terms of human scheduling, a newcomer can quickly start a micro service without any other business background. If the team is stable, then it is recommended that the service division be a little more coarse, and the staff turnover is very strong, so it can be a little more detailed.
  2. Do not use microservices to use them, they are not silver bullets. Small company start-up stage, on the short flat, there is no need to pull these false.
  3. Microservices are easy for people to take care of themselves. And dividing microservices is also a very empirical thing. So if you’re going to use microservices, you need to have someone who specializes in microservices, who is going to be able to compartmentalize and tweak the whole thing.
  4. Microservices become so numerous between calls that it is too expensive to guarantee automatic compatibility or repair for exception scenarios that are difficult to occur. At this point, you can consider gently playing a log or some other background monitoring means, manual solution.