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

As a framework for micro-service governance, Spring Cloud takes almost all aspects of micro-service governance into account. Some articles about Spring Cloud have been written before, focusing on the use of components. This sharing mainly answers these two questions: what does Spring Cloud do in the architecture of micro-services? How do these functions provided by Spring Cloud facilitate the architecture of micro-services?

This is also my last article in writing the Spring Cloud trilogy. The first two articles are as follows:

Micro-service practice for small and medium-sized Internet companies-experiences and lessons

Can Spring Cloud be used in domestic small and medium-sized companies?

Let's first briefly review the development of our Internet architecture in the past:

Development history of traditional architecture single architecture

Monolithic architecture is common in small and micro enterprises. A typical representative is an application, a database, and a web container. For example, the open source software cloud collection we developed is a standard monolithic architecture.

In two cases, a single architecture may be chosen: first, in the early stage of enterprise development, in order to ensure rapid online, this scheme is relatively simple and flexible; second, traditional enterprises have higher verticality and less access pressure to the business. In this mode, the technical requirements are low, it is convenient for developers at all levels to take over, but also can meet the needs of customers.

The following is an architectural diagram of the single architecture:

In the single architecture, the technology selection is very flexible, giving priority to meet the requirements of rapid launch, but also easy to quickly follow up the market.

Vertical architecture

After the development of the single architecture for a period of time, the company's business model has been recognized, and the trading volume has gradually increased. At this time, some enterprises will split the original business in order to cope with larger traffic. For example: back-end system, front-end system, trading system and so on.

At this stage, the system is often divided into different levels, each level has corresponding responsibilities, the UI layer is responsible for interacting with users, the business logic layer is responsible for specific business functions, and the database layer is responsible for data exchange and storage with the upper layer.

The following is an architectural diagram of the vertical architecture:

At this stage, SSH (struts+spring+hibernate) is the key technology of the project, Struts is responsible for web layer logic control, Spring is responsible for business layer management Bean, Hibernate is responsible for database operation encapsulation and persistence of data.

Service-oriented architecture

If the company is further bigger, the vertical subsystems will become more and more, and the call relationship between the system and the system will increase exponentially. In this context, many companies will consider the SOA of services. SOA stands for service-oriented architecture, which divides applications into different modules according to their different responsibilities, and different modules interact directly through specific protocols and interfaces. In this way, the whole system is divided into many single component services to complete the request, when the traffic is too large, it is supported by expanding the corresponding components horizontally, and all components meet the overall business needs through interaction.

The advantage of SOA service is that it can deploy, combine and use loosely coupled coarse-grained application components distributed through the network according to the requirements. The service layer is the foundation of SOA, which can be directly called by the application, so as to effectively control the human dependence of the interaction with the software agent in the system.

Service-oriented architecture is a set of loosely coupled architecture. The split principle of services is high cohesion within services and low coupling between services.

The following is a service-oriented architecture diagram:

WebService or dubbo can be used to serve governance at this stage.

We find that from the single architecture to the service-oriented architecture, the number of applications is constantly increasing, slowly sinking becomes the basic set-up, and floating becomes the business system. From the above, we can also see that the essence of the architecture is constantly splitting and refactoring: the process of splitting the system is to divide the system into subsystems / modules / components. When splitting, we must first solve the positioning problem of each component, and then we can divide each other's boundaries to achieve a reasonable split. Integration is the organic integration of the separate components according to the final requirements. The result of the split enables developers to achieve business focus, skill focus, and agile development. the result is that the system becomes flexible and can be changed according to needs to achieve business agility.

The difference between SOA and microservice architecture SOA and microservice

In fact, the service-oriented architecture can already meet the needs of most enterprises, so why should we study micro-services? Let's talk about the difference between them first.

The micro-service architecture emphasizes that business systems need to be thoroughly componentized and serviced. A component is a product that can provide services independently.

Micro services no longer emphasize the heavy ESB enterprise service bus in the traditional SOA architecture.

Microservices emphasize that each microservice has its own independent running space, including database resources.

The micro-service architecture itself comes from the idea of the Internet, so the services released by the components emphasize the use of HTTP Rest API.

The segmentation granularity of micro-services will be smaller.

Summary: micro-service architecture is an extension of SOA architecture, which emphasizes the independence of service individuals and smaller split granularity.

Why consider Spring Cloud?

Spring Cloud comes from Spring, and its quality, stability and continuity can be guaranteed.

Spirng Cloud naturally supports Spring Boot, which makes it easier for business to land.

The development of Spring Cloud is very fast, from the beginning of 16 years of contact, the related component version is 1.x, and now the 2.x series will be released.

Spring Cloud is the most suitable framework for microservices in the field of Java.

Compared with other frameworks, Spring Cloud has the greatest support for the surrounding environment of microservices.

For small and medium-sized enterprises, the threshold for use is low.

Spring Cloud is the best solution for micro-service architecture.

Its characteristics.

The following are the core features of Spring Cloud:

Distributed / versioned configuration

Service registration and discovery

Routin

Invocation between services and services

Load balancing

Circuit breaker

Distributed message delivery

These features are accomplished by different components and play an important role in the evolution of the architecture. Let's take a look.

Micro-service architecture

The first problem solved by Spring Cloud is the decoupling between services and services. When many companies develop their business at a high speed, the service components will continue to increase accordingly. There is a complex mutual invocation relationship between service and service. Service An invokes service B, service B invokes service C and service D … With the increasing number of serviced components, the invocation relationship between services grows exponentially, as shown in the following figure in extreme cases

In this way, it is most likely to lead to a situation that affects the whole body. It often occurs because one service is updated and no other services are notified, resulting in frequent tragedies after being online. At this time, service governance should be carried out to transform the direct dependence between services into the dependence of services on the service center. Eureka, the core component of Spring Cloud, solves this kind of problem.

Eureka

Eureka is an open source Netflix product that provides service registration and discovery and provides a complete Service Registry and Service Discovery implementation. It is also one of the most important and core components in the Spring Cloud system.

In vernacular, Eureka is a service center, which registers all the services that can be provided to manage it, and other callers go to the registry when they need it, and then make calls, which avoids direct calls between services and facilitates subsequent horizontal expansion, failover, and so on. As shown below:

Of course, the suspension of such an important component as the service center will affect all services, so it is necessary to set up an Eureka cluster to maintain high availability. At least two are recommended in production. With the increasing traffic of the system, it is necessary to expand a service according to the situation. Eureka has provided load balancing function, and you only need to add corresponding server instances. So what if an instance fails during the operation of the system? Eureka content has a heartbeat detection mechanism. If an instance does not communicate within a specified period of time, it will be automatically deleted, so as to prevent an instance from dropping and affecting the service.

Therefore, the use of Eureka automatically has the functions of registry, load balancing and failover. If you want to know more about Eureka, please refer to this article: registry Eureka

Hystrix

In micro-service architecture, there are usually multiple service layer invocations, and the failure of basic services may lead to cascade failures, resulting in the unavailability of the whole system, which is called service avalanche effect. The service avalanche effect is a process in which the unavailability of the "service provider" leads to the unavailability of the "service consumer" and gradually magnifies the unavailability.

As shown in the following figure: an is the service provider, B is the service consumer of A, and C and D are the service consumers of B. The unavailability of A causes the unavailability of B, and when the unavailability is enlarged to C and D like a snowball, the avalanche effect is formed.

In this case, it is necessary for the whole service organization to have the function of fault isolation to avoid a service hanging up and affecting the overall situation. Hystrix components play this role in Spring Cloud.

Hystrix will immediately notify the caller of the failure of the invocation in the case of N consecutive calls of a service, preventing the caller from waiting and affecting the overall service. The service is checked again during the Hystrix interval and will continue to be provided if the service is restored.

To learn more about Hystrix, please refer to: fuse Hystrix

Hystrix Dashboard and Turbine

When a circuit breaker occurs, it needs a rapid response to solve the problem and avoid further spread of the fault, so the monitoring of the circuit breaker becomes very important. There are now two tools for monitoring circuit breakers: Hystrix-dashboard and Turbine

Hystrix-dashboard is a tool for real-time monitoring of Hystrix. Through Hystrix Dashboard, we can directly see the request response time, request success rate and other data of each Hystrix Command. But if you only use Hystrix Dashboard, you can only see the service information in a single application, which is obviously not enough. We need a tool that allows us to aggregate data from multiple services in the system and display it on Hystrix Dashboard. This tool is Turbine. The effect of monitoring is as follows:

If you want to know which indicators are monitored and how to monitor them, you can refer to this article: fuse monitoring Hystrix Dashboard and Turbine

Configuration center

With the increasing number of micro-services, each micro-service has its own corresponding profile. In the process of research and development, there are test environment, UAT environment and production environment, so each microservice corresponds to at least three different environment configuration files. With so many configuration files, if you need to modify the configuration information of a public service, such as cache, database, etc., it will inevitably cause confusion, so you need to introduce another component of Spring Cloud: Spring Cloud Config.

Spring Cloud Config

Spring Cloud Config is a configuration management solution for distributed systems. It includes two parts: Client and Server. Server provides the storage of the configuration file and provides the contents of the configuration file in the form of an interface. Client obtains data through the interface and initializes its own application according to this data.

In fact, the Server side services all the configuration files, and the service instance of the configuration file needs to go to Config Server to obtain the corresponding data. Organize all the configuration files together to avoid the fragmentation of the configuration files. Configuration Center git instance reference: configuration Center git example

If the configuration file is changed while the service is running, the service will not get the latest configuration information, and Refresh needs to be introduced to solve this problem. You can reload the configuration file while the service is running, as described in this article: configuration Center svn sample and refresh

When all configuration files are stored in the configuration center, the configuration center becomes a very important component. If there is a problem with the configuration center, it will lead to catastrophic consequences, so it is recommended to cluster the configuration center in production to support the high availability of the configuration center. Specific reference: configuration center service and high availability

Spring Cloud Bus

Although the above Refresh scheme can solve the problem of overloading configuration information during the operation of a single microservice, in real production, there may be more than N services that need to update the configuration. If you rely on manual Refresh each time, it will be a huge workload. At this time, Spring Cloud proposed another solution: Spring Cloud Bus.

Spring Cloud Bus connects distributed nodes through a lightweight message broker. This can be used in broadcast state changes (such as configuration changes) or other message instructions. One of the core ideas of Spring Cloud Bus is to extend Spring Boot applications through distributed initiators, and it can also be used to establish communication channels between one or more applications. Currently, the only way to do this is to use the AMQP message broker as a channel.

Spring Cloud Bus is a lightweight communication component that can also be used in other similar scenarios. With Spring Cloud Bus, when we change the configuration file and submit it to the version library, the Refresh of the corresponding instance will be automatically triggered. The specific workflow is as follows:

You can also refer to this article: configuration Center and message bus

Service gateway

In the micro-service architecture mode, the number of instances of back-end services is generally dynamic, so it is difficult for clients to find the access address information of dynamically changed service instances. Therefore, in order to simplify the front-end invocation logic in micro-service-based projects, API Gateway is usually introduced as a lightweight gateway, and related authentication logic is also implemented in API Gateway to simplify the complexity of calling each other between internal services.

The technology that supports API Gateway landing in Spring Cloud system is Zuul. Spring Cloud Zuul routing is an indispensable part of micro-service architecture, which provides edge services such as dynamic routing, monitoring, resiliency, security and so on. Zuul is a load balancer based on JVM routing and server produced by Netflix.

Its specific function is to forward, receive and forward all internal and external client calls. Zuul can be used as a unified access entry for resources, and you can also do some permission verification and other similar functions in the gateway.

For specific use, refer to this article: service Gateway zuul

Link tracking

With more and more services, the analysis of the call chain will become more and more complex, such as the call relationship between services, the call chain corresponding to a request, the consumption time between calls, and so on. In the actual use, we need to monitor the indicators of communication between services and services, these data will be the main basis for us to improve the system architecture. So distributed link tracking becomes very important, and Spring Cloud also gives a specific solution: Spring Cloud Sleuth and Zipkin.

Spring Cloud Sleuth provides link tracing for calls between services. Through Sleuth, you can clearly understand which services a service request has gone through and how long it takes for each service to process. This makes it very convenient for us to sort out the invocation relationship between microservices.

Zipkin is an open source project of Twitter that allows developers to collect monitoring data on various Twitter services and provide query interfaces.

Distributed link tracking needs to be implemented with Sleuth+Zipkin. For more information, please refer to this article: distributed Link tracking (Sleuth).

Summary

Let's take a look at how the various components of Spring Cloud work together:

From the figure above, we can see that the various components of Spring Cloud cooperate with each other to support a complete set of micro-service architecture.

Among them, Eureka is responsible for the registration and discovery of services, which connects the services very well.

Hystrix is responsible for monitoring the invocation between services and performing circuit breaker protection after successive failures.

Hystrix dashboard,Turbine is responsible for monitoring the circuit breaker of Hystrix and giving it a graphical display.

Spring Cloud Config provides a unified configuration center service

When the configuration file changes, Spring Cloud Bus is responsible for notifying each service to get the latest configuration information

All external requests and services are forwarded through Zuul, which acts as an API gateway.

Finally, we use Sleuth+Zipkin to record all the request data to facilitate our follow-up analysis.

From the beginning of its design, Spring Cloud considered the functions needed for the evolution of the architecture of most Internet companies, such as service discovery registration, configuration center, message bus, load balancing, circuit breakers, data monitoring and so on. These functions are provided in the form of plug and plug, so that in the process of system architecture evolution, we can reasonably select the required components for integration, so that the process of architecture evolution will be smoother and smoother.

Micro-service architecture is a trend. Spring Cloud provides a standardized, full-station technical solution, which may be comparable to the birth of the current Servlet specification and effectively promote the progress of server-side software system technology.

Source: talk about what Spring Cloud has done from the perspective of architectural evolution.

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.