1. Three dimensions of service splitting
After the three dimensions are split, the architecture diagram of the microservice is shown in the following figure:
- API GATEWAY Service Gateway:
Identity authentication, authority management, service dynamic routing, data aggregation (for example, the property details page has details, comments, and recommendations, which belong to different services, and we need to do these in the service gateway)
Service Register: Registration and discovery of registry services
Registration and discovery: If it is in a monolithic architecture, adding an instance is generally adding an instance server ip port in the front-end reverse proxy such as Nginx.
In microservices, this method is difficult to meet the multi-service architecture. On the one hand, frequent modification of the Nginx configuration file is prone to errors, causing the failure of the entire system.
On the other hand, service consumers need to record a large number of url and ip configurations. It is very cumbersome to manage these configurations, and it is difficult to sort out the dependencies between them. And to increase the investment in hardware and software.
If configured on the client side, this investment is reduced. Service registration and discovery are made possible by client-side load balancing.
-
For the database of microservices, an appropriate database can be selected according to the characteristics of each service. For example, if the amount of Order data is large, the Hbase database can be selected.You can also choose according to the technology stack you are good at.
2. Principles and steps of splitting
1.拆分的原则
The principle of evaluating the quality of the architecture: It can be measured by the cost of change. The purpose of architecture is to manage complexity, variability and uncertainty.
In this way, changes in one part of the system will not affect another part of the system during the system evolution process.
- High cohesion and low coupling, moderate service granularity
- Start with business model
- Evolutionary Split
2. Steps of splitting
- Analyze business models - weakly coupled together, high cohesion
- Determine service boundaries
1) Analyze the business model
Recommendation is to recommend real estate, so the recommendation depends on the real estate; the property rights of the real estate belong to a certain user, so the real estate depends on the user
The broker belongs to an economic institution; the broker is also a user
Comments can be for blogs or properties
Both reviews and blogs depend on users
Users, brokers, and economic institutions are closely related, so they can be put into one service, called user service.
Recommendations are currently only recommended for real estate, we can put the recommendation and real estate together, called real estate service.
When comments and blogs are put together, we call it a commenting service.
The resulting dependencies are:
Comment service depends on user service
Real estate services rely on user services and review services
User service as an underlying service does not depend on other services
2) Determine service boundaries
The shared model of the comment service and the user service is the user
The comment service needs to obtain the user's avatar, name and other information, and the user service provides an interface for the comment service to access.
The shared model of user service and real estate service is economic man
The real estate service needs to obtain some information of the economic person from the user service, including the avatar, email, contact information, etc., and does not require information such as passwords. The user service provides an interface for the real estate service to access.
Compared with the single body, the tables of each database are unchanged, but the database is divided into three