What does spring cloud do from an architectural evolution perspective?

Spring Cloud, as a framework for microservices governance, takes into account almost every aspect of microservices governance and has previously written about spring cloud articles that focus on the use of components, and this share answers both of these questions: Spring What does cloud do in the microservices architecture? How does Spring cloud offer these features to facilitate the architecture of microservices?

This is also the last article I wrote on the Spring Cloud trilogy, with the previous two sections as follows:

• Micro-service practices in small and medium-sized Internet companies-experiences and lessons learned

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

Let's take a brief look at the developments in our past Internet architectures:

Traditional Architecture History Monomer architecture

Monolithic architecture in small micro-enterprise is more common, the typical representative is an application, a database, a Web container can run up, such as our development of open source software cloud collection, is the standard monolithic architecture.

In both cases, the monomer architecture may be selected: First, in the early stage of enterprise development, in order to ensure the rapid launch, the adoption of such a scheme is more simple and flexible, the second is the traditional enterprise with high verticality, less access pressure business. In this mode, the technical requirements are low, convenient for all levels of developers to take over, but also to meet customer needs.

Here is the architecture diagram for the monolithic architecture:

In the monomer architecture, technology selection is very flexible, priority to meet the requirements of fast on-line, but also facilitate the rapid follow-up market.

Vertical architecture

After a period of development of the monomer structure, the company's business model has been recognized, trading volume is also slowly big up, at this time some enterprises in order to deal with the larger flow, will be the original business to split, such as: Back-end systems, front systems, trading systems.

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

Here is the schema diagram for the vertical schema:

At this stage ssh (struts+spring+hibernate) is the key technology of the project, struts is responsible for the Web layer logic control, spring is responsible for the business layer Management bean, Hibernate is responsible for the database operation encapsulation, persisted data.

Service-Structured architecture

If the company is further bigger, the vertical subsystem will become more and more, and the call relationship between the system and the system is increasing exponentially. In this context, many companies consider the SOA of services. SOA represents a service-oriented architecture that divides applications into different modules based on different responsibilities, with different modules interacting directly with specific protocols and interfaces. This allows the entire system to be divided into a number of individual component Services to complete the request, and when the traffic is too large to support by horizontally scaling the corresponding components, all the components interact to meet the overall business requirements.

The advantage of SOA service is that it can be distributed, combined, and used across the network for loosely coupled coarse-grained application components based on demand. The service layer is the foundation of SOA and can be called directly by application, thus effectively controlling the human dependence of the software agent interaction in the system.

The service architecture is a loosely coupled architecture in which service splitting is the principle of high cohesion within the service and low coupling between services.

Here is the service architecture diagram:

At this stage, you can use WebService or Dubbo to service governance.

We find that from the monolithic architecture to the service-based architecture, the number of applications is constantly increasing, slowly sinking into the foundation of the formation, the floating becomes the business system. From the above also can be seen that the essence of architecture is constantly split refactoring: the process of dividing the system into subsystems/modules/components, when the demolition, the first to solve each component positioning problems, and then to divide each other's boundaries, to achieve a reasonable split. The combination is the organic integration of the separate components according to the final requirements. Split results enable developers to focus on the business, focus on skills, achieve agile development, and the result is that the system becomes flexible and can be changed as needed to achieve business agility.

The difference between SOA and microservices architecture SOA and MicroServices

In fact, the service architecture has been able to solve the needs of most enterprises, then why should we study micro-services? First talk about their differences;

• MicroServices architecture emphasizes that business systems need to be completely modular and serviced, and that a component is a product that can provide services independently
• MicroServices no longer emphasize the relatively heavy ESB enterprise service bus in traditional SOA architectures
• MicroServices emphasize that each micro-service has its own separate running space, including database resources.
• The microservices architecture itself is rooted in the idea of the Internet, so the external services of components emphasize the use of the HTTP Rest API to
• Smaller granularity of micro-service segmentation

Summary: The microservices architecture is an extension of the SOA architecture idea, which emphasizes the independence of the service individual and the smaller the granularity of the separation.

Why consider Spring Cloud

• Spring cloud comes from spring, guaranteeing quality, stability and durability
• SPIRNG Cloud Naturally supports spring Boot, making it easier for businesses to hit the ground.
• Spring Cloud is developing very fast, starting in 16 when the relevant component version is 1.x and will now release the 2.x series
• Spring Cloud is the most suitable framework for microservices in the Java world.
• Spring Cloud has the most support for the micro-service perimeter environment compared to other frameworks.
• For small and medium-sized enterprises, the use threshold is low.

