directory

Eureka

Ribbon and Feign

Zuul

Hystrix

Config

Summarized below

Let’s take a look at the various components of SpringCloud and see why.

Before explaining the principle, first look at a most classic business scenario, such as developing an e-commerce website, to realize the function of paying orders, the process is as follows:

1. After creating an order, if the user immediately pays for the order, we need to update the order status to “paid”.

2. Deduct the corresponding inventory of goods

3. Notify the warehouse center for shipment

4. Add points to the user for this purchase

As mentioned above, the application scenarios and core competitiveness of microservices are as follows:

• Reduced coupling: Each microservice focuses on a single function and clearly expresses service boundaries through well-defined interfaces. Due to its small size and low complexity, each microservice can be fully controlled by a small development team, making it easy to maintain high maintainability and development efficiency.

• Independent deployment: Because microservices have independent running processes, each microservice can also be deployed independently. There is no need to compile and deploy the entire application when a microservice changes. Applications made up of microservices have a series of parallel distribution processes, making distribution more efficient, reducing the risk to the production environment, and ultimately shortening the application delivery time.

• Flexible selection: Under the microservice architecture, technology selection is decentralized. Each team is free to choose the most appropriate technology stack based on its own service needs and industry development status. Because each microservice is relatively simple, the risk of upgrading the technology stack is low, and even a complete refactoring of a microservice is feasible.

• Fault tolerance: When a component fails, in the traditional architecture of a single process, the failure is likely to spread within the process, resulting in application-wide unavailability. In a microservice architecture, faults are isolated within a single service. If well designed, other services can achieve fault tolerance at the application level through retry, smooth degradation and other mechanisms.

• Flexible scale-out: Monolithic applications can also achieve scale-out by copying the entire application to different nodes. Microservices architectures are flexible when different components of an application have different scaling requirements, because each service can scale independently based on actual needs.

Dubbo benchmarking Spring Cloud microservices:

• Background analysis: Dubbo is the core framework of Alibaba’s servitization governance and has been widely used in Various Internet companies in China. Spring Cloud is a product of the well-known Spring family. Alibaba is a commercial company, although it has opened many top-level projects, but from the overall strategy, it still mainly serves its own business. Spring focuses on the development of enterprise-level open source frameworks, which are widely used both in China and around the world. Developing common, open source and robust open source frameworks is their main business.

• Activity comparison: Dubbo is a very good service governance framework, and does better than Spring Cloud in service governance, gray publishing, traffic distribution, except dangdang added REST support on the basis, there has been almost no update for more than two years. There are few replies to issues submitted to GitHub due to problems in use. On the contrary, Spring Cloud is still developing rapidly since its development. As can be seen from the frequency of submitting code on GitHub and the time interval of release, Spring Cloud is about to release version 2.0, which will be more perfect and stable in the later stage.

• Platform architecture: The Dubbo framework only focuses on governance between services. If we need to use configuration centers and distributed tracking, we need to integrate these things ourselves, which makes it more difficult to use Dubbo virtually. Spring Cloud considers almost every aspect of service governance and is supported by Spring Boot, making it very convenient and simple to develop.

• Tech prospects: Dubbo is also benefiting small and medium-sized companies. After so many years of development, the Internet industry has also emerged more advanced technology and ideas, Dubbo is a bit of a pity. Spring launched Spring Boot/Cloud for many reasons of its own. Spring’s original lightweight framework has grown larger over time, with more integration projects and more cluttered configuration files, slowly moving away from the original concept. Over the years, with the advent of new technology concepts such as microservices, distributed link tracking, and more, Spring desperately needed a framework to improve its development model, hence the Spring Boot/Cloud project. You’ll notice that Spring Boot and Spring Cloud have been placed in the top two of the three most highlighted projects on the home page, indicating the importance Spring attaches to these two frameworks. Dubbo implements the following:

Spring Cloud implementation ideas:

Eureka

