Some people say: use multiple independent microservices to compose a complex business system. As such, the overall complexity of the business system is not reduced. If, at the extreme, each public function is a standalone service, it adds complexity to the system. In this way, microservices only solve part of the scalability problem. There are no fundamental changes compared to SOA architecture or Monolic.


That’s not the case.


Distributed means the challenge of complexity, and from a static point of view, where the system doesn’t change much over time, adopting a microservice architecture often adds more complexity to the system as a whole than it gains.


However, there is a word called “architecture corruption”, which means that the system cannot stand still. As the business grows and the market changes, the system always needs to add new capabilities. Over time, the initially simple and efficient architecture often becomes extremely complex and bloated. Scalability, usability, and performance complications are inevitable, and it would be terrible to change a line of ancestral code for six months. This is also a manifestation of the principle of entropy increase.


With a microservice architecture, boundaries and responsibilities are clear, modules are highly cohesive and coupled, and the increase in entropy of the system can be slowed down. Moreover, after the system is broken up, it is much easier for small teams responsible for individual microservices. This is where SOA and monolithic architectures that emphasize service bus (ESB) do not.


It is true that there are many things that need to be done to make microservices architecture work properly, such as:

  • Service registration/discovery: The network address of the service instance is dynamically assigned, and the configuration of the service instance changes frequently, so it’s not fun without this.

  • Continuous deployment: The more features there are, the more time it takes to build and deploy, and even the smallest changes need to be deployed. If you deploy manually, you’ll never see the end of it.

  • Locating and fixing exceptions: When serving multiple links is complex, it can be a struggle to find the one in the crowd.

  • High availability: Services are indeed relatively independent and resources are isolated, reducing the impact of local failures on the whole, but with calls and dependencies, if you don’t make every service high available, you’re waiting for an avalanche.


But these are infrastructure-level jobs, and as long as you have a good microservices infrastructure that is minimally intrusive and supports automation as much as possible, it’s not a problem. The design of netease Cloud Micro service is to solve all the problems of the life cycle of micro service application.


Therefore, the microservice architecture not only solves part of the problem of functional expansibility, but also plays a huge role in ensuring system availability, reducing communication costs, supporting the diversity of technology choices and improving research and development efficiency.


Optimizing the complexity of business systems should be to ensure business responsiveness, business innovation, and improve IT efficiency. Many Internet companies and traditional enterprises are engaged in micro-services, of course, because micro-services have such benefits.


Related articles: JVM garbage collector (1) Java memory model and shared variable visibility