The last article talked about the overall architecture model.
API gateway + BFF data assembly + service layer
So how to divide the service layer?
According to what
For example, the customer department, logistics department, and financial department. But there are very few such divisions.
There is also a classification by business
Solve different business problems.
For example, the manuscript group, the video group, the comic group, the comment group, and the barrage group.
Generally, once a service is stable, it can be maintained by the people below, and the main force will continue to develop the next service.
How detailed
The benefits of fineness:
(1) Services can be deployed independently
(2) Expansion and shrinkage are convenient, which is beneficial to improve resource utilization
(3) The finer the split, the relative reduction of coupling
(4) The finer the split, the relatively fault-tolerant Will be better, one service will not affect other services
(5) better scalability
Disadvantages of detail:
(1) The finer the disassembly, the more complex the system
(2) The dependency between the systems is also more complicated
(3) The complexity of operation and maintenance
(4) The monitoring is more complicated
(5) The problem of positioning when a problem occurs is more complicated difficult
Micro granularity is also related to the separation of libraries.
my suggestion is:
Step by step
In fact, the structure really means that the long-term division must be combined, and the long-term integration must be divided.
- When you feel that there is no business coupling between the two codes, you can separate them.
- When you think that a piece of data needs to call multiple services, it must be merged.
Example:
Account service, which started as a service with only nickname, avatar, gender, etc.
VIPs, equipment systems, backpacks, etc. were added later.
So these are all broken down into services, after all, there is no coupling relationship.
Later, it was discovered that to fetch a user's data, seven or eight sub-services need to be called, which is troublesome, and code merging is uncomfortable.
How to do?
The architecture is layer by layer.
Add an account BFF layer to assemble data. If you need all the account information, just call it.
Aggregate externally and split internally.
to sum up
The architecture is slowly evolving, and the architecture and evolution architecture should be selected according to the business and actual environment.
Continue to iterate and continue to rebuild.