As a microservice governance framework, Spring Cloud considers almost every aspect of microservice governance.
This post addresses these two questions:
- What does Spring Cloud do in the microservices architecture?
- How do these features provided by Spring Cloud facilitate the architecture of microservices?
Let’s start with a quick review of how our Internet architecture has evolved in the past:
History of Traditional Architecture
Monomer architecture
Single architecture is common in small and micro enterprises. A typical example is that one application, one database and one Web container can run. For example, the cloud collection of open source software developed by us is the standard single architecture.
Singleton architectures may be chosen in two situations:
- In the early stage of enterprise development, it is relatively simple and flexible to adopt this scheme in order to ensure fast online.
- Services with high verticality and low access pressure in traditional enterprises. In this mode, the technical requirements are low, convenient for developers at all levels to take over, but also to meet customer needs.
Here is an architecture diagram of a single architecture:
In the single architecture, the technology selection is very flexible, priority to meet the requirements of quick online, but also easy to quickly follow up the market.
Vertical architecture
After the development of the single structure for a period of time, the business model of the company has been recognized, and the transaction volume has gradually increased. At this time, some enterprises will split the original business, such as background system, front-end system and transaction system, in order to cope with greater traffic.
In this stage, the system is often divided into different levels, each level has corresponding responsibilities, UI layer is responsible for interaction with users, business logic layer is responsible for specific business functions, database layer is responsible for data exchange and storage with the upper layer.
The following is an architecture diagram of the vertical architecture:
SSM (Spring + SpringMVC + MyBatis) is the key technology of the project at this stage. SpringMVC is responsible for the logic control of the Web layer, Spring is responsible for the management Bean of the business layer, and MyBatis is responsible for the encapsulation of database operations and persistent data.
Service-oriented architecture
As companies get bigger, there will be more and more vertical subsystems, and the call relationships between systems will increase exponentially.
In this context, many companies are considering soa-based services. Service-oriented Architecture (SOA) represents a service-oriented Architecture that divides applications into different modules based on different responsibilities. Different modules interact with each other through specific protocols and interfaces.
In this way, the whole system is divided into many individual component services to complete the request. When the traffic is too large, the corresponding components are supported by horizontal expansion. All the components interact to meet the overall business requirements.
The advantage of SOA servitization is that loosely coupled coarse-grained application components can be distributed, combined, and used over a network as required.
The service layer is the foundation of SOA and can be invoked directly by applications to effectively control the artificial dependencies in the system that interact with software agents.
Servitization architecture is a set of loosely coupled architecture. The principle of service separation is high cohesion within services and low coupling between services.
Here is the servitization architecture diagram:
At this stage, Web Services or Dubbo can be used for Service governance.
Differences between SOA and microservices architecture
More: Microservices architecture explains: That’s called an easy to understand
The servitization architecture already solves most enterprise needs, so why do we study microservices?
Here are some of the differences:
- Microservice architecture emphasizes that business systems need to be thoroughly componentized and servitized. A component is a product and can provide services independently.
- Microservices de-emphasize the ESB Enterprise Service Bus (ESB), which is heavy in traditional SOA architectures.
- Microservices emphasize that each microservice has its own independent running space, including database resources.
- The microservice architecture itself is derived from the idea of the Internet, so the services released by components emphasize the use of HTTP Rest API.
- The granularity of microservices will be smaller.
Summary: Microservices architecture is an extension of SOA architecture, which emphasizes the independence of individual services and has smaller granularity.
Why consider Spring Cloud
There are several reasons to consider Spring Cloud:
- Spring Cloud comes from Spring, and its quality, stability and continuity can be guaranteed.
- SPRNG Cloud naturally supports Spring Boot, making it easier to land services.
- Spring Cloud iterates very quickly.
- Spring Cloud is the most suitable framework for microservices in the Java space.
- Compared to other frameworks, Spring Cloud has the most support for the microservices surrounding environment.
- For small and medium-sized enterprises, the use of low threshold.
- Spring Cloud is the best implementation of microservices architecture.
Features of Spring Cloud
The following are the core features of Spring Cloud:
- Distributed/versioned configuration
- Service registration and discovery
- routing
- Services and calls between services
- Load balancing
- The circuit breaker
- Distributed messaging
These features are done by different components and play an important role in the evolution of the architecture, as we’ll see below.
Microservices Architecture
The first problem Spring Cloud addresses is decoupling between services. When the business of many companies grows rapidly, the service component will increase accordingly.
There is A complex intercall relationship between services. Often, service A calls service B, and service B calls service C and service D… With the increasing number of servitization components, the calling relationship between services grows exponentially, as shown in the figure below:
⭐ is the most likely to lead to the situation is related to the whole body, often due to the update of a service without notice to other services, resulting in frequent disasters after the launch.
At this point, 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 problem.
Eureka
Eureka is designed to solve the snowball effect caused by the failure of a service to call the service, and decouple services from each other.
Eureka is an open source Service registration and Discovery product from Netflix that provides complete implementations of Service Registry and Service Discovery. It is also one of the most important and core components of the Spring Cloud architecture.
⭐ To put it simply, Eureka is a service center, which registers all services that can be provided to it for management. Other callers go to the registry to obtain services when they need them, and then call them, avoiding direct calls between services and facilitating subsequent horizontal expansion and failover. The diagram below:
Of course, if such an important component as the service center fails, all services will be affected. Therefore, Eureka cluster should be set up to maintain high availability. It is recommended to have at least two Eureka clusters in production.
As the system traffic increases, a service needs to be extended based on the situation. Eureka already provides load balancing function. You only need to add corresponding server instances.
What if an instance hangs while the system is running? Eureka content has a heartbeat detection mechanism. If an instance does not communicate within a specified period of time, it will be automatically removed to avoid the impact of the service caused by the failure of an instance.
Therefore, using Eureka automatically has registry, load balancing, and failover capabilities.
Hystrix
In microservice architectures, there are often multiple service layers called, and the failure of the underlying service may lead to cascading failures that make the entire system unusable, a phenomenon known as the service avalanche effect.
Service avalanche effect is a process in which the unavailability of “service providers” leads to the unavailability of “service consumers” and gradually amplifies the unavailability.
As shown in the figure below, A is the service provider, B is the service consumer of A, and C and D are the service consumers of B. An avalanche effect occurs when the unavailability of A causes the unavailability of B and snowballs the unavailability to C and D.
⭐ In this case, the entire service organization needs to have the function of fault isolation to prevent the failure of a service from affecting the whole world. The Hystrix component plays this role in Spring Cloud.
Hystrix immediately notifies the calling end of the call failure when a service is invoked for N consecutive times and does not respond, preventing the calling end from waiting and affecting the whole service. Hystrix intervals will check this service again and continue to provide service if it is restored.
Hystrix Dashboard, Turbine
⭐ When a circuit breaker occurs, rapid response is required to resolve the problem and prevent further spread of the fault, so monitoring of the circuit breaker becomes very important.
There are now two tools for monitoring fuse breaks: Hystrix-Dashboard and Turbine.
Hystrix- Dashboard is a real-time monitoring tool for Hystrix. Through the Hystrix Dashboard, you can intuitively view the request response time and request success rate of each Hystrix Command.
⭐ But with the Hystrix Dashboard, you can only see service information within a single app, which is not enough.
⭐ We needed a tool to aggregate data from multiple services within the system and display it on the Hystrix Dashboard. The tool was Turbine.
The monitoring effect is as follows:
Spring Cloud Config
With the increasing number of microservices, each microservice has its own profile. There are test environments, UAT environments, and production environments in the development process, so each microservice corresponds to at least three configuration files for different environments.
⭐ There are so many configuration files. If you need to modify the configuration information of a public service, such as cache and database, it will inevitably cause confusion. At this time, you need to introduce another component of Spring Cloud: Spring Cloud Config.
Spring Cloud Config is a configuration management solution for distributed systems. It consists of a Client and a Server. The Server stores the configuration file and provides the content of the configuration file in the form of an interface. The Client obtains data through the interface and initializes its application based on the data.
In this way, all the configuration files are servified on the Server, and the service instances of the configuration files need to obtain corresponding data from the Config Server. All configuration files are consolidated to avoid configuration file fragmentation.
If the configuration file is changed while the service is running, the service will not get the latest configuration information. To solve this problem, Refresh needs to be introduced. It can reload the configuration file during the running of the service.
When all configuration files are stored in the configuration center, the configuration center becomes a very important component.
If the configuration center fails, catastrophic consequences may occur. Therefore, you are advised to cluster the configuration center to support high availability of the configuration center.
Spring Cloud Bus
Although the Refresh solution above ⭐ can solve the problem of reloading configuration information during the run of a single microservice, in a real, practical production, there may be N more services that need to update their configuration. If relying on manual Refresh each time is too much work, Spring Cloud comes up with another solution: The Spring Cloud Bus.
Spring Cloud Bus connects distributed nodes through lightweight message brokers. This is used to 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 a distributed launcher, which can also be used to establish communication channels between one or more applications. The only way to do that right now is withAMQPThe message broker acts as a channel.
Spring Cloud Bus is a lightweight communications component that can be used in other similar scenarios. With Spring Cloud Bus, when we change the configuration file and commit it to the repository, it will automatically trigger the Refresh of the corresponding instance. The workflow is as follows:
API Gateway Service Gateway & Spring Cloud Zuul routing
⭐ In the microservice architecture mode, the number of back-end service instances is generally dynamic. It is difficult for clients to discover the access address information of dynamically changed service instances.
Therefore, in order to simplify the calling logic of the front end, API Gateway is usually introduced as a lightweight Gateway in the project based on microservices. At the same time, relevant authentication logic is also implemented in the API Gateway to simplify the complexity of calling each other between internal services.
The technology that supports API Gateway landing in ⭐Spring Cloud is Zuul. Spring Cloud Zuul Routing is an integral part of the microservices architecture, providing dynamic routing, monitoring, resilience, security and other edge services.
Zuul is a Netflix load balancer based on JVM routing and server side.
Its specific role is service forwarding, receiving and forwarding all internal and external client calls. Zuul can be used as a unified access point for resources, as well as perform permissions verification and similar functions on the gateway.
Link tracking: Spring Cloud Sleuth, Zipkin
With the increasing number of services, the analysis of the invocation chain will become more and more complex, such as the invocation relationship between services, the invocation chain corresponding to a certain request, and the consumption time between the invocation, etc. Monitoring these information becomes a problem.
In practical use, we need to monitor the indicators of services and communication between services, and these data will be the main basis for us to improve the system architecture.
Therefore, distributed link tracking becomes very important, and Spring Cloud provides specific solutions: Spring Cloud Sleuth and Zipkin.
Spring Cloud Sleuth provides link tracing for invocations between services. Sleuth allows you to know exactly what services a service request goes through and how long each service takes to process. So that we can be very convenient to clarify the call relationship between the micro-services.
Zipkin is an open source project for Twitter that allows developers to collect monitoring data from various Twitter services and provide a query interface.
conclusion
Let’s take a look at how Spring Cloud components work together as a whole.
As you can see from the figure above, Spring Cloud components work together to support a complete set of microservices architecture:
- Eureka is responsible for the registration and discovery of services, which are well connected.
- Hystrix monitors calls between services and provides circuit breaker protection for multiple consecutive failures.
- Hystrix Dashboard, Turbine is responsible for monitoring Hystrix’s fuses and giving them a graphical display.
- Spring Cloud Config provides a unified configuration center service.
- When configuration files change, Spring Cloud Bus is responsible for notifying services to get the latest configuration information.
- We forward all requests and services through Zuul, acting as an API gateway.
- Finally, Sleuth + Zipkin was used to record all the request data for our subsequent analysis.
Spring Cloud was designed from the very beginning with most of the capabilities required by the evolution of the architecture of Internet companies in mind, such as service discovery registry, configuration center, message bus, load balancing, circuit breakers, data monitoring, etc.
These functions are provided in pluggable form, so that we can reasonably select the required components for integration during the evolution of the system architecture, so that the evolution of the architecture will be smoother and smoother.
Microservice architecture is a trend, and Spring Cloud provides a standardized, full-site technology solution that may be comparable to the birth of the current Servlet specification, effectively advancing the technological level of server software systems.
Don’t limit your imagination to what you can do now!