Shulou(Shulou.com)06/02 Report--

This article mainly explains "summary of some knowledge points in micro-service". Interested friends may wish to take a look at it. The method introduced in this paper is simple, fast and practical. Now let the editor to take you to learn "some knowledge points in micro-service summary"!

Micro-service architecture

The word "microservice" comes from an article written by Martin Fowle. Developers can click here to read the details of the article and click here to read the Chinese translation.

To put it simply, micro-service is a design style of system architecture, its main purpose is to split an independent system into several small services, these small services operate in their own independent processes, and the services communicate and cooperate with each other through HTTP-based RESTful-style API. Note that each small service that is split is built around some or some highly coupled business functions in the system, and each service maintains its own data storage, business development, automated test cases, and independent deployment mechanisms. Due to the existence of lightweight communication protocols as the basis, these micro-services can be written in different languages.

The difference between a single system and a single system

In the traditional enterprise system architecture, we usually use objects or business types to build a single project for a complex business requirement. In a project, the requirements are usually divided into three main parts: database, server-side processing, and front-end presentation. In the early stage of business development, because all the business logic is in one application, it is relatively easy and convenient to develop, test and deploy. However, with the development of the enterprise, the system will continue to add different business modules to the single project in order to meet different business needs; at the same time, with the progress of mobile devices, the front-end presentation module is not limited to the form of Web, which needs more interface modules for the back-to-front support of the system. With the increasing demand, monomer applications become more and more bloated, so the shortcomings of monomer applications are becoming more and more obvious. Because the monolithic system is deployed in a process, when we modify a small function, and then deploy it online, it is likely to affect the operation of other functions. And the usage scenarios, concurrency and types of resources consumed of each module in the single application are different, and the utilization of resources influence each other. This undoubtedly has a great impact on the evaluation of the system capacity of each business module, so it seems that although the single system can be easily developed and used at the initial stage, with the development of the system. There is no doubt that the cost of maintenance will become more and more expensive and very difficult to control.

In order to solve the problem that it is difficult to maintain a single system after it becomes bloated, the micro-service architecture is born. We can split the different functional modules in the system into a number of different services, which can be deployed and expanded independently. Because each service runs within its own process, there is a solid boundary on deployment, so that the update of each service will not affect the operation of other services. At the same time, because each service is deployed independently, the performance capacity of each service can be evaluated more accurately. at the same time, the bottleneck location of the system can be found more easily by cooperating with the cooperation process between services. and give a more accurate system-level performance capacity evaluation.

Challenges posed by microservices

Before implementing micro-services, it is important to know that the split of micro-services has given rise to many problems and challenges that do not exist in single applications:

(1) the new height of operation and maintenance. In the micro-service architecture, due to the split of the system, the number of processes that the operation and maintenance personnel need to maintain is greatly increased, which requires the operation and maintenance personnel to have a certain development ability to arrange the operation and maintenance processes and make them run automatically.

(2) consistency of the interface. Although we split the service, the business logic dependency will not be eliminated, but from the code dependency in the single application to the communication dependency between micro-services. This makes developers make a little change to the original interface, then the corresponding interaction parties also need to coordinate such changes to release to ensure the correct call of the interface. In other words, we need more perfect interface and version management at this time, or strictly follow the principle of opening and closing.

(3) the complexity of distribution. Because the split micro-services are deployed independently and run in their own processes, they can only cooperate through communication, so the problems of distributed environment are important factors to be considered in the design of micro-service architecture. such as network delay, distributed transactions, asynchronous messages and so on.

Although there are many shortcomings in the micro-service architecture, what you know has two sides, the key lies in how to choose, when you feel that the agile development and automated deployment implemented in the micro-service architecture are the issues you need to consider, then it is a good choice to choose the micro-service architecture at this time.

9 features of micro-service

Due to the influence of environment, resources, team and other factors, architects hardly have the same architecture design in the process of designing and implementing a large system architecture. This is especially true for the micro-service architecture, because the micro-service architecture is only a suggestion, not a mandatory requirement, so architects usually design according to their own understanding and actual situation, and continue to evolve and improve in the process of development. Of course, as the saying goes, there are nine characteristics of non-service architecture, which is instructive for architects to design architecture through the study of these nine characteristics.

(1) Service componentization. The so-called component refers to a unit that can be replaced and upgraded independently. In the micro-service architecture, we need to decompose the service into components. A service is an out-of-process component that collaborates through communication protocols such as HTTP, rather than coordinating work in an embedded way like traditional components. Each service is developed, tested and deployed independently, which can effectively avoid the redeployment of the whole system caused by the modification of a service.

(2) organize teams according to business. When deciding how to divide microservices, it usually means that we have to start replanning and organizing the team. In the past, we will divide the team into several teams from the technical level, such as DBA team, operation and maintenance team, back-end team, front-end team, designer team and so on. But if we still organize a team to implement micro-service architecture development in this way, it is very easy to occur when a service needs to be modified (it may be a very simple change, such as adding a field to an object, etc.). Then this requires consideration from the data storage to the design and front end, although there is little modification, or even some nodes do not need to be modified. But this is bound to lead to unnecessary cross-team communication, which needs to be avoided as much as possible in the enterprise.

In the implementation of micro-service architecture, different team segmentation methods are needed. Because each service is a wide-stack or full-stack implementation for a specific business, it is not only responsible for the persistent storage of data, but also responsible for various cross-disciplinary functions such as user interface definition. Therefore, in the face of large-scale projects, the author suggests that the split of the micro-service team should be carried out in the way of the line of business, on the one hand, it can effectively reduce the internal friction caused by the internal modification of the service; on the other hand, the boundary of the team becomes clearer.

(3) the attitude of making products. In a team that implements a micro-service architecture, each small team should be responsible for the entire life cycle of its product as a product, rather than as a project model, with the ultimate goal of completing development and interaction and handing over the results to maintainers.

Generally speaking, the development team can increase their understanding of the specific business by understanding the situation of the service in the specific production environment, so it is necessary for the developer to treat each micro-service with the attitude of making a product and continuously pay attention to the operation of the service. And continuous analysis to help users to improve business functions.

(4) Intelligent endpoints and dumb pipes. In a single application, components can interact and cooperate with each other directly through function calls. In the micro-service architecture, because the service is not in a process, the communication mode of the component sends a change. If the method call originally in the process is changed to the RPC call, this will lead to tedious communication between micro-services and make the performance of the system worse, so we need a more coarse-grained communication protocol.

In the micro-service architecture, the following two service invocation methods are generally used: (1) using HTTP's RESTful-style API or lightweight message sending protocol to trigger message delivery and service invocation. (2) by passing messages on a lightweight message bus, some middleware such as RabbitMQ that provide reliable asynchronous exchange are used.

In addition to the above two approaches, in some cases with a strong emphasis on performance, some teams use binary messaging protocols, such as protobuf. But even so, these systems may still have the characteristics of the aforementioned "smart endpoints and dumb pipes" in order to strike a balance between readability and efficiency. Of course, most Web applications or enterprise systems don't need to choose between the two, because it's good to be readable.

(5) decentralized governance. When we adopt a centralized architecture governance solution, we usually develop unified standards on the technology platform, but each technology has its own appropriate application scenarios, which is not suitable for all scenarios, so when we encounter its shortcomings, it takes a lot of effort to solve it, and it is very likely to become the bottleneck of the system in the future.

When implementing the micro-service architecture, by using a lightweight contract to define the interface, we are no longer so sensitive to the technology platform of the service itself. in this way, each component of the whole micro-service architecture system can choose different technology platforms according to its different business characteristics and use the most appropriate technology, so that there will be no embarrassing situation.

I like the sentence very much: not every problem is a nail, and not every solution is a hammer.

(6) decentralized management data. When we implement the micro-service architecture, we all want each service to manage its own database, which is actually the decentralization of data management.

In the process of decentralization, in addition to splitting the storage content in the original database into new other database instances on the same platform (such as splitting the tables originally stored in MySQL and storing them in multiple different MySQL instances), of course, we can also store some data with special structures or business characteristics in database instances with other technologies. For example, log information is stored in MongoDB or user information is stored in Redis.

Although the decentralization of data management can make data management more detailed, data storage and performance can be optimized by adopting more appropriate technologies. However, because the data is stored in different database instances, data consistency has become an urgent problem to be solved in the micro-service architecture, and it is very difficult to implement the distributed transaction itself. therefore, in the micro-service architecture, we put more emphasis on "no transaction" calls between services, while for data consistency, we only require that the data is consistent in the final processing state. If an error is found in the process, it can be dealt with through the compensation mechanism, so that the error data can achieve the ultimate consistency.

(7) Infrastructure automation. With the continuous development of cloud computing services and container technology, the work of operation and maintenance infrastructure becomes easier and easier, but when we implement the micro-service architecture, the databases and applications become smaller, but because of the split, the number has increased exponentially, which makes the operators have to spend more time to pay attention, and the operational tasks will also increase exponentially. If these problems do not attract enough attention at the beginning, then it is bound to increase the burden on the operation and maintenance personnel.

Therefore, in the micro-service architecture, a "continuous delivery" platform must be built from the very beginning to support the entire implementation process, which generally consists of two parts: automated testing and automated deployment.

(8) Fault-tolerant design. In a single application, there is generally no single component failure while other components are still running. However, in the micro-service architecture, because each service is running in an independent process, there are cases in which some services fail while other services run normally. For example, suppose that when a normally running service B invokes a failed service A, because the failed service A does not return, the thread is suspended to wait until the timeout is released. At this time, if the request that triggers service B to invoke service A comes from service C, and when service C invokes service B frequently, a large number of threads are suspended to wait because it depends on service A, resulting in service A not being able to serve properly. At this point, there will be the spread of the fault.

In view of this situation, it must be designed and considered to quickly detect the source of failure and restore services as automatically as possible in the micro-service architecture. In general, we want to implement monitoring and logging components in each service, and then provide dashboards with critical data such as service status, circuit breaker status, throughput, network latency, and so on.

(9) Evolutionary design. In fact, through the above study, we can find that to implement a perfect micro-service architecture, we need to consider a lot of things and the cost is also quite high, for some teams that do not have enough experience, it is very easy to pay more than a single architecture application.

Therefore, in many cases, the architect will build the system in an evolutionary way, that is to say, a good architecture is not designed, but evolved. In the initial stage, it is generally designed and implemented with a single architecture, on the one hand, because the initial volume of the system is not too large, the construction and maintenance costs are not high; on the other hand, the initial core business usually does not change greatly in the later stage. With the development of the system or the needs of the business, the architect will microservice some content that changes frequently or has a time effect for a period of time, and gradually split out the ever-changing modules that used to be in the single system. The stable and constant modules form a core micro-service that exists in the whole architecture.

Micro-service technology

Next, learn about the various solutions and open source frameworks shared by some excellent enterprises for various problems in different application scenarios in the micro-service architecture:

(1) Service governance: Alibaba's open source Dubbo and Dangdang's extended DubboX, NetFlix's Eureka, Apache's Consul, etc.

(2) distributed configuration management: Disconf of Baidu, Archaius of Netflix, QConf of 360, Config of Spring Cloud, Diamond of Taobao, etc.

(3) batch tasks: Elastic-Job of Dangdang, Azkaban of LinkedIn, Task of Spring Cloud, etc.

(4) Service tracking: Hydra of JD.com, Spring Cloud Sleuth and Zipkin of Twitter, etc.

Of course, the above list is only part of it, and for people with choice difficulties, the choice of multiple answers to a question is also a problem. In fact, if you look at it carefully, you can find that the above frameworks are all designed to solve some of the problems. In fact, when the problem comes, you can choose a more systematic tool. Spring Cloud is such a tool. It is a comprehensive solution framework for solving the implementation of micro-service architecture. It is not to build wheels repeatedly, but to integrate many widely practiced and proven frameworks as the basic components of implementation. Then some excellent edge components are created on this basis.

Introduction to Spring Cloud

Spring Cloud is a micro-service architecture development tool based on Spring Boot, which provides a simple development method for configuration management, service governance, circuit breaker, intelligent routing, micro-agent, control bus, global lock, decision campaign, distributed session and cluster state management involved in micro-service architecture.

Spring Cloud contains a number of subprojects, as follows:

(1) Spring Cloud Config: configuration management, which supports the use of Git to store configuration content, which can be used to externalize the storage of application configuration, and support client configuration information refresh, encryption / decryption, etc.

(2) Spring Cloud Netflix: this is the core component of Spring Cloud, which integrates multiple Netflix OSS open source suites:

Eureka: service governance component, including the implementation of service registry, service registration and service discovery mechanism; Hystrix: fault tolerant management component, which implements circuit breaker pattern, helps delay in service dependency and provides strong fault tolerance for failure; Ribbon: service invocation component of client load balancing; Feign: declarative service invocation component based on Ribbon and Hystrix Zuul: gateway component, which provides intelligent routing, access filtering and other functions; Archaius: externalized configuration component.

(3) Spring Cloud Bus: event, message bus, used to propagate state changes or events in the cluster to trigger subsequent processing, such as dynamic refresh of configuration information, etc.

(4) Spring Cloud Cluster: implementation of election algorithms and general patterns for Zookeeper, Redis, Hazelcast, Consul

(5) Spring Cloud Cloudfoundry: integration support with Pivotal Cloudfoundry; (6) Spring Cloud Consul: service discovery and configuration management tool

(7) Spring Cloud Stream: a consumer micro-service implemented through Redis, RabbitMQ or Kafka that can send and receive messages through a simple declarative model

(8) Spring Cloud AWS: components for simplifying the integration of Amazon Web Service

(9) Spring Cloud Security: security toolkit that provides a repeater for OAuth3 client requests in the Zuul proxy

(10) the distributed service tracking implementation of Spring Cloud Sleuth:Spring Cloud application can integrate Zipkin perfectly.

(11) Spring Cloud Zookeeper: service Discovery and configuration Management component based on Zookeeper

(12) the basic component of Spring Cloud Starters:Spring Cloud, which is the basic dependency module of Spring Boot-style projects

(13) Spring Cloud CLI: a Spring Boot CLI plug-in for quickly creating Spring Cloud applications in Groovy.

Of course, there are definitely not only these components, but also a lot of components waiting for us to learn.

At this point, I believe you have a deeper understanding of the "summary of some knowledge points in micro-services". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.