How it works: Master service registration and discovery, where the name of a microservice is registered with Eureka, allows the microservice to be found through Eureka without modifying the configuration file of the service invocation.

Analysis: Spring Cloud encapsulates Eureka module developed by Netflix to realize service registration and discovery, adopting C-S design architecture. Eureka Server serves as the Server of service registration function, which is the service registry center. Other microservices in the system use The Eureka client to connect to the Eureka Server and maintain the heartbeat. In this way, the maintenance personnel of the system can monitor the normal operation of each micro-service in the system through Eureka Server. Some other modules in Spring Cloud, such as Zuul, can use Eureka Server to discover other microservices on the system and perform related logic.

Eureka Server

Eureka Server provides the service registration service. After each node is started, it registers with the Eureka Server. In this way, the service registry of the Eureka Server stores information about all available service nodes.

Eureka Client

Eureka Client is a Java Client designed to simplify Eureka Server interactions. The Client also has a built-in load balancer that uses round-robin load algorithms. After the application is started, a heartbeat is sent to the Eureka Server (default interval is 30 seconds) to prove that the current service is available. If the Eureka Server does not receive the heartbeat from the client within a certain period of time (90 seconds by default), the Eureka Server will remove the service node from the service registry.

Eureka Server self-protection mechanism

If more than 85% of the nodes do not have a normal heartbeat within 15 minutes, Eureka considers that there is a network failure between the client and the registry.

• Eureka no longer removes services from the registry that should expire because they have not received a heartbeat for a long time

• Eureka can still accept registration and query requests for new services, but will not be synchronized to other nodes (i.e. the current node is still available).

• When the network is stable, the new registration information of the current instance is synchronized to other nodes

Therefore, Eureka can cope with the loss of some nodes due to network failure, rather than the whole registration service collapse like ZooKeeper.

Eureka and ZooKeeper

The famous CAP theory states that A distributed system cannot satisfy C (consistency), A (availability), and P (partition fault tolerance) at the same time. Since fault tolerance of partitions is A must in distributed systems, we have to make A trade-off between A and C.

They guarantee the CP

When we query the registry for a list of services, we can tolerate the registry returning the registration information from a few minutes ago, but we cannot accept that the service is down and unavailable. In other words, service registration features require more availability than consistency. However, in ZooKeeper, when the Master node loses contact with other nodes due to a network fault, the remaining nodes re-elect the leader. The problem is that it takes a long time to elect a leader (30 to 120s), and the whole ZooKeeper cluster is unavailable during the election, which leads to the breakdown of the registration service during the election. In the cloud deployment environment, it is highly likely that the ZooKeeper cluster will lose the Master node due to network problems. Although the service can be restored eventually, it is intolerable that the registration will be unavailable for a long time due to the long election time.

Had guaranteed the AP

Eurek prioritizes usability at design time. All Eureka nodes are equal. The failure of several nodes will not affect the work of normal nodes. The remaining nodes can still provide registration and query services. When Eureka clients register with a Eureka or find a connection failure, they will automatically switch to other nodes. As long as one Eureka is still available, the registration service can be guaranteed (guaranteed availability), but the information found may not be the latest (not guaranteed strong consistency).

In addition, Eureka also has a self-protection mechanism, see above.

conclusion

Eureka can deal with the loss of some nodes due to network failure, rather than the entire registration service crash like ZooKeeper.

Eureka is much more “professional” than ZooKeeper as a pure service registry, because registry services are more about availability, and we can accept that consistency is not achieved in the short term.

​

Ribbon and Feign

In the microservices architecture, the business is split into a separate service, and the communication between services is based on HTTP RESTful. Spring Cloud has two service invocation methods, Ribbon+RestTemplate and Feign.

concept

Netflix Ribbon is a client load balancing tool based on the polling strategy.

Client load balancing: Load balancing Zuul gateway sends a request to an application for a service. If a service has multiple instances started, the Ribbon uses a load balancing policy to send the request to a service instance. In the Ribbon of Spring Cloud, the client will have a list of server addresses, select a server through load balancing algorithm (such as simple polling, random connection, etc.) before sending a request, and then access it.

Load balancing

• Load balancing: Used to spread workloads across multiple servers to improve the performance and reliability of websites, applications, databases, or other services.

• The benefits of using load balancing are obvious: When one or more servers in a cluster go down, the remaining servers can continue to use services. By distributing the access load to each server, the system CPU does not spike due to a single peak hour.

• Load balancing has several implementation strategies, including Random, RoundRobin, ConsistentHash, Hash, and Weighted.

• The default policy of the Ribbon is polling

RestTemplate

Traditionally, RESTful services have been accessed in Java code, usually using Apache’s HttpClient, but this approach is too cumbersome to use. Spring provides a simple and convenient template class to operate on, RestTemplate.

Feign is a declarative HTTP client. Using Feign makes it much easier to write HTTP clients by defining an interface and then annotating it, eliminating the need to constantly parse/encapsulate JSON data when calling the target microservice. Feign integrates Ribbon by default in Spring Cloud and combines it with Eureka to achieve load balancing by default.

The difference between Ribbon and Feign

Feign aims to make it easier to write Java Http clients

When Ribbon+ RestTemplate is used, the Ribbon needs to build HTTP requests, simulate HTTP requests, and then send them to other services using the RestTemplate. Using RestTemplate to encapsulate the HTTP request processing, the formation of a – template – based call method. However, in real development, because service dependencies may be called in more than one place, often an interface may be called in more than one place, it is common to wrap some client classes for each microservice to wrap the invocation of these dependent services. So, Feign took this one step further and helped us define and implement the definition of the dependent service interface.

Under the Feign implementation, we just need to create an interface and configure it with annotations (previously Dao interface with Mapper annotation, now it is a microservice interface with Feign annotation) to complete the interface binding to the service provider. Simplifies the development of automatically wrapped service invocation clients when using Spring Cloud Ribbon.

Feign integrates with the Ribbon

Unlike the Ribbon, which implements client load balancing through polling, Feign is a declarative Web services client. It makes writing Web services clients very easy. You just create an interface, add annotations to it, and call it as if it were a local method. It doesn’t feel like it’s calling a remote method. Feign integrates Ribbon by default in SpringCloud, and combines it with Eureka to achieve load balancing by default.

The difference between Ribbon and Nginx

Server side load balancer Nginx

Nginx is all requests from the client are handed to Nginx in a unified manner. Nginx implements load balancing request forwarding, which belongs to server-side load balancing. The request is forwarded by the Nginx server. Client Load balancing Ribbon. The Ribbon obtains the service registry information list from the Eureka registry server, caches it to the local server, and implements polling load balancing policies locally. Load balancing is implemented on the client.

Differences in application scenarios

Nginx is suitable for server-side load balancing, such as Tomcat. The Ribbon is suitable for local service load balancing with remote RPC calls in microservices, such as Dubbo and Spring Cloud.

Zuul

Application scenarios

If there are currently dozens of micro-services, orders, goods, users, etc., obviously the client does not need to deal with each service one by one, so there needs to be a unified entry point, which is the service gateway. API Gateway All client requests access backend services through this gateway. It can use certain routing configurations to determine which service handles a URL. And get the registered service from Eureka to forward the request.

The core function

Zuul contains two of the most important functions for routing and filtering requests. Zuul is a unified gateway to various services, as well as providing monitoring, authorization, security, scheduling, and more.

Routing: is responsible for forwarding external requests to specific microservice instances and is the basis for achieving a unified entry point for external access.

Filter function: it is responsible for intervening in the process of request processing, and is the basis for realizing request verification, service aggregation and other functions.

Integration of Zuul and Eureka: Registration of Zuul itself as an application under Eureka service governance, and access to other microservices from Eureka. In other words, future access to microservices is obtained through Zuul jump.

Note: The Zuul service will eventually be registered with Eureka, providing proxy + routing + filtering.

Core principles

At Zuul’s core is a set of filters that can act like filters from the Servlet framework, or AOP.

Filters do not communicate with each other directly, but pass data through the Request Context.

Zuul’s filters are written in Groovy. These filter files are placed in specific directories on Zuul Server. Zuul polls these directories periodically, and the modified filters are dynamically loaded into Zuul Server for filtering requests.

Zuul load balancing: Zuul intercepts the corresponding API prefix request and forwards it to the corresponding serverId. In Eureka service, the same serverId can correspond to multiple services, that is to say, two instances can be registered with different ports of the same service node. However, the serverId is the same. Zuul will combine eureka-Server for load balancing when forwarding.

Types of filters:

• PRE (PRE) : This filter is invoked before the request is routed. We can use this filter to realize authentication, current limiting, parameter verification and adjustment, etc.

• ROUTING: This filter routes requests to the microservice. This filter is used to build requests sent to microservices and request microservices using Apache HttpClient or Netfilx Ribbon.

• POST (POST) : This filter is executed after routing to the microservice. Such filters can be used to add standard HTTP headers to responses, collect statistics and metrics, send responses from microservices to clients, logs, and so on.

• ERROR: This filter is executed when errors occur in other phases.

Zuul and Nginx

Zuul, while not as powerful as Nginx, has its advantages. Zuul provides edge services such as authentication, dynamic routing, monitoring, flexibility, security, and load balancing. Using Zuul as a gateway is a good way to get started quickly if the team size is small and there is no dedicated route development.

Nginx and Zuul can be used together to give full play to their respective advantages, using Nginx as a load balance for high-concurrency request forwarding and Zuul as a gateway.

Zuul and the Ribbon implement load balancing

Zuul supports the Ribbon and Hystrix, as well as client load balancing. Isn’t our Feign also client-side load balancing and Hystrix? Now that Zuul has been implemented, is our Feign still necessary?

It can be interpreted as follows:

Zuul is the only exposed interface. The request of Controller is routed, while the request of Service is routed by Ribbonhe and Fegin.

Zuul does load balancing for the outermost requests, while Ribbon and Fegin do load balancing for service calls across microservices within the system.

Hystrix

introduce

Hystrix is a system to deal with distributed delay, and fault tolerance of the open source library, in a distributed system, many rely on cannot avoid rabbit can call fails, such as overtime, abnormal, Hystrix can guarantee in the case of a dependency problem, won’t cause the overall service failure, avoid cascading failure, in order to improve the flexibility of a distributed system. Hystrix was created to deal with the avalanche effect.

Service avalanche

When invoking multiple microservices, it is assumed that microservice A calls microservice B and microservice C, and microservice B and microservice C call other microservices, which is called “fan out”. If the response time of A microservice invocation on the fan-out link is too long or unavailable, the invocation of microservice A will occupy more and more system resources, resulting in system crash, the so-called “avalanche effect”.

Service fusing

Circuit breaker mechanism is a kind of micro – service link protection mechanism to deal with avalanche effect.

If a microservice on the deleted link is unavailable or the response time is too long, the service will be degraded, and the invocation of the microservice on the node will be interrupted, and an error message is quickly returned. Restore the call link after detecting that the microservice invocation response of this node is normal. In the SpringCloud framework, circuit breakers are implemented through Hystrix. Hystrix monitors the status of calls between microservices, and when the number of failed calls reaches a certain threshold, the default is 20 failed calls within 5 seconds. The comment on the circuit breaker mechanism is @hystrixCommand.

Service degradation

The overall resources are not enough, so we will turn off some services and then turn them back on.

Hystrix monitoring and circuit breakers

We just need to add the Hystrix tag to the service interface, and we can implement the monitoring and circuit breaker function of this interface.

The Hystrix Dashboard monitoring panel provides an interface to monitor the time consumed by service invocation on various services.

Hystrix Turbine monitors aggregation

With Hystrix monitoring, we need to open the monitoring information for each service instance to view. Turbine can help us aggregate the monitoring information of all service instances into one place for unified viewing. So you don’t have to go from page to page.

Safety mechanism of Zuul

Sig signature algorithm is MD5 (appKey+appSecret+ TIMESTAMP). AppKey is the ID assigned to the client, appSecret is the key assigned to the client. Timestamp is a Unix timestamp and the requested URL is valid for 15 minutes.

Token mechanism, users will return an Access_ Token after login, and clients need to use Bearer mode in the Authorization header to access the resources that require login, such as head(” Authorization “, Bearer token “).

Hystrix design principles

• Resource isolation (thread pool isolation and semaphore isolation) mechanisms: Restrict the use of resources for invoking distributed services, so that problems in one service invocation do not affect other service invocations.

• Traffic limiting mechanism: The traffic limiting mechanism sets the highest QPS threshold for each type of request in advance. If the threshold is higher than the threshold, the request is returned without invoking subsequent resources.

• Circuit breaker mechanism: When the failure rate reaches the threshold, the fault will be degraded automatically (for example, the failure rate is really high due to network failure or timeout). The quick failure triggered by the fuse will be recovered quickly.

• Demotion mechanism: demotion due to timeout, demotion when resources are insufficient (thread or semaphore), abnormal operation demotion, etc. After demotion, it can cooperate with the demotion interface to return bottom data.

• Cache support: provides the request cache, request merge implementation.

• The near real-time statistics/monitoring/alarm function improves the speed of fault discovery.

• You can configure the properties and hot change function in near real time to improve the speed of troubleshooting and recovery.

Config

introduce

Spring Cloud Config is a configuration management solution for distributed systems. Microservices mean that the services in a single application are divided into sub-services. Each service has a relatively small granularity, so there are a large number of services in the system. Because each service requires the necessary configuration information to operate, a centralized, dynamic configuration management facility is essential. Spring Cloud provides ConfigServer to solve this problem. Each microservice comes with its own application. Yml management of hundreds of configuration files.

Application scenarios

• It is difficult to maintain. Multiple users modify configuration files at the same time, resulting in constant conflicts

• The configuration of content security and permissions, mainly for online configuration, is generally not open to development, only operation and maintenance have permissions, so the configuration file needs to be isolated, not put in the project code

• The configuration project needs to be restarted every time the configuration file is updated, which is time-consuming. With the use of the Configuration center, real-time configuration updates can be realized with the combination of CongFig Server and Config Client with Spring Cloud Bus to achieve automatic configuration refresh.

The principle of

• The configuration file is stored in the remote Git repository (such as GitHub and Gitee repositories). The config-server pulls the configuration file from the remote Git and saves it to the local Git.

• The interaction between local Git and config-server is bidirectional, because the configuration file is fetched from the local Git when the remote Git is not accessible.

• Config-client (i.e., each micro-service) pulls configuration files from config-server.

role

• Config Server: stores the configuration file and provides the content of the configuration file through interfaces.

• Config Client: obtains data through the interface and initializes the application based on the data.

Summarized below

Java has a wide range of knowledge, and interview questions cover a wide range of topics, including: Java foundation, Java concurrency, JVM, MySQL, data structures, algorithms, Spring, microservices, MQ, etc., involved in the knowledge of how huge, so we often don’t know how to start in the review, today small editor to bring you a set of Java interview questions, questions library is very comprehensive. Including Java basics, Java Collections, JVM, Java concurrency, Spring buckets, Redis, MySQL, Dubbo, Netty, MQ, etc., including Java back-end knowledge 2000 +

Information access: public account: “Programmer Bai Nannan” to obtain

​