【Reprint】Enterprise Microservice Architecture Entry Point

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

In the previous two articles, I explained that when enterprises have not reached a certain level of IT maturity, they should be cautious about the microservice architecture, its core The reason is that the complexity of development, integration, and even later operation and maintenance management and control will increase exponentially after the architecture is microserviced. Even if the enterprise itself has the idea of ​​componentization and serviceization, it does not have the ability to completely build a microservice architecture.

Just as many enterprises do not even manage basic master data, nor build integrated R&D, production-related core systems such as PLM, MES, CIM, etc., they start talking about the same reasoning that they want to step into Industry 4.0 and intelligent manufacturing. Everything has to be considered from the simple to the complex, gradually evolving through an iterative approach. The following is a brief analysis of some feasible entry points for enterprises to implement microservice architecture.

1. The sinking construction of common technical service capabilities When an

enterprise starts planning and construction, or after a certain stage of construction, it will involve the following basic common technical requirements, such as message management, log management, file storage, and common small application components ( Forum, address book, online reading of documents), etc.

These common capabilities can be either technical services or common applets. The biggest feature is that these components have relatively little horizontal interaction, and more of them expose and integrate their capabilities upward. Therefore, it is appropriate to use the microservice architecture to build and deploy such scenarios independently. The online and integration of such modules can minimize the impact on existing horizontal businesses.

To discover such requirements, an enterprise should have a unified requirements acceptance and analysis group to analyze the requirements submitted by various business departments or business systems, extract common requirements, and then consider whether to build them uniformly through microservices.

2. Basic platform layer capabilities first

When implementing the microservice architecture, enterprises must realize that the two capabilities of 4A+ process engine need to be extracted for platformization and microservice modularization. Because these two basic capabilities are often the basis for any business microservice module to operate. It is precisely because of the platformization of these two basic capabilities that we can focus entirely on business implementation when building new microservice modules.

3. Move out of new modules

If the enterprise has implemented the procurement system and has been running for many years, then when there is a large module-level demand for the procurement system (such as the need to add bidding functions to the procurement demand), then this module You can consider moving out of the procurement system and build it independently through a micro-service architecture, and integrate it with the procurement management system after the construction is complete.

For whether a new module can be removed, the key point is to consider the coupling and integration between the module and the existing legacy business system. The less coupling, the easier it is to build separately and integrate later. From this point of view, which upstream businesses in the original business system are most suitable for moving out, for example, the construction of the bidding module only needs to transfer the information of qualified suppliers and purchasing bill of materials to the purchasing system, and does not need to return from the existing purchasing system any information.

Moving new modules out and microservices is often the solution that has the least impact on legacy systems. After the microservice architecture is gradually implemented within the enterprise and matures, consider moving more modules or components out of the existing system.

4. Modules are removed under major changes. When an

enterprise receives a new change request processing, when there is a major change in a module of the existing business system (for example, the content and scope of the change exceed 30%-50% of the module itself), here In this case, you can consider moving the change module out and transforming the microservice architecture.

It should be clear that in the case of major module changes, even if the original module is developed and processed, it will bring huge workload of module development and integration, joint coordination and implementation. It is better to deal with the evolution strategy of the enterprise microservice architecture. Two large impacts on the business become one impact. Although it increases the complexity, it actually reduces the overall workload and the difficulty of later migration.

Enterprises implementing microservice architecture should not completely overthrow the legacy system and build a new one, but should adopt a progressive implementation strategy of 3+4 iterations.