Micro service splitting


Introduction: with the increase of project functions and scale, the shortcomings of single architecture also appear, and micro service splitting can solve these problems.
Author: Xiuzhi


Microservices have become popular in recent years. The R & D personnel of many companies are considering the microservice architecture. At the same time, with the development of docker container technology, automatic operation and maintenance and other related technologies, microservices become easier to manage, which gives a good development opportunity for the microservice architecture.

On the way to doing micro services, splitting services is a hot topic. What principles should we follow to split the existing business? Is it better to split it as thin as possible? Next, let’s talk about the strategy and principles of service splitting.

What is the purpose of the split?

Before introducing how to split, we need to know what the purpose of splitting is, so that we won’t forget the original purpose in the subsequent splitting process.

The essence of splitting is to simplify complex problems. What complexity problems do we encounter in the single architecture stage? First of all, let’s recall why we chose the single architecture. When the e-commerce project was just launched, we just hope to build the project as soon as possible to facilitate the early launch of products to the market for rapid verification. At the initial stage of development, this architecture does bring great convenience to development, operation and maintenance, which is mainly reflected in:

• simple and direct development, centralized code and project management
• when troubleshooting problems, you only need to troubleshoot this application, which is more targeted
• only one project needs to be maintained to save the labor cost of maintaining the operation of the system

However, with more and more functions, the scale of the development team is becoming larger and larger, and the defects of the single architecture are slowly reflected, mainly in the following aspects.

At the technical level, the number of database connections has become the bottleneck of application server expansion, because the number of clients connected to MySQL is limited.

In addition, the monomer architecture increases the cost of R & D and inhibits the improvement of R & D efficiency. For example, the company’s vertical e-commerce system team will be divided into different groups according to business lines. When so many small teams work together to maintain a set of code and a system, problems will arise in the process of cooperation. There is little communication between different teams. If a team needs a function of sending text messages, some R & D students will think that the fastest way is not to ask other teams whether they have ready-made ones, but to write one by themselves. However, this idea is inappropriate and will lead to repeated development of functional services. Because the code is deployed together, everyone submits code to the same code base, and code conflicts cannot be avoided; At the same time, the coupling between functions is serious. Maybe you just change a small logic, but other functions are unavailable. Therefore, the overall function needs to be regressed during testing, which prolongs the delivery time. Modules depend on each other. If a member of a small team makes a mistake, it may affect the services maintained by other teams and have a great impact on the overall system stability.

Finally, the single architecture will also have a great impact on the operation and maintenance of the system. Imagine that at the beginning of the project, your code may be only a few thousand lines, and it takes only a minute to build at a time, so you can quickly and flexibly go online to change and fix problems frequently. However, when your system is expanded to hundreds of thousands or even millions of lines of code, the process of one construction includes compilation, unit testing, packaging and uploading to the formal environment, which may take more than ten minutes, and any small modification needs to build the whole project. The process of online change is very inflexible.

These problems can be solved by micro service splitting.

In order to facilitate you to better understand this, I attach a table (content source: cloud native: best microservices under cloud native architecture), which can help you understand the purpose of splitting more intuitively.

Micro service splitting

How should the split timing be decided?

At the beginning of the product, the single architecture should be given priority. Because in the face of a new field, it is difficult to understand the business clearly at the beginning. It is often after a period of time that it can gradually stabilize. If the split is too early, it will lead to unreasonable boundary split or too detailed split, which will affect productivity. Many times, it is much easier to divide services from an existing single architecture than to build microservices from the beginning. At the same time, the company’s products have not been verified by the market and may fail, so the risk of this investment will be relatively high.

In addition, in the case of limited resources, many advantages of using microservice architecture cannot be reflected, and the performance disadvantages will be more obvious. As shown in the figure below. When the business complexity reaches a certain level, the cost consumed by the microservice architecture will reflect the advantages. Not all scenarios are suitable for the adoption of the microservice architecture. The division of services should be carried out gradually and continuously evolved. At the initial stage of the product, when the business complexity is not high, the single architecture should be adopted as far as possible.
Micro service splitting

As the company’s business model has been gradually verified and its products have been recognized by the market, in order to accelerate the iterative efficiency of products and quickly occupy the market, the company began to introduce more development students. At this time, the complexity of the system will become higher and higher, there will be a contradiction between individual applications and team size, and the R & D efficiency will not increase but decrease. The intersection in the figure above shows that the business has reached a certain complexity, the single application can no longer meet the needs of business growth, and the R & D efficiency begins to decline. At this time, it is the time to consider service splitting. This point needs to be weighed by architects. The author’s company considers service only when the team size reaches 100 people.

When we know when to split, can we land directly? No, for the implementation of micro service splitting, supporting infrastructure should be prepared in advance, such as service description, registry, service framework, service monitoring, service tracking, service governance and other basic components. Each of the above components is indispensable, and the deployment of each component includes many technical thresholds, such as container technology, continuous deployment, Devops and other related concepts, As well as the reserve of talents and the change of concept, microservices are not only the upgrading of technology, but also the transformation of development mode, organizational structure and development concept.

So far, when to split microservices? The overall summary is as follows:

  1. Business scale: the business model has been verified by the market and needs to further accelerate the pace and quickly occupy the market. At this time, the business scale becomes larger and larger. It is divided according to the product life cycle (import period, growth period, maturity period and recession period). At this time, it is generally in the growth stage. If it is the import period, try to use the single architecture.
  2. Team size: usually when the team reaches 100 people.
  3. Technical reserve: Domain Driven Design, registration center, configuration center, log system, continuous delivery, monitoring system, distributed scheduled tasks, cap theory, distributed call chain, API gateway, etc.
  4. Talent reserve: Architects and corresponding development students proficient in microservice landing experience.
  5. R & D Efficiency: R & D efficiency has decreased significantly. For specific problems, please refer to the above split purpose.

What guiding principles should be adhered to when splitting?

  1. High cohesion and low coupling of internal functions of a single service
    In other words, each service only completes the tasks within its own responsibility, and the functions that are not its own responsibility are entrusted to other services.
  2. Closure principle (CCP)
    The closure principle of microservices is that when we need to change a microservice, all dependencies are in the components of the microservice, and there is no need to modify other microservices.
  3. Principle of service autonomy and interface isolation
    Try to eliminate strong dependence on other services, so as to reduce communication costs and improve service stability. Services are isolated through standard interfaces to hide internal implementation details. This enables services to be developed, tested, deployed and run independently, and continuously delivered as a service.
  4. Principle of continuous evolution
    In the early stage of service splitting, it is actually difficult for you to determine what kind of service to split into. From the perspective of microservices, the granularity of services seems to be small enough, but more services will also bring problems. The rapid growth of the number of services will lead to a sharp increase in architecture complexity, and it is difficult for development, testing, operation and maintenance to adapt quickly, resulting in a significant increase in failure rate and reduced availability. In unnecessary cases, it should be divided gradually and continuously evolved, Avoid the explosive growth of the number of services, which is equivalent to the effect of gray publishing. First take out several unimportant functions and split a service for test. If there is a fault, the impact range of the fault can be reduced.
  5. The splitting process shall try to avoid affecting the daily function iteration of the product
    In other words, we should complete the service-oriented splitting while doing the product function iteration. For example, give priority to stripping relatively independent boundary services (such as SMS), start from non core services, reduce the impact of splitting on existing businesses, and give the team an opportunity to practice and try and error. At the same time, when there is a dependency between the two services, the dependent services are preferentially split.
  6. The definition of service interface shall be extensible
    After the service is split, because the service is deployed as an independent process, the communication between services is no longer a method call within the process, but a cross process network communication. In this communication model, the definition of service interface should be extensible, otherwise unexpected errors will be caused when the service is changed. For example, the upgrade of the microservice interface changes the previous three parameters to four, which leads to a large number of errors reported by the caller after it goes online. It is recommended that the parameter type of the service interface is the encapsulated class. In this way, if you add parameters, you don’t have to change the signature of the interface, but only need to add fields in the class
  7. Avoid circular and bidirectional dependencies
    Try not to have circular dependency or two-way dependency between services, because this situation shows that our functional boundaries are not clearly defined or common functions are not sinking.
    Micro service splitting
  8. Phased consolidation
    With the gradual deepening of your understanding of the business domain, or the logic of the business itself has changed greatly, or the previous split has not been considered clearly, resulting in more and more confusion in the service boundary after the split. At this time, it is necessary to re sort out the domain boundary and constantly correct the rationality of the split.

Is the granularity of splitting the finer the better?

At present, many traditional single applications are upgraded to the micro service architecture. If the splitting granularity is too fine, it will increase the complexity of operation and maintenance, and if the granularity is too large, it will not have an effect. How to balance the splitting granularity in the transformation process?
Micro service splitting

Bow and arrow principle

Balancing split granularity can be weighed from two aspects: the complexity of business development and the number of team size. As shown in the figure above, it is like a bow and arrow. Only when the business complexity and the number of teams are large enough, the sword of service splitting granularity will fly further and exert its maximum power.

For example, for e-commerce’s goods and services, when we separate goods from large monomers, the logic of goods and services itself is not complex enough to the point that 2 ~ 3 people can’t maintain. At this time, we don’t need to continue to disassemble goods and services more carefully, but with the development of business, the business logic of goods becomes more and more complex, It may serve multiple platforms of the company at the same time. At this time, you will find that the problems faced by the commodity service itself are basically the same as those faced in the monomer architecture stage. At this stage, we need to split the commodity into finer grained services, such as inventory service, price service, category service, commodity basic information service, etc.

Although the business complexity has been met, if the company does not have enough manpower at this time (recruitment is not timely or there are many employee changes), it is best not to split the service. Splitting will lead to more problems due to insufficient manpower, such as a sharp decline in R & D efficiency (a service whose development responsibility does not match its quantity). Here is another question. How many development and maintenance are required for a micro service? Is it more rational? I can solve this problem by quoting a classic discussion of Mr. Li Yunhua in “learning architecture from scratch”.

Three Musketeer principles

Why is it more rational for three people to allocate a service? Not four, not two?
First of all, in terms of system scale, three people are responsible for developing a system, and the complexity of the system just reaches the granularity that everyone can fully understand the whole system and carry out division of labor; If two people develop a system, the complexity of the system is not enough, and the developers may feel unable to reflect their technical strength; If four or more people develop a system, the complexity of the system will not enable developers to understand the details of the system deeply.

Secondly, in terms of team management, three people can form a stable backup. Even if one person is on vacation or deployed to other systems, the remaining two people can still support; If there are two people, the remaining one is under great pressure after one is transferred; If there is one person, this is a single point. The team has no backup. In some cases, it is very dangerous. What if the person is on vacation and there is a problem with the system?

Finally, from the perspective of technology improvement, the three person technical team can not only form effective discussions, but also quickly reach an agreement; If there are two people, they may adhere to their own opinions, or they may have insufficient experience, resulting in design defects; If it is a person, because no one has technical discussion with him, it is likely to fall into the blind spot of thinking and lead to major problems; If there are four or more people, some of the participants may not seriously participate, but just complete the task.

The principle of “Three Musketeers” is mainly applied to the design and development stage of microservices. If microservices have been relatively stable after a period of development and are in the maintenance period, and there is no need for too much development, an average person can maintain one microservice or even several microservices. Of course, considering the problem of personnel backup, it is best to arrange two people to maintain each micro service, and each person can maintain multiple micro services.

To sum up, the finer the granularity is, the better. The granularity needs to comply with the bow and arrow principle and the Three Musketeers principle.

What are the split strategies?

The splitting strategy can be considered according to functional and non functional dimensions. The functional dimension is mainly to clearly divide the business boundary. The non functional dimension mainly considers six points, including scalability, reusability, high performance, high availability, security and heterogeneity. Next, let’s introduce it in detail.

Functional dimension

The functional dimension is mainly to clearly divide the business boundary. The main design method adopted can use DDD (for the theoretical knowledge of DDD, please refer to other online materials). The strategic design of DDD will establish a domain model, which can guide the splitting of micro services through the domain model. It is mainly divided into four steps:

• the first step is to find domain objects such as domain entities and value objects.
• the second step is to find out the aggregation root and establish aggregation according to the dependency between entity, value object and aggregation root.
• the third step is to define the boundary context according to factors such as business and semantic boundary.
• step 4: each bounding context can be split into a corresponding microservice, but some non functional factors should also be considered.

Taking the e-commerce scenario as an example, the clearance context divided by the transaction link is shown in the left half of the figure below. A microservice can be designed according to a clearance context, and the disassembled microservices are shown in the right part of the figure below.

Non functional dimension

When we split according to the functional dimension, it is not all right. In most scenarios, we need to add other dimensions for further splitting in order to finally solve the problems caused by the single architecture.

• scalability: distinguish between the changed and unchanged parts of the system. The unchanged parts are generally mature and common service functions, and the changed parts are generally functions that have changed a lot and meet the needs of business iteration scalability. We can split the unchanged parts as common services and separate the changed parts to meet the needs of personalized expansion. At the same time, according to the “28” principle, only about 20% of the system changes frequently, while the remaining 80% is basically unchanged or rarely changed. This split also solves the problem of too many publishing frequencies affecting the stability of mature services.

• reusability: duplicate functions often appear in different businesses or services. For example, each service has functions such as authentication, flow restriction, security and log monitoring. These functions can be separated to form an independent service, that is, the API gateway in the micro service. For example, for didi business, there are express and downwind business, both of which involve the function of order payment, so order payment can be independent and serve the upper business as a general service. As shown below:
Micro service splitting

• high performance: separate modules with high performance requirements or high performance pressure to prevent services with high performance pressure from affecting other services. Common splitting methods are related to specific performance bottlenecks, such as e-commerce rush buying. The biggest performance pressure is the queuing function of the entrance, which can be independent of the queuing function as a service. At the same time, we can also split it based on the separation of reading and writing. For example, the commodity information of e-commerce is mainly business details on the app side. There are a lot of reading operations, but the access to the business center on the write side is really small. Therefore, you can separate the reading and writing of services with large traffic or core services, and split them into two service publishing, one is responsible for reading and the other is responsible for writing. In addition, data consistency is another point that needs to be considered in splitting based on the performance dimension. For strongly consistent data, it belongs to strong coupling and should be placed in the same service as far as possible (but sometimes it needs to be split for various reasons, so it needs a response mechanism to ensure). Weak consistency can usually be split into different services.
Micro service splitting

• high availability: separate core services with high reliability requirements from non core services with low reliability requirements, and then focus on ensuring the high availability of core services. When splitting, the core services can be one or more, as long as the final number of services meets the principle of “Three Musketeers”. For example, for merchant services, you can split a core service and a non core service. The core service is accessed by the transaction service, and the non core service is accessed by the merchant center.

• security: different services may have different requirements for information security. Therefore, services requiring high security can be separated and deployed differently. For example, setting a specific DMZ area for partition deployment of services can more specifically meet the requirements of information security and reduce the requirements for throughput and concurrency of security devices such as firewalls, Reduce costs and improve efficiency.

• heterogeneity: for business scenarios that require the type of development language, their functions can be independent in different languages to implement an independent service.

The above splitting methods are not more than one, but can be arranged and combined freely according to the actual situation. At the same time, splitting is not only an adjustment in the architecture, but also means making corresponding adaptive optimization in the organizational structure to ensure that the split services are maintained by a relatively independent team.

Why merge when all services are dismantled?

Heraclitus, an ancient Greek philosopher, once said, “one cannot step into the same river twice.” with the passage of time, the state of anything will change. As like as two peas, the system is not the same at any time. The granularity of the service split now may be appropriate, but who can guarantee that this granularity will always be correct.
The reason why services should be combined after they are disassembled is to constantly adapt to the new business development stage. Let me make an analogy here to see if you are clear. Disassembly is equivalent to our development code, and combination is equivalent to refactoring code. I’m sure you know why to refactor. The same is true of microservices, which may change over time as we learn more and more about the application domain. For example, you may find that the specific decomposition is inefficient due to too much inter process communication, so you have to combine some services together.

At the same time, the mismatch between the number of personnel and services leads to an increase in maintenance costs, which is also an important reason for service consolidation. For example, the impact of the epidemic this year has led to a large number of layoffs and personnel loss in many enterprises, but the number of services has not changed, resulting in an imbalance between the number of services and personnel. A developer has to maintain the development of at least five services at the same time, resulting in a significant decline in efficiency.

If the number of microservices is too large and the resources do not match, you can consider merging multiple microservices into service packages and deploying them to one server, which can save the basic resource consumption during service running and reduce the maintenance cost. It should be noted that although the service package runs in a process, the services in the service package still need to meet the microservice definition so that they can be separated quickly when they need to be disassembled one day in the future. The schematic diagram of merging services into service packages is as follows:

Risks to be noted in the process of splitting

  1. Do not fight unprepared battles

Whether the development team has enough experience and can control the technology stack of microservices may be the first point to be considered. It is not required that the team must have perfect experience to start service splitting. It is best to have experts in this field in the team. If not, it may require sufficient technical demonstration and rehearsal in advance, at least not to fight an unprepared battle. Avoid dismantling which one is simple and which new business needs to be launched. Start with a service first. Otherwise, there may be some common distributed problems, such as insufficient server resources, difficult operation and maintenance, chaotic calls between services, call retry, timeout mechanism, distributed transactions, etc.

  1. Constant correction

We need to admit that our cognition is limited. We can only formulate a relatively appropriate splitting scheme based on the current business state and limited prediction of the future, rather than the so-called optimal scheme. Any scheme can only ensure that it provides relatively appropriate granularity and division principles at the moment. We should do it well at all times. It will become untimely at the end of the future Preparation for readjustment. Therefore, with the evolution of business, we need to re-examine whether the division of services is reasonable. If the service is disassembled too carefully, resulting in a decline in personnel efficiency and a significant increase in the probability of failure, we need to re divide the domain boundary.

  1. Be an activist, not a theorist

In terms of how to split it, don’t worry too much about whether it is appropriate. How can we know whether it is appropriate to close it without hands? If you find it really inappropriate after disassembly, just readjust it. You might say that the cost of readjustment is relatively high. But in fact, the essence of this problem is whether a complete capability system has been built for the service-oriented architecture, such as service governance platform, data migration tools, data double writing, etc. if so, the cost of readjustment will not be too high.

Original link
This article is the original content of Alibaba cloud and cannot be reproduced without permission.

Recommended Today

The real problem of Alibaba IOS algorithm can’t hang up this time

More and more IOS developers continue to enter the peak of job hopping in 2020 Three main trends of interview in 2020: IOS bottom layer, algorithm, data structure and audio and video development Occupied the main battlefield. Data structure and algorithm interview, especially figure, has become the main reason for the failure of most first-line […]