Talk about micro services


Microservices have suddenly become popular in recent years. I often see them in various places. I just have time to sort out my views. I began to work in 18 years. When I first came out of work, I thought that microservice was an “advanced” design style, and it was good to use it. However, looking back recently, microservice was only a solution to some problems, and it was not applicable to all systems. Choosing architecture, in my opinion, is more like shopping: finding what you need and picking out the best quality at the least cost. There is no outdated architecture, only the appropriate architecture.

Microservice architecture

Microservices is an architectural style of building a single application through multiple small service combinations. These services are built around business capabilities rather than specific technical standards. Each service can use different programming languages, different data storage technologies, and run in different processes. The service adopts lightweight communication mechanism and automatic deployment mechanism to realize communication, operation and maintenance. When the system scale is large, or the program needs to be modified, the deployment cost and the migration cost of technology upgrading will become more expensive. There is a very common idea to solve the problem, that is, divide and Conquer: divide a big problem into n small problems to solve. The popularity of microservices, on the one hand, is the infrastructure required by microservices: there are many mature solutions for registration and discovery, tracking and governance, load balancing, transmission and communication, and continuous integration deployment; On the other hand, more and more business scenarios are informationized, resulting in our system becoming larger and larger.


  • Service autonomy. Each service is an independent small application. You can choose the programming language and database used by the service according to your needs. You only need to adopt a consistent communication protocol and format for the external interface. There is a well-known theory in the myth of man and moon that the work that one person can complete in 10 days will not be completed in one day if it is added to 10 people. Service splitting also helps split teams, control the size of individual teams, and increase development efficiency.
  • Fault tolerant, reliable systems can be made up of error prone services. In the design of microservices, there is an automatic mechanism for rapid fault detection of the services it depends on, isolation in case of continuous errors, and reconnection when the services are restored.


  • Data consistency. In the case of single service, the data is generally stored in the same database, which can well ensure transactions. However, after service splitting, different services have their own databases, and a user request may need multiple databases. It is a headache to do cross database transactions.
  • How to split is reasonable? The benefit of using services to build programs is the real isolation of the “whole” and “part” of the software system at the physical level, which is extremely valuable for building a reliable large-scale software system, but on the other hand, the cost it pays is also negligible. The microservice architecture has made great concessions in terms of complexity and execution performance. In a distributed system in which multiple microservices call each other to operate normally, each node plays multiple roles of service producers and consumers, forming a complex network of call relationships. Which division method is adopted for the original system to make the calls between services less and simpler? This is a problem that needs to be considered


Microservices are more suitable for systems with complex business and large scale.Just as a single thread can complete tasks well, there is no need to use multithreading.