Spring Cloud is the best floor plan for microservices architectures

It's characteristic

The following are the core features of Spring cloud:

• Distributed/versioned Configuration
• Service Registration and Discovery
• Routing
• Calls between services and services
• Load Balancing
• Circuit Breaker
• Distributed Message Delivery

These features are done by different components and play an important role in the evolution of the architecture, so let's take a look at the next steps.

Micro-Service Architecture

The first problem that Spring Cloud solves is the decoupling between services and services. Many companies in the rapid development of business, service components will also increase correspondingly. There are complex invocation relationships between services and services, often service a calls service B, service B calls service C, and service D ..., as the number of serviced components increases, the call relationships between services grow exponentially, as shown in extreme cases:

This is the most likely cause of the situation is reaching. Often occurs because of a service update without notification to other services, resulting in a frequent tragedy after the online. At this point, service governance should be carried out, and the direct reliance between services will be transformed into service-to-service dependencies. The Spring Cloud Core component Eureka is a solution to this kind of problem.

Eureka

Eureka is a product of Netflix's open source offering service registration and discovery, which provides complete services registry and service discovery implementations. is one of the most important and core components of the spring cloud system.

With plain English, Eureka is a service center, all the services can be provided to register it here to manage, the other callers need to go to the registry to obtain, and then make the call, avoid the direct call between services, easy to follow the level of expansion, failover and so on. Such as:

Of course, the service center is such an important component one but hanging off will affect all services, so you need to build Eureka cluster to maintain high availability, the production of a minimum of two units recommended. As the flow of the system continues to increase, a service needs to be scaled according to the situation, and the Eureka internally has the capability of balancing the load, and only needs to add the corresponding server instance. What if an instance hangs during the run of the system? Eureka Content has a heartbeat detection mechanism, if an instance does not communicate within the specified time, it will automatically be eliminated, to avoid an instance hanging off and affect the service.

Therefore, the use of Eureka automatically has a registry, load balancing, failover functions. If you want to learn more about Eureka, you can refer to this article: Registration center Eureka

Hystrix

In a microservices architecture, there are often multiple service layer calls, and the failure of the underlying service can lead to cascading failures that could result in an entire system being unavailable, a phenomenon known as service avalanche effect. The service avalanche effect is a process in which the service consumer is not available and will not be usable due to the unavailability of the service provider.

As shown in: A as a service provider, B is a service consumer, C and D are service consumers of B. A unavailability causes the unavailability of B and will not be available as a snowball to C and D, the avalanche effect is formed.

In this case, the whole service is required to have the function of fault isolation, to avoid a service hanging off the impact of the global. The Hystrix component plays this role in spring Cloud.

Hystrix will immediately notify the caller of the call failure and prevent the caller from continuing to wait for the whole service to be affected if a service calls N-times without response. The Hystrix interval will check again for this service if service recovery will continue to serve.

Continue to understand Hystrix can refer to: Fuse hystrix

Hystrix Dashboard and turbine

When the fuse occurs, it is necessary to respond quickly to solve the problem and avoid further spread of the fault, so the monitoring of the fuse becomes very important. Fuse monitoring now has two tools: Hystrix-dashboard and turbine

Hystrix-dashboard is a real-time monitoring tool for Hystrix, through Hystrix dashboard we can visually see the request response time of each hystrix command, the request success rate and other data. But using only Hystrix dashboard, you can only see the service information in a single app, which is obviously not enough. We need a tool that allows us to summarize data from multiple services within the system and display it on the Hystrix dashboard, which is turbine.
The following are monitored:

To find out what metrics are monitored and how to monitor it, refer to this article: Fuse monitoring Hystrix dashboard and turbine

Configuration Center

With the increasing number of microservices, each micro-service has its own corresponding configuration file. In the development process has the test environment, the UAT environment, the production environment, therefore each micro-service also corresponds to at least three different environment configuration file. So many configuration files, if you need to modify the configuration information of a public service, such as: cache, database, etc., will inevitably create confusion, this time 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 contains the client and server two parts, the server provides the configuration file storage, in the form of an interface to provide the contents of the configuration file, the client through the interface to obtain data, and based on this data to initialize their own applications.

In fact, the server side will all the configuration file service, need to configure the service instance of the file to the config server to obtain the corresponding data. All configuration files are consolidated to avoid configuration file fragmentation. Configuration Center git instance reference: Configuration center git sample;

