The design practice of enterprise-level micro-service architecture needs thinking from macro to micro level, which is mainly divided into business architecture, application architecture, technical architecture and development design methodology.

First, business architecture thinking

To the construction of enterprise information system must first clear system requirements, and to formulate system requirements must first clear system for enterprises to resolve what problems, which involved in object and how to participate, then consider how to use the information means to optimize productivity, this is business architecture need to solve the problem.

1. Business domain identification

The business main body, business function and business boundary of business operation are mainly clarified. Here is the understanding and assumption of business function. The understanding of the business domain requires the use of the thought of domain-driven design to design at the strategic level, clarify the responsibilities of each domain, and demarcate the boundaries of the domain.

There is no unified standard for the division of fields, which is based on the advantages and disadvantages of the actual situation of the enterprise. The main principle is high cohesion and low coupling, including the businesses that are strongly related to the business field, and stripping out the businesses in other fields. Some ambiguous business attributions need to be treated seriously and determined by analyzing the nature of business results. If too many similar businesses exist, you need to consider whether the previous business domain was correctly identified.

Business domain functional design is an ongoing process, and there should be a capability map, a long-term plan for the capabilities that the domain provides. Only in this way can it be clear how to design functional attribution when a business operation process appears.

2. Business process sorting

The representation of a business process image is the delivery of business results between multiple business operations. From the macro level of the whole business system, business results are transmitted among various business fields. The design of business processes needs to maintain the independence and reuse of business results, and the delivery mode requires standardization and universality. At the micro level of the business domain, where business results are delivered across business operations, business processes need to be designed to be simple.

3. Business model construction

This part is where the value of business architecture lies. It has a profound understanding of the role of business fields, a perspective of many business processes, a clear understanding of the essence of business operations, a grasp of business development trajectory, a formation of business construction principles, and a construction of business architecture model.

Business abstraction requires a profound understanding of the business logic behind business operations. Instead of simply realizing existing requirements, we should fully consider the versatility and variability of business models to adapt to the continuous development of future business. Changes in the details of requirements are varied, but in order to achieve the goal of the stated basis is unchanged, should start from this point of view, standing in the business problem solving perspective to establish a business model.

Second, thinking about application architecture

Application architecture needs to define what business systems are in the overall product, how they are integrated, how they are divided internally, and how they are connected.

1. Application partitioning

  • Business requirements: Application segmentation is largely derived from business architecture analysis and is the result of the business model.
  • Technical status: Performance and stability requirements need to be balanced considering actual technical support. Some application services are characterized by simple business, low response tolerance, wide audience and high stability; Some application services are characterized by complex business, high response tolerance, small audience and certain failure rate.
  • Physical environment: In a complex network environment, some services may need to interact with other services on different networks, resulting in application splitting.
  • Security requirements: Application services may have different security levels. Some are external services and some are internal apis, and their security authentication methods are different.
  • System iteration: Incompatibilities may occur due to the continuous upgrade of the system, it is more and more difficult to maintain the old version due to the change of personnel, and it is not suitable due to the innovation of technical architecture

2. Application interaction

It mainly includes two ways, one is blocking synchronization mode, strong association operation; The other is triggered asynchrony, which is weakly associative operation.

2.1 Strong association interaction

Used for necessary steps in process operations, strong consistency, mainly using remote interface calls. In this way, both the caller and the called party must respond in time, react quickly, the system coupling degree is higher, and the execution process is more complex. In the system design, the invocation of this method should be minimized, and the response time of the called party should be paid attention to when the invocation is necessary.

2.2 Weakly associative interaction

For other operations in the process that the application does not care about, the application only needs to send the message, and the application that needs to use the message needs to subscribe, mainly using message middleware. This method uses asynchronous mode, does not require timely response of subscribers, the system coupling degree is low, there is no consistency requirement by default, and the final consistency can be achieved. In the system design, try to use this method in order to improve the response speed of the whole system and stability of the structure.

2.3 Form of message transmission

Transmission of behavior identification: including the type of behavior object, the state of behavior object and the identification code of behavior object

 {"code":"XP0000000000000D6001"."notice":"PRODUCT"."noticeAction":"MODIFY"}
Copy the code

In this way, the content transmitted is simple, small in quantity and unified in format. After receiving the message, the subscriber needs to query the behavior object through the remote interface again. Here, the result can be formulated, but it adds extra call overhead and needs to maintain the communication stability of both parties

Transport of behavior objects: What is passed is the entire behavior object, and behavior identification can be configured by message routing

 {"code":"XP0000000000000D6001"."name":"XXX"."statue":"MODIFY"."id":"XXX". }Copy the code

After receiving the message, the subscriber can directly obtain the behavior object without requesting the interface again. However, the format of the behavior object is fixed and cannot be formulated. In order to meet the needs of more subscribers, the whole object often needs to be passed out, which consumes a lot of transmission. If messages pile up in the message server, it can seriously affect server performance.

The two modes have different application scenarios and can be selected as required. In general, if the content of the behavior object is small, the behavior object can be directly transmitted to avoid the second request; if the content of the behavior object is large, only the behavior identifier can be transmitted.