1. Principles of Microservices
- Modeling around business concepts, experience has shown that interfaces defined around business Bounded Contexts are more stable than interfaces defined around technical concepts.
- Embracing the culture of automation, microservices contain too much complexity, such as we have to manage a large number of services. So the best way is to spend a certain amount of time in the early stage to build tools that support microservices; there are also automated tests, deployment scripts, etc., which can help us do most of the time-consuming things.
- Hide internal implementation details, in order to make a service independent of other services, and maximize the ability to evolve independently. Bounded context modeling can help here. Services should also hide their databases to avoid falling into data coupling. Choose APIs that support common technologies where possible, which gives you the freedom to choose to use different technology stacks.
- It can be deployed independently, and the side effects caused by deployment can be reduced by adopting the single-service single-host mode. Consider using blue/green deployment or canary deployment techniques.
- To isolate failures, we have to account for possible failures in downstream services, or the system will suffer catastrophic failure. So remember the "anti-fragile ways", like setting timeouts correctly, knowing when and how to use bulkheads and circuit breakers.
2. When you should not use microservices
- The first suggestion is that the less you know about a domain, the harder it will be to find the right context for your service. As mentioned earlier, the wrong division of service boundaries may lead to frequent changes in the collaboration between services, which is very costly. So the first thing to do before partitioning services is to spend some time understanding what the system does, and then try to identify clear module boundaries. If it is a brand new business field, please consider building a single system first, and split it after it is stable.
3. Final Words
The microservice architecture brings us more choices and requires us to make more decisions. Therefore, we cannot avoid making mistakes in some decisions, so please try to influence the scope of the decision as much as possible. The idea here is to embrace the evolutionary architecture.
The microservices built by each organization are unique. Don't go after the so-called standards, it's better to use them as a reference. Our system needs to be gradually changed and evolved to adapt to our business. At any time, our business can be carried out normally and with certain efficiency, which can prove that our system is stable and effective.
Blogger's note: If readers also use Go language to develop projects and intend to embrace the microservice architecture, you are invited to pay attention to the go-kit example project go-kit-examples , which contains detailed documents and codes required for getting started with go-kit, and more Contains fully commented microservice demo projects and gateways.
-------------------------------------------------- -------------- The dividing line of saosao -------------------------------- ----------------------------------------
Blogger's Coding tribe group 588757596, come and play together!