The nine characteristics of micro-service reread notes

http://blog.didispace.com/20160917-microservices-note/

Today, I reread Martin Fowler's "MicroServices" to record the understanding of the nine features.

Serviced components

Component is a unit that can be replaced and upgraded independently. Just like the CPU, memory, graphics card, and hard disk in a PC, it is independent and can be replaced without affecting other units.

In the microservices architecture, we need to have a component decomposition of the service. Service is an out-of-process component that collaborates through communication protocols, such as HTTP, rather than traditional components that work together in an embedded manner. Services are independently developed, deployed, can effectively avoid the modification of a service resulting in the redeployment of the entire system.

To make an inappropriate analogy, if our PC component is built as a service, we only maintain the motherboard and some of the necessary peripherals, and the computing power is implemented through a set of external services, we just need to tell the PC which address we are going to get the computing power from, using the service-defined computing interface to achieve the computational requirements of our use. , thus realizing the service of CPU components. This makes our complex PC service more lightweight, and we even need to change our service address to upgrade our PC's computing power.

Organize teams by business

When we start deciding how to divide microservices, it often means that we start to re-plan and organize our teams. In the past, we tend to divide different teams on a technical level, such as DBA, OPS, backend, front-end, team, and so on. If we continue to organize teams in this way to implement the "microservices" architecture development, when there is a problem that needs to be changed, it can be a very simple change, such as: Add a field to the character description, which needs to start from the data storage into the design and front-end, although everyone's changes are very small, However, this can lead to cross-team time and budget approvals.

When implementing the MicroServices architecture, a different team segmentation approach is required. Since each micro-service is a wide stack or full stack implementation for a particular business, it is responsible for the persistent storage of data as well as for the various cross-discipline functions of the user's interface definition. Therefore, in the face of large-scale projects, the Division of Micro-service team is more recommended by line of business split, on the one hand can effectively reduce the internal changes in services generated by the friction; On the other hand, team boundaries can become clearer.

The attitude of doing "product"

In a team that implements the MicroServices architecture, each small team should be responsible for the entire life cycle of their products in the way they do their products. Instead of the project model, the final goal is to complete development and delivery and transfer the results to the maintainer.

The development team can increase their understanding of the specific business by understanding the circumstances of the service in a specific production environment, such as the special or unusual situations that occur in some business, and may not be known to the product managers, but it is easy for careful developers to discover these special potential problems or requirements through the production environment.

Therefore, we need to use "product" attitude to treat each "micro-service", continue to focus on the operation of the service, and constantly analyze to help users to improve business functions.

Smart Endpoints and dumb pipes

In the monomer application, the components are directly interacting with each other through function calls. In the "microservices" architecture, the service is not in a process, the communication pattern between components has changed, if only the original in-process method calls to RPC mode calls, will lead to cumbersome communication between microservices, making the system performance worse, so we need a more coarse-grained communication protocol.

In the MicroServices schema, these two service invocation methods are typically used:

• The first is the use of the HTTP protocol's RESTful API or the lightweight message-sending protocol to implement the triggering of information delivery and service invocation.
• Second, by passing messages on the lightweight message bus, something like RABBITMQ provides a reliable asynchronous interchange structure.

With extreme emphasis on performance, some teams use binary message-sending protocols, such as: Protobuf. Even so, these systems will still present "smart endpoints and Dumb pipes", in order to strike a balance between legibility and efficiency. Of course, most Web applications or enterprise systems do not need to make a choice between the two, to be able to gain legibility is a great victory. --martin Fowler

Go to the center of governance

When we adopt a centralized architecture governance scheme, we usually do the same standard on the technology platform, but each technology platform has its own short board, which can lead to a lot of effort to solve when it comes to the short board, and it may be that the underlying causes are not well solved.

When implementing the MicroServices architecture, by using a lightweight contract definition interface, we are less sensitive to the specific technology platform of the service itself, so that the components in our entire microservices architecture can choose different technology platforms for their different business features. Finally, there will be no overkill or the embarrassment of killing cows with nail clippers.

Not every problem is a nail, not every solution is a hammer

De-Centralized management data

When we implement a "microservices" architecture, we want to allow each service to manage its own database, which is the centrality of data management.

In the process of de-centering, in addition to splitting the storage contents of the original database into the new other database instances of the same platform (e.g., after splitting a table originally stored in MySQL and storing several different MySQL instances), It is also possible to store data in some other technology database instances (e.g., storing log information in MongoDB, storing user login information in Redis) for some special structure or business characteristics.

While the de-centering of data management can make data management more granular, data storage and performance are best achieved by adopting more appropriate technologies. However, because data is stored in different DB instances, data consistency becomes one of the most urgent issues in the microservices architecture. The implementation of the distributed transaction itself is very difficult, so in the "microservices" architecture, we emphasize the "no transaction" between the services of the call, and for data consistency, only requires the data in the final processing state is the same effect; If errors are found in the process and processed by the compensation mechanism, So that the error data can achieve the final consistency.

Infrastructure automation

With the maturing of cloud computing services and containerized technologies in recent years, it is becoming increasingly difficult to operate infrastructure. However, when we implement the "microservices" architecture, the size of the database and application is smaller, but the number of reasons for the split has multiplied. This makes operations personnel need to pay attention to the content also multiplied, and operational tasks will multiply, these problems if not properly resolved, will become the nightmare of operations personnel.

Therefore, in the microservices architecture, it is important to build a "continuous delivery" platform from the outset to support the entire implementation process, which requires two main elements, which are indispensable:

• Automated testing: Before each deployment, get the confidence to run the software as much as possible.
• Automated deployment: Free tedious repetitive operations and configuration management for multiple environments.

Fault Tolerant Design

In monomer applications, there is generally no single component failure and others are still in operation, usually a hang-hung. In the "microservices" architecture, because the service is running in a separate process, there is a situation where some services fail, and other services are working properly, for example: when the normal operation of service B calls to the failed service A, the thread hangs to wait until the service a fails, until the timeout is released. At this point, if the request to invoke service A is from service C, and service C calls service B frequently, because of its dependency on service A, a large number of threads are suspended waiting, and finally the service A is not normal service, then there will be a failure of the spread.

Therefore, in the "microservices" architecture, the rapid detection of fault sources and as far as possible automatic recovery services must be designed and considered. In general, we want to implement monitoring and logging components in each service, such as: Service status, Circuit breaker status, throughput, network latency, and other key data dashboards.

Evolutionary design

Through the above characteristics, we have been able to realize that to implement a perfect "micro-service" architecture, the need to consider the design and cost is not small, for not enough experience of the team, or even more than the single application to pay more costs.

Therefore, in many cases, architects will be in an evolutionary way to build the system, in the initial system in the form of single-system design and implementation, on the one hand, the system is not very large initial volume, construction and maintenance costs are not high. On the other hand, the initial core business usually does not change dramatically in the late stages. With the development of the system or the needs of the business, the architects will be some often change or have a certain time effect of the content of "micro-service", and gradually the original in the monomer system of the changeable modules gradually split out, and the stability of the change has become a core "microservices" exists throughout the architecture.

The nine characteristics of micro-service reread notes