If the configuration file is changed during service run time, the service will not get the latest configuration information and need to solve this problem to introduce refresh. You can reload the configuration file during the run of the service, as detailed in this article: Configuration Center svn example and refresh

When all the configuration files are stored in the configuration center, the configuration center becomes a very important component. If a problem with the configuration center can result in catastrophic consequences, it is recommended that you cluster the configuration center in production to support high availability of the configuration center. Specific reference: Configure hub service and high availability

Spring Cloud Bus

The refresh scheme above can solve the problem of overloading configuration information during the operation of a single microservices, but in real practice production, there may be more than n services that need to be updated, and if you rely on manual refresh every time it will be a huge workload, then spring Cloud presents another solution: Spring Cloud Bus

Spring Cloud Bus connects the nodes of each distribution through a lightweight message broker. This is used for changes in broadcast status (such as configuration changes) or other message directives. One of the core ideas of spring Cloud bus is to extend the spring boot application through a distributed launcher, or to establish communication channels between one or more applications. The only way to implement this is to use the AMQP message agent 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 submission to the repository, it automatically triggers the refresh of the corresponding instance, with the following workflow:

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

Service Gateway

In MicroServices architecture mode, the number of instances of back-end services is generally dynamic, and it is difficult for clients to discover the access address information of dynamically changing service instances. Therefore, in order to simplify the invocation logic of the front end in a microservices-based project, the API gateway is often introduced as a lightweight gateway, and the API gateway implements the relevant authentication logic to simplify the complexity of calls between internal services.

The technology that supports API Gateway's landing in the Spring cloud system is zuul. Spring Cloud Zuul Routing is an integral part of the microservices architecture, providing dynamic routing, monitoring, resiliency, security, and other edge services. Zuul is a load balancer based on the JVM Routing and service side of Netflix.

Its specific role is service forwarding, receiving and forwarding all internal and external client calls. The use of Zuul can be used as a unified access portal for resources, but also can be done in the gateway to do some similar functions such as permission checking.

For specific use reference this article: Service Gateway Zuul

Link Tracking

As the service becomes more and more, the analysis of the call chain becomes more and more complex, such as the call relationship between services, the call chain corresponding to a request, the time spent between calls, and so on, which is a problem to monitor. In practical use we need to monitor the metrics of communication between services and services, which will be the primary basis for our improved system architecture. As a result, distributed Link tracking becomes very important, and spring cloud provides a concrete solution: Spring Cloud Sleuth and Zipkin

Spring Cloud Sleuth provides link tracking for calls between services. With sleuth, you can clearly understand what services a service request has gone through, and how long each service has taken to process. So that we can easily clarify the relationship between micro-service calls.

Zipkin is an open source project on Twitter that allows developers to collect monitoring data on Twitter's services and provide a query interface

Distributed Link Tracking requires Sleuth+zipkin combination to achieve, specific operation reference This article: Distributed Link Tracking (sleuth)

Summarize

Let's take a holistic look at how the various components of spring cloud work together:

We can see that the various components of spring cloud work together to support a complete micro-service architecture.

• Among them, Eureka is responsible for the registration and discovery of the service, which connects the services well.
• The hystrix is responsible for monitoring the call situation between services, successive failures for fuse protection.
• Hystrix Dashboard,turbine is responsible for monitoring the hystrix of the fuse and giving a graphical display
• Spring Cloud Config provides a unified configuration center service
• When the configuration file changes, Spring Cloud Bus is responsible for notifying the services to get the latest configuration information
• All external requests and services, we are through the Zuul to carry forward, play the role of the API Gateway
• Finally, we use Sleuth+zipkin to record all the request data, so that we could perform the subsequent analysis.

Spring cloud has taken into account the features of most Internet company architectures since its inception, such as service discovery registration, Configuration center, message bus, load balancing, circuit breakers, data monitoring, and more. These functions are provided in the form of plug-in, convenient for our system architecture evolution process, we can reasonably choose the components required for integration, so that the evolution of the architecture will be smoother and smoother.

Micro-service architecture is a trend, Spring cloud provides a standardized, all-in-one technical solution, meaning may be comparable to the current servlet specification is born, effectively promote the service side software system technology progress.

This is my share of gitchat. What does Spring Cloud do in terms of architectural evolution?

What does spring cloud do from an architectural evolution perspective?