【Reprint】}Enterprises should be cautious about microservice architecture

Original address: http://blog.sina.com.cn/s/blog_493a84550102wkbe.html

I have talked about the microservice architecture in many previous articles.

The essence of the microservice architecture is the complete componentization (front end, logic layer, database) decoupling of a single business system, and at the same time, they cooperate with each other through lightweight service interfaces and protocols. This is consistent with the idea of ​​componentized architecture that we talked about a long time ago. After implementing the microservice architecture, you will see that there is no concept of traditional business systems, and some are just microservice modules or small applications.

The microservice architecture has been very popular recently. Many people will say that SOA is outdated, ESB is outdated, and some people even use microservice architecture to completely deny SOA and ESB. These are quite dangerous signals. When I wrote a series of articles on the enterprise private cloud PaaS platform in 2012 and 2013, I have proposed the idea of ​​​​the micro-service architecture of componentization of business capabilities and component services, but the actual application implementation effect is not ideal.

An enterprise's IT development and architecture capabilities, as well as the enterprise's own IT governance and control maturity, will directly affect whether the microservice architecture can be successfully implemented. It is necessary to know that the complexity of integration and subsequent operation and maintenance after the introduction of the microservice architecture will be complicated. exponential growth.

As a simple example, an enterprise has implemented 5 business systems, and there are 10 interfaces between the business systems. If all microservices are used, it is possible to design 50 microservice modules and 100 interfaces and integration points. It is conceivable that after the thorough implementation of microservices, the complexity of our early-stage architecture design, later-stage integration, and control has increased by more than 10 times.

This kind of integration is far more difficult than most people imagine. If you take a real project as an example, if you talk about business systems, there are only 3, but at the level of microservice modules, there are close to 60, and there are actually 1,000 integration interfaces involved. . We basically need to spend 2, 3 weeks or even longer to do joint debugging of any complex end-to-end business.

One of the important reasons why Internet companies are suitable for microservice architecture is that Internet companies such as e-commerce platforms have very low coupling between modules after microservices, and there will not be too many integration and coordination points. Or to put it simply, each microservice module is more to provide service capabilities to the above PC or APP, and there is little horizontal interface coordination between modules.

It is in this low-coupling situation that collaboration and integration are relatively easy. When you turn back to the inside of the enterprise, you will find that after the modularization of microservices, there are quite a lot of integration points between various modules, especially after the business system is split to the level of modules or components, many original internal integrations and dependencies All the points are exposed, and you need to manage them well. Since there are a large number of horizontal integration and coordination points, the horizontal integration between microservice modules is extremely complicated, far exceeding that of many Internet applications. This is a problem you will actually face.

The construction of enterprise information management or business system must be able to tolerate grayscale according to the development of the enterprise's own IT management and control capabilities and maturity. Just like an enterprise bidding for the construction of three business systems, the initial concern is that the three systems can operate to support the business, and the data between the three businesses can be integrated. You expect the three systems to be designed and delivered with a unified standard, framework, development language and componentized architecture, but it is actually impossible. The standards and methods of each manufacturer are different. The componentized design claimed by the manufacturer is actually internal. Modules are still strongly coupled together and cannot be split. These are real situations that need to be tolerated, that is, as long as the business system functions normally and can be integrated with the outside, I don't care much about its internal chaos.

This is the same as management sometimes. We need to grasp the goals and process, but it is impossible for the top leader of the team to manage everyone. What he is more concerned about is whether the goals assigned to each department manager can be accomplished well, and whether there is a problem with the coordination among department managers. However, the management methods and process tolerance of managers in various departments are different. When the management and governance level of the enterprise continues to mature, we will consider how to manage more refined.

Divide and conquer, to which level can a thing be decomposed? Which layer is suitable for decomposition? It is closely related to your personal ability and maturity.

The decomposition is rough at the beginning, for example, it is only decomposed to the business system level. It is easy to control at the beginning, but some chaos and disorder within the business system are tolerated. The problem then is that when the business system has fine-grained control requirements and capability expansion requirements, you will find that it is quite difficult to split the business system into loosely coupled components and achieve complete independent management. This is also the reason why microservices architectures are now being proposed within the enterprise.

The implementation of micro-service architecture due to insufficient IT maturity of enterprises brings many problems. The following article will analyze the common problems in detail. The third part talks about where is the best entry point for enterprise microservice architecture?