12.1 Principles of Micro Service
We discussed in Chapter 2, the micro-service principle what role to play. They are mainly describes what to do, and why the question should do so. These principles can help us to make all kinds of decisions when building systems. You should absolutely define their principles, but some of the key principles of micro-services, summarized in Figure 12-1, I think it is worth Yang said here. These principles will help us create a series of small services may well be the work of self-government. So far, all the contents of the micro-services we have at least mentioned once in the book, so nothing new chapter, but a refining their core essence is also valuable. Two:;
You can choose all using these principles, or customized using something meaningful in their part of the organization. Note, however, the value of a combination of these principles: the value is greater than the overall use of part of the sum to use. So, if you decide to give up one of principle, make sure you understand their loss brings.
For each principle, I have to try in this book are some practices that support them. As the saying goes: All roads lead to Rome. You may use their own ways to achieve these principles, but in practice listed below can bring you a good start.
Figure 12-1: Principles of Micro Service
12.1.1 around the concept of modeling business
Experience has shown that the interface bounding around the business context definition, is more stable than the interface definition of the concept of technology around. To model for how the system works in this area, not only can help us to form a more stable interface, but also to ensure that we are better able to reflect changes in business processes. Using bounded areas may be defined context boundaries.
12.1.2 acceptance of automated culture
Micro Services introduces many complexities, in which the key part is that we have to manage a large number of services. A key way to solve this problem is to embrace automation culture. Early to spend some cost to build support micro-service tool that makes sense. Automated testing is essential, as compared to monolithic systems, to ensure that we can work a lot of service is a more complex process. Call a unified command line, in the same way to deploy the system into practice each environment is a very useful, which is the use of continuous delivery of product quality after each commit be a key part of the fast feedback.
Consider using the environment to help you clearly define the differences between different environments, while maintaining the ability to use a unified way to deploy. Consider creating custom images to speed up the deployment, and create a fully automated server immutable, it would be easier positioning of the system itself.
12.1.3 Internal hide implementation details
In order for a service independent of the other services, the ability to maximize its own evolution, hiding implementation details to be shut Zhen. Bounded context modeling can help in this regard, because it helps us focus on what model should be shared and which should be hidden. Services should also hide their databases in order to avoid falling into the database coupling, which is most common in the traditional service-oriented architecture of one type of pot together. Data Pump (data pump) pump or event data (event data pump), will integrate data across multiple services together to realize the function of the report.
In the possible, try to choose independent and technology API, which allows you the freedom to choose to use different technology stacks. Consider using REST, it will be internal and external standardized way of separating implementation details, even when using RPC, you still can use these ideas.
12.1. Let's all go to a centralized
In order to maximize the autonomy of micro-services can bring, we need to continue to look for opportunities to serve the team has delegated decision-making and control. In the beginning of this process as long as possible, try to use the resources self-service that allows people to demand the deployment of software, the development and testing as simple as possible, and avoid a separate team to do these things.
In this journey, ensure that the team keep the ownership of the service is an important step, ideally, or even allow the team to decide when to make those changes on the line. Internal use open source model, ensuring that people can change the service other teams have, but please note that, to achieve this model requires a lot of work. Let the team and organization consistent, so that Conway's law works, and help the team is building business-oriented services, so that they become experts in business areas that build. Some global guidance is necessary, try to use a shared governance model, so that each member of the team responsible for the co-evolution of technology vision systems.
Such a scheme like Enterprise Service Bus or Service Delivery System, will lead the business logic of the service center and dumb, you should avoid using them. Instead of using a synergistic orchestration or dummy middleware, Endpoint using intelligent (smart endpoint) to ensure that data and associated logic, cohesion within the service delimiting maintain services.
12.1.5 can be deployed independently
We should always strive to ensure that micro-services can be deployed independently. Even when you need to do is not compatible change, we should also provide both old and new versions, allowing consumers to slowly migrate to the new version. This can help us to accelerate the rate of release of new features. Have these micro-services team, we can have more autonomy, because they do not need to continue to do the deployment process allocation. When using integrated RPC-based, avoiding the use of that pile like javaRMI provided using code generation, tightly bound technology client / server.
By using a single service single host mode, you can deploy to reduce the side effects caused by a service, such as the impact of another completely irrelevant services. Consider using blue / green or canary deployment technology deployment, deployment and release distinguish reduce the risk of release of error. The use of consumer-driven contracts tests, capture them before destructive changes.
Remember, you can change a single service, then deploying it into a production environment without any linkage to the deployment of other services, this should be the norm, not the exception. Your consumers should decide when to update, you need to adapt to them.
12.1.6 isolation failure
Micro-service architecture can be more flexible than a monolithic structure, provided that we understand the failure modes of the system, and plan accordingly. If we do not consider the fact that the downstream call may fail, the system will suffer a catastrophic cascade failure, the system will be more vulnerable than ever before.
When a network calls, do not like to use as a local call handling remote calls, because it hides different failure modes. So be sure to use the client libraries, no long-distance calls over-abstraction.
If our hearts hold anti-fragile creed, expected faults occur anywhere in the city, which shows we are on the right track. Make sure to set your timeout to understand when and how to use the knock-on effect bulkheads and circuit breakers, to limit the failed component. If only part of the system is not normal behavior, to understand its impact on users. You know what network partition may mean sacrifice in a particular case and whether the availability or consistency was the right decision.
12.1.7 height can be observed
We can not rely on the observation of a single service instance, or the behavior of a server, to see whether the system is functioning properly. Instead, we need to look at what is happening as a whole. By injecting synthetic transactions to your system, simulate real user behavior in order to use semantic monitoring to see whether the system is functioning properly. Syndicate your logs and data, so that when you encounter a problem, you can further analyze the reasons. And when you need to reproduce the problem annoying, or just to see how your system in a production environment is interactive, you can help identify the association between your call tracking system.
12.2 When should you not use micro service
I have been asked this question many times. My first piece of advice is that the more you do not know an area bounded find the right context for the service, the harder it. As we discussed earlier, the boundaries of the service division error, could lead to collaboration between services have to change frequently, and this change is costly. So, if you do not understand a single block system in the field, then, before the division of the service, the first thing is to spend some time to understand what the system is doing and then try to identify a clear boundary module.
Developed from scratch is also very challenging. Not only because its domain may be new, but also because of the existing classification of things, things that do not exist than to classify much easier! Thus, consider again the system first constructs a monolithic, When split again stabilized.
When the micro-scale service, many of the challenges you face will become more severe. If you mainly use manual way to do things, when only one or two services, can have to deal with, if it is 5-10 services? Adhere to the old practice of monitoring, such as in this way to view the CPU and memory indicators, okay, but more collaboration among service when only a few services, you will be more painful. With the increase of more services, you will find yourself in constant touch these pain points. I hope this book suggestions that can help you anticipate some of these problems, and to understand some specific tips on how to solve these problems. As I said before, REA and Gilt before have the ability to service large-scale use of micro, it took some time to every configuration tools and practices to help micro-management services. These experiences made me even more convinced of the importance of the gradual start, it can help you understand the willingness and ability of organizational change, which will help correct micro-services.
12.3 parting words
Micro-services architecture will give you more options, you also need to make more decisions. Compared to simple single-piece system, in service in the micro-world, making decisions is a more common activity. I can guarantee that you will always be some mistakes in decision-making. Now that you know we will inevitably do something wrong, then how to do it? Ah, I would suggest you try to narrow the scope of each decision. As a result, if done wrong, it will only affect a small part of the system. Learn to embrace the concept of evolutionary architecture. In this concept, the system will expand and change after you learn something new. Do not think about the big bang rewrite and replace it over time, gradually carry out a series of changes to the system, this can keep the flexibility of the system.
Hope so far, I'll give you more than enough to share knowledge and experience to help you decide Micro service is right for you. If the micro service for you, I hope you see it as a journey, not a destination. Step by step forward. A block to split your system, and gradually learn. Get used to this: In many ways, continually changing and evolving system, this rule than I share in this book give you any knowledge to be important. Change is inevitable, so embrace it now!