Spring Cloud, as a microservices governance framework, considers almost all aspects of microservices governance. I have written some articles about Spring Cloud before, focusing on the use of components. This article mainly answers two questions: What does Spring Cloud do in microservices architecture? How do these features provided by Spring Cloud facilitate the architecture of microservices?

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

  • Micro services practices for Small and medium Internet companies – lessons learned

  • Can Spring Cloud be used by small and medium sized companies in China?

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.

In two cases, a single architecture may be selected. First, in the early stage of enterprise development, it is relatively simple and flexible to adopt such a scheme in order to ensure rapid online; The other is the business with higher verticality and less 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:

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 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. SOA stands for service-oriented architecture, which divides applications into modules with different responsibilities, and the different modules interact directly 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:

WebService or Dubbo can be used for service governance at this stage.

We find that from single architecture to service-oriented architecture, the number of applications is constantly increasing, slowly sinking into the foundation, floating into the business system. It can also be seen from the above that the essence of architecture is continuous disassembly and reconstruction: the process of disassembly is to split the system into various subsystems/modules/components. When disassembly, the positioning of each component should be solved first, and then the boundaries of each other can be divided to achieve reasonable disassembly. Integration is the organic integration of separate components according to the final requirements. The result of the split is that developers can be business focused and skill focused to achieve agile development. The result of the split is that the system becomes flexible and can change as needed to achieve agile business.

SOA and microservices architecture

The difference between SOA and microservices

In fact, service-oriented architecture can already solve the needs of most enterprises, so why do we research microservices? Let’s talk about 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

  • 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.

  • The development of Spring Cloud is very fast. The related component version was 1.x when I first started to contact Spring Cloud in 2016, and now the 2.x series will be released

  • 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

The characteristics of it

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 in extreme cases:

The easiest way to do this is to get involved. It is often not notified to other services due to the update of one service, 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, addresses these issues.

Eureka

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.

In plain English, 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, the failure of such an important component as the service center will affect all services. Therefore, Eureka cluster needs to be built 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. If you want to learn more about Eureka, see this article: Registry Eureka

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.

To learn more about Hystrix, see: Fuse Hystrix

Hystrix Dashboard and 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 isn’t enough. We need a tool to aggregate data from multiple services in the system and display it on the Hystrix Dashboard. The tool is Turbine. The monitoring effect is as follows:

To find out what metrics are being monitored and how to monitor them, see the article: Fuse Monitor Hystrix Dashboard and Turbine

Configuration center

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. 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. In this case, 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 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 fact, all the configuration files are servified by the Server. 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. Configuration center Git example 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. To solve this problem, Refresh needs to be introduced. The configuration file can be reloaded during the running of the service, as described in this article: Configuring the Central SVN Example and Refresh

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. For details, see Configuring the service and high availability of the center

Spring Cloud Bus

Although the Refresh solution above can solve the problem of reloading configuration information during the operation of a single microservice, in real practice, there may be N more services that need to update configuration. If relying on manual Refresh each time would be a huge workload, Spring Cloud proposes another solution: 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. Currently, the only way to do this is with the AMQP message broker as the 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 to commit to the version library, it will automatically trigger the Refresh of the corresponding instance. The workflow is as follows:

Also refer to this article: Configuring hubs and message buses

The service gateway

In the microservice architecture mode, the number of back-end service instances is generally dynamic, and it is difficult for clients to find 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.

Zuul is the technology in the Spring Cloud architecture that supports API Gateway landing. 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.

See this article for details: Service Gateway Zuul

The link to track

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 the actual 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

Distributed link tracking needs Sleuth+Zipkin combination to achieve.

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 microservices architecture.

  • Eureka is responsible for the registration and discovery of services, which is a good link between services

  • 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

  • All outbound requests and services are forwarded 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 the form of insertion and removal, so that the required components can be reasonably selected for integration during the evolution of the system architecture, making the evolution of the architecture 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.

MORE | MORE excellent articles