REVIEW : "micro-service design" is a cameo technical books, from the readability, the actual technical aspects of dry goods are very good, and even reminds me once read "in-depth understanding of computer systems" such classic "UNIX Programming Art" the feeling of a good book. Here is what I do some general reading notes, very much hope that we can read the book, tap more knowledge.

First, what is micro-services: small and autonomy is some work services.

  • Small and focus on doing one thing : to determine the boundaries of business services based on the boundary.
  • Autonomy : a micro-service is a separate entity. We are communicating over the network between the calling service, thereby enhancing the isolation between the services, avoid tight coupling. These services should be modified independently of each other, and the deployment of a service should not cause a change in the service consumer. 

    Second, the main benefits of micro-services

  • Technical heterogeneity : stacks may employ different techniques, languages, databases or the frame.
  • Elastic : A key concept is elastic engineering bulkhead. If a component is not available in the system, but does not cause cascading failures, then the rest of the system continues to function correctly.
  • Extended : a smaller multiple services, you may only need to expand services to be extended so that it can expand services to those who do not need to run in a smaller, somewhat less on the performance of the hardware.
  • Simplify deployment : micro-services architecture, the deployment of each service is independent, so that you can more quickly deploy a specific part of the code.
  • Match the organizational structure : micro-services architecture may well match the architecture and the organizational structure, to avoid excessive code base to obtain ideal team size and productivity.
  • Combination of : a combination of different particle size can be based on different service object functions for customers.

    Third, the principle of micro-services

  • Around business concept modeling
    experience has shown that the interface boundaries around the definition of the business context, is more stable than the interface technology around the definition of the concept. 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. May be used to define the boundaries of the field of context boundaries.
  • Cultural acceptance of automated
    micro-services into a lot of complexity, a key part of its summary 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.
  • Hiding the internal implementation details
    in order to make a service independent of other services, maximizing the ability of evolution alone, hiding implementation details is essential. 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, so as not to fall into a database coupled, this kind of coupling is the most common type in the traditional service-oriented architecture. Data Pump Data Pump or events to integrate data across multiple services together to realize the function of the report. 
    In the possible, try to choose a technology-independent API. This 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.
  • Let everything to the center
    in order to maximize micro-services can bring autonomy, 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 process, 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, using intelligent endpoint and associated logic to ensure data, cohesion within the service delimiting maintain services.
  • Can be deployed independently
    , we should always strive to ensure that 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. We have these micro-services team, but also to have more autonomy, because they do not need to do the deployment process of continuous allocation. When using integrated RPC-based kind of like to avoid using Java RMI provided using the generated stub code, 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 the 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.
  • Quarantine failed
    micro Services Architecture can be more flexible than a monolithic architecture, only if we understand the system failure modes, 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 have 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.
  • Highly observe
    that we can not rely on 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.

    Fourth, the proposals for micro-services

  • First, consider the first building block of a single system, stabilize and then split when
    the more you do not know an area bounded find the right context for the service, the harder it. Limit service division errors that may 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. In addition, the existing classification of things, things that do not exist than to classify much easier.
  • Evolution architecture concept
    micro-services architecture will give you more options, you also need to make more decisions. Compared to simple single-piece system, in the micro-world service, making decisions is a more common activity. You will be in some decision-making mistakes, so try to narrow the scope of each decision. Even if 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.
  • Also very important point: Micro service is not a silver bullet.

    Fifth, for the architect of view

  • Evolutionary Architect : just as Urban Planner (optimize the urban layout, making it easy to existing residents, but also consider the future of the factors), should design a rational framework, within this framework can evolve slowly correct system; to focus on the general direction, only to participate in very specific to implementation under very limited circumstances. They need to ensure that the system can not only meet current needs, but also be able to respond to future changes. And they should also ensure that developers working on the system and the user to use the system just as happy.
  • Evolutionary architect should bear a responsibility :
    • Vision : Make sure there is a full communication through technology vision at the system level, this vision should be able to help you meet the needs of customers and organizations.
    • Empathy : understand the impact of decisions you have made to bring clients and colleagues.
    • Cooperation : and as many co-workers to communicate in order to better define the vision, revision and implementation.
    • Adaptability : Make sure that when your customers need to adjust the technical and organizational vision.
    • Autonomy : find the right balance between standardization and team autonomy.
    • Governance : ensure system implementation in accordance with the requirements of technical vision.