Our company has been implementing the micro service architecture for many years, and I have been developing it for some time. As it happens, recently found time to “micro service design” book with hand over again, they have the idea of writing this article, although the article is not a strong universal, but also as their own recent summary and thinking.
I think this is a question that many people who start microservices development have at least one
How should microservices be divided? How should MY service granularity be assessed?
Before exploring these questions, we might ask ourselves: What makes good service? Frankly, this isn’t about microservices, and we can think abstractly at a higher level: What makes good code? I think a lot of people will blurt out: high cohesion, low coupling. Yes, and these two principles are also the foundation of microservices, without which the value of microservices will not be realized. Imagine that a service provider for how many service consumers in use is without awareness (although we can through the registry, but the meaning is not big, we also don’t care), assuming that the service provider of a service to do adjustment leading to all consumers need to be jointly and severally, this is a very trouble, is also very hard to accept.
Low coupling
In a microservice architecture, it is important to design with as little information as possible about the collaborators and to modify and deploy the service independently without requiring other services to synchronize the changes.
High cohesion
Gather relevant actions in one place and irrelevant ones elsewhere. On the one hand, multiple changes can be troublesome, and on the other hand, multiple changes and multiple deployments can be relatively risky.
With these two principles in mind, we can then move on to our next question, which I mentioned above, “How should microservices be divided?”
Qualified context
One of the more important concepts in Domain-Driven Design is that —- restricts context. When I first saw this concept, I thought it was very obscure, but as I thought about it in the business, this concept became clear. Let’s break the qualified context into two words, “qualified” + “context”. Defined refers to a range or context, such as in the system of goods. Context can be understood as context. To sum up, it seems that there are different ranges of properties in different systems for a model that is defined in common. Or to put it this way, while the service provider needs to expose some data (the shared model) both internally and externally, not all data needs to be exposed for different businesses.
For an example of more clear, for example, we need to goods as a services division to go out, then the service consumers can see and used by our internal system is different, in other words, we will only to external sharing what they need, and our internal representation is not Shared, or if one day the internal adjustments, then inevitably affected service consumers. Therefore, we need to think about sharing specific models rather than internal representations to avoid high coupling. It is worth mentioning that when we divide services, we need to pay attention to what functions we are facing, rather than simply considering sharing data out, otherwise it is very easy to fall into the misunderstanding of anemia.
Particle size
When dividing designs, we sometimes fall into the trap of dividing too early. It’s not a bad thing to divide microservices in detail from the start, but it always leads to high upfront development costs. When we design, I prefer a coarse-to-thin process, however, there are two things that can happen in this process, such as the difference between nesting and complete separation
The choice between these two approaches depends more on your company’s architecture, but if they are maintained by different teams, complete separation is more appropriate, and if they are maintained by one team, nesting is more appropriate.
Welcome to pay attention to my public account, at least one in-depth original article every week:
