About Spring Cloud microservices architecture Core Components

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. Services and services have complex inter-invocation relationships, often with service a called Service B, service B calls service C, and service D ..., as the number of serviced components increases, the call relationships between services grow exponentially, so the most likely scenario 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 hangs up will affect all services, therefore need to build Eureka cluster to maintain high availability, production recommended at least two units. 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. &NBSP

Therefore, the use of Eureka automatically has the function of registry, load Balancing, failover.  

hystrix  
There are often multiple service layer calls in the MicroServices architecture, and the failure of the underlying service can lead to cascading failures, which in turn will result in the entire system being unavailable. This phenomenon is called the 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.

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:

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.

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.

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.

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:

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.

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

About Spring Cloud microservices architecture Core Components