Shulou(Shulou.com)05/31 Report--

In this issue, the editor will bring you about how to divide the modules and identify the services in the micro-service architecture. The article is rich in content and analyzes and describes it from a professional point of view. I hope you can get something after reading this article.

Recently, in the exchange and discussion of micro-service architecture, in addition to talking about micro-service technology architecture, customers are often more concerned about the division granularity of your micro-service module, and have specific micro-service API interface identification and definition issues, so this article will focus on micro-service module partition and service identification in the process of micro-service architecture practice.

First of all, let's summarize the methods of identifying and defining services in cross-system interface integration, which can be summarized as follows:

1. Based on the process architecture and business architecture, starting from the cross-system interaction process, analyze the business interaction interface points and identify the key business service capabilities.

two。 Identify key data service capabilities based on data architecture and master data modeling and analysis.

3. Based on the analysis and definition of technical architecture and common platform layer technical components, the key technical service capabilities are identified by the principle of open capability.

Therefore, for cross-system integration, the idea of service identification and definition is relatively clear. What is the granularity of business system partition and definition in traditional methods? In the previous enterprise architecture analysis, I have talked about identifying the finest-grained business functional modules and functional units through cross-system interaction process analysis, and then aggregating from the bottom up, using CRUD analysis as the main method to iterate many times into business system partitions that meet the conditions of high cohesion and loose coupling. There is no precise method, but there is a guiding method under the general principle.

Division of micro-service modules

The division of micro-service modules is not new, or the division of business functional components within the traditional business system, but the key point I should pay attention to is the granularity and size of the business components themselves. Originally, when it was not completely split into independent micro-service modules, a business system could be divided into more than 20 business modules, because the database itself was not split, and the calls between business modules were internal API calls, so there was no problem. However, if the 20 business modules are completely divided into independent micro-service modules, you will find that the tight coupling or a large number of interactive integration interfaces between the modules will lead to the relative complexity of the whole system integration and interaction, which is difficult to manage in the later stage.

This is also what we used to emphasize that when a traditional large business system divides micro-service modules, it is more appropriate to divide it into 6 to 8 modules as far as possible. When your own IT maturity reaches a certain level, you can divide it in more detail. At the same time, when dividing the micro-service module, we must consider the division of the database itself, that is, the underlying database is also divided, similar to the horizontal split of the database I talked about when I was talking about private cloud PaaS.

How to dismantle it? In fact, the method is still the same, or it is necessary to analyze the processes within a single business system, then decompose them into specific business components or functions, and then aggregate according to the principle of high cohesion to ensure that the interactions between micro-service modules are as minimal as possible. At the same time, the common sinking strategies and ideas are still used for the basic data modules that we all need to use. At the same time, a valuable reference method is to analyze what is the main business process carried by the business system. Then analyze which independent stages of the business process can be divided horizontally, and then divide these independent stages into slightly different micro-service modules, and then correct them by CRUD analysis.

Identification and definition of microservice interface

Whether it is the traditional interface between cross-business systems or the interactive API interface between micro-service modules, one of the key points I have always stressed is that the interface must ensure the coarse-grained characteristics and achieve a high degree of cohesion of business rules and logic. The interface should face the core business object, domain object or business rule capability exposure, not the exposure of CRUD operations of database tables within the microservice module. If you expose database table CRUD operations as Rest API interfaces and invoke each other between microservice modules. One is the increase in coupling, and the other is that the basic requirements of high cohesion have not been achieved at all.

Based on the above basic principles, when we identify and define the micro-service interface, we still need to start from the business process, sort out the business interaction interfaces between the micro-service modules of a complete business process, and then identify these interfaces, then split or merge the interfaces, and finally form the micro-service API interface. Only in this way can the final micro-service API interface be reused.

Because we have independent the basic data management into a basic module, the ability of these basic data can be exposed as an independent data service capability interface in the way of query service based on the principle of data capability openness and exposure. The requirement is still at the domain object level rather than the database table level.

When each microservice module is developed and implemented, if it is based on the idea of domain-driven architecture design, only the domain object of the microservice module is well defined, and the capabilities of domain objects can be exposed in the way of API interface, which includes not only query class interface, but also import or data insertion class interface. Secondly, the implementation of the core business rules can be independently exposed as interface services.

In the previous micro-service architecture consultation, I have mentioned that on top of multiple micro-service modules, there may also be a micro-service capability composition layer to implement similar process services and composite service classes. If this happens, then * is also implemented by an independent micro-service module. This micro-service module itself may not correspond to a specific database, but combines the service capabilities of the underlying micro-service modules to form a new interface service capability.

Because in the design of micro-service architecture, we put more emphasis on the follow-up development and implementation of data without landing, because the data does not land, we can better identify and expose the interface with open thinking. In a nutshell, what data or business objects do you have, and what business rules do you manage? After coarse-grained aggregation, these can be identified and positioned as micro-service API interfaces.

The above is how to divide modules and identify services in the micro-service architecture shared by the editor. If you happen to have similar doubts, please refer to the above analysis to understand. If you want to know more about it, you are welcome to follow the industry information channel.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.