We know that micro-services is a concept, and no precise definition of the border, such design principles, belongs to abstract concepts. Talk in ill-defined circumstances divide is also a talk past each other, to analyze specific issues that need, so this article comes division is not absolute standard for reference purposes only.
Some say slightly difficult, the difficulty is to divide the service, although I had reservations. But the reaction from the side of the divide have some difficulties. Contradiction here is that size. If the particle size is too big, regardless of points and it seems almost; if the particle size is too small, aggregation, publishing, call chain, debugging, etc. are pit.
The following is a summary of talking about the split of previous experience, I listed three experts split position, each of the different experiences and perspectives, each biased, I am here to talk about is more sympathy and feelings, hope to inspire you.
A split pose
1. a pose:
Sina microblogging service expert Wu Chung want from the vertical and horizontal dimensions to two, simple and crude:
1.1 longitudinally split
From the business dimensions split. In accordance with standard business associate degree to decide, associate relatively close business suit split into a micro-services, and function relatively independent business suit split into a separate micro service.
1.2 Split lateral
From public and independent functional dimension split. Are there standards in accordance with the public are a number of other service calls, and resource-dependent independence is not coupled with other business.
Longitudinal reference to the business relationship with iron; functionally independent lateral together. I think if the split so simple, you have emboldened demolition, dare dismantle it? So we went over to look at comments from other experts.
2. pose two:
Ali's junior partner from a comprehensive point of view of dimensions, some dimensions and above will coincide.
2.1 Service to meet the needs of the business split
Full account of operational independence and professionalism of the team to avoid in order to define the border, which appeared in "bandits" seats and seize territory, affecting team confidence.
The dimensions and similar to the above, but stressed that the independence of their respective business and team members, for the above is a good supplement.
Maintenance cost is lower than the 2.2 split before split
Maintenance costs here include: human, material and time.
Here's an important part of the cost of most of the small teams are necessary to consider, and if the investment income is not directly proportional, or out of the leadership of the budget or market window, the advanced technology is a stumbling block, do not be obsessed with technology, so-called engineer thinking wholly unacceptable.
2.3 Adaptive optimal adjustment of just splitting architecture to be done in response to the organizational structure of
Services to ensure that after the split of a relatively independent team is responsible for maintaining.
This sentence is how to understand it? The team is divided in accordance with traditional products division, front-end, back-end horizontal partitions, the future of micro-services team might be a number of people eating pizza, products, front-end, back-end services are classified into the inside, to serve as The number of distribution centers.
The most promising results are split 2.4 improves the scalability of the system
The spun off services with different requirements scalability, respectively deployment, reduce costs and improve efficiency. Such as full-text search service.
This is above and independence to split by function somewhat similar, in fact, functional independence for scalability.
2.5 Consider frequent software releases
For example the portion of 20% for frequently changing detached, deployment and management alone 80% change infrequently. That white is split in accordance with the principle of 8/2. The advantage of this split is very obvious, you can reduce as much as possible sequelae of release, such as user experience, service interfere with each other and so on.
But there is a problem, if 20% of the service belong to different business level, how do you cope? So here is the split should have a priority in conflict with each other when the split should be a priority of the relatively high weight.
3. pose three:
Li Yunhua, a senior technical expert in his book gives a split architecture:
3.1 Based on business logic
The traffic in the system according to the terms of reference identification, the same division of responsibilities into a single service. This business-first approach in front of the two positions which have appeared, showing that the most basic, the most important division mode (no one).
3.2 based on stability
The system service module in accordance with the stability of the sort . Stable, not often modified division one; the unstable, often classified as a separate service changes. Such as logging services, monitoring services are relatively stable service can be grouped together. This is very similar to the 8 principles mentioned above, 80% of the business is stable.
At this point you will find Split service really is no absolute standard, it is the only reasonable standard.
3.3 Reliability
Similarly, system service modules sorted reliability. Grouped together for higher reliability core module, the less demanding the reliability in a non-return core modules.
This split may well avoid clever because a bad mouse droppings gruel monomer drawbacks, but do high-availability solutions can be a very good save future machine or bandwidth costs.
3.4 High Performance
Above, the system of prioritizing service module according to performance requirements. The high performance requirements as a separate service module, less demanding performance put together. Such as full-text search, query and classification of goods, spike belong to high-performance core module.
4. posture inventory:
Split over different posture is different, the same purpose!
-
Of business are invariably the first place logic.
-
Business module stability and reliability, functional independence, scalability have similar views
-
It should be emphasized that split multiple choice , rather than radio. Specific conditions, the freedom and flexibility permutations.
II. Digression
If you divide the top angle take it back down the field units, you may also encounter conflicts or disputes.
1. Business contradiction:
If we are divided in accordance with the business, according to particle size, there may be the following two:
-
The first is divided into commodity trading, users three services;
-
The second is divided into merchandise, order, payment, logistics, buyers, sellers six service.
** 3 VS 6, ** how to do this?
If your team only nine individuals, then it is reasonable to split into three, if there are 18 people, then six service is reasonable. Here the introduction of team members to help split.
Split visible posture is not radio, but a multiple choice . This time the team must consider the number of members .
When split encountered controversy, under normal circumstances we add a split condition, although not sufficient and necessary condition, but at least our answer will be closer to the truth.
In addition to business can be controversial, the other division will be controversial, such as a stand-alone service configuration in the end how many people need?
2. Three Musketeers (staffing)
The number of staffing mentioned above, why there are 9 and 18 do? (Team here mentioned configuration with reference to Li Yunhua predecessors Three Musketeers views)
Put another question is asked, why is three people assigned a service (of course, staff members are mainly back-end)?
-
Assumption is that one person, ask for leave, will not give birth to a disease. A single point will have problems, so unreasonable.
-
Assumption is that two individuals, and finally have a backup, but after a detached, leaving a pressure is still very large, unreasonable.
-
3 assumption is that individuals, as well as two in a detached. And number three is the magic number and stable, with well more with less. Especially in face of technical discussions, three people relatively comprehensive, if it is two may disagree, self prejudices and blind spots with.
3 then this is not that stable quantity of it?
Suppose you do is open the side edge aircraft engine change rewrite work, then three individuals may pre-stretched. But by the latter part of the service, you may have a enough.
3 So in my understanding should be a baseline , different time periods will fluctuate, but relatively stable.
