Abstract
How do you, as a team architect/technical lead, divide microservices? This topic has been discussed in previous articles, Implementable DDD(4)- How to use DDD to divide microservices (2), and recently combined with the practice of different development teams, I have a new thinking, compared to the previous ddD-based more comprehensive implementable, also welcome to comment.
Why microservices
Microservices architectures are widely used by Internet companies and have the advantage that each service is small enough to be isolated from the other. With some infrastructure, requirements can be quickly iterated online. But what should be the granularity of each service, and what should be the relationship between services?
First, let’s discuss the goals of microservice segmentation. Microservice partitioning involves two objects, a microservice and a developer. So the goal is to organize microservices and developers in an efficient and orderly way.
How do you measure order?
- Responsibilities clear
- The interdependence is clear
An unordered microservice call, chaos hell.
So set some standards
Horizontal: According to the business process, the business process reflects the data flow, and the data flows from upstream to downstream. Upstream needs to be decoupled from downstream, and upstream cannot call downstream from service to service. Downstream yes.
Vertical: Divided into four layers from top to bottom based on technology. The upper layer can call the lower layer, and the other layers can call each other, but the lower layer cannot call the upper layer.
- The application system
For each end, such as PC, for the user, for the small two. App side. Front-end applications.
- Core areas
The core business of the whole system is closely connected with business. Support business development. 3. Infrastructure capabilities more general services abstracted from the core domain, not just serving the current business. It also serves other businesses of the company.
- Rely on the system
Some common common modules and service dependencies with other sibling departments.
This makes the call relationship clearer.
How do you measure productivity?
High performance and stability for services and high efficiency and room for technology growth for developers
A lot of work on the back end is around performance and stability, and the microservices division is also deeply affected. Therefore, service partitioning will also follow
- Based on iteration frequency
Change is the main cause of failure, so if a service is stable, we can split it into a single microservice so that existing functionality is not affected during rapid iterations of the project. You don’t need to invest too much regression testing time.
- Dependability based
Core services need to be protected. Applications with high traffic and applications with low traffic also have different stability requirements. Core services and applications with high traffic volume can be separated separately. In this way, the logic of core services is simple, dependency is reduced, and storage is independent. Stability is greatly guaranteed.
- Developer-based
Architecture activities need to care about people as well as machines. The productivity of developers greatly affects the speed and quality of business delivery. A microservice requires a unique owner and 2-3 developers (the owner also participates in the development). Owner is the first person responsible for the code quality and service stability of the entire application. 2-3 people are responsible for the development of a system, there is no single point, can complement each other in the situation of personnel flow, at the same time, they can carry out in-depth discussions on technical solutions, can deal with a certain level of complex requirements. The number of people should not exceed 4, because there are too many people. Developing different requirements in the same application may deal with conflicts between different branches every day, and testing in multiple environments is inefficient. At the same time, there are too many people and the discussion is inefficient. In addition, it is important to ensure that every mid-level and senior developer is a microservice owner, with their own piece of land, and can do some technology related development work in addition to the requirements undertaking.
Of course, efficiency and order are not always the same, and sometimes we need to make architectural trade-offs.
How to divide the
Business analysis
For example, let’s say your company does online education and you’re hired to develop the company’s customer management system (CRM). First you need to look at the WHOLE CRM business.
process
CRM is divided into customer acquisition – follow-up – conversion – contract – service according to the process. According to the field of abstraction, can be divided into pre-sale, sale, after sale.
service
According to the services, the main services are delivery services, marketing activities services, call services, customer management, schedule management, message reminder, orders, contracts, work orders, sales effect analysis.
function
Each service has more fine-grained functionality. For example, delivery services: provide multi-channel delivery, baidu, Toutiao, wechat, etc., delivery analysis. Marketing services: marketing landing page, opening season promotional activities, lucky draw, coupon activities. Customer management services: customer profile, sales opportunities, sales board. No further details are required.
personnel
At present, the business is still in the initial stage. There are 6 people in charge of the development of this area, including 3 back ends, 2 front ends and 1 test.
Services division
Based on the above considerations, the services are divided into the following six services.
Considering that only one PC workbench is needed, marketing personnel and sales personnel all use the same workbench, and the application system layer is not required. Then the core areas are divided into three services: pre-sales (marketing personnel), in-sales (customer service, sales) and after-sales (customer service, finance). Each developer is responsible for one service. At the same time, three common infrastructure services are abstracted, one for each developer.
- An internal company account system
Provides unified account management, organizational structure, and rights management capabilities.
- Service system
Common utility capabilities, such as privacy numbers, agent calls, todo, message reminders, etc. These are not in the same domain, but given the current stage, services should not be broken down too much. So they’re all in the same service.
- The data analysis
Each module needs data analysis, so a single capability is abstracted and processed uniformly.
evolution
After half a year of development, business is thriving, more and more demand. The staff is also expanding. The back-end staff was expanded to 10. The original microservices architecture is becoming less adaptable. Therefore, appropriate adjustments are needed. After analysis, the current business focus is
- pre-sale
The two core indicators are effective lead quantity and single lead cost. 2. The sale process determines whether the lead can be converted into an order. At present, the corresponding operation staff is the largest, 100 customer service staff, 300 sales staff. Improving operational staff efficiency is the focus.
- after-sales
Work order response time
Pre-sales this basic system functions have been built, the general marketing tools have been available, marketing personnel can carry out component combination, build different marketing pages, and then according to the effect of the appropriate adjustment. The service is more stable, so there are only 2 developments in this area. Mainly responsible for marketing tool development.
After sales are relatively stable, 2 development. In sale is the focus, demand iteration is also more, 6 development. Before there was only one microservice, development efficiency was relatively low. It needs to be broken up properly. Add 3 services
- Add a mobile workbench to the application system
Because sales people are often on the outside, mobile is needed, and mobile is usually an operational-like function of sales management activities. The PC side is to view analysis.
- Add an on-sale service domain to the core domain layer
The sale is divided into two services, one is the clue domain, mainly around the high seas, private sea, clue recommendation. The other is the service domain, which is oriented towards the daily activities of sales. Such as events, visits, notes, customer tags, etc.
- Add a process engine service to the base capability layer
People in various roles need to initiate approval and process choreography frequently, so a new basic capability, process engine, is built. It can serve the entire CRM business, and can be used by other businesses in the company if needed.
Refer to the article
www.woshipm.com/pd/3983693….