preface

Spring Cloud, as the current mainstream microservice framework, enables us to realize the microservice architecture in A simple and quick way. The roles of various components in Spring Cloud in the microservice architecture are shown in the figure below. The black line indicates the annotation, and the blue line points from A to B, indicating that B obtains services from A.

The microservices architecture shown in the figure above is roughly composed of the logical structure shown in the figure above, including various microservices, registration discovery, service gateways, fuses, unified configuration, tracking services, etc. Here’s what roles the components in the Spring Cloud play.

Feign

Feign(Interface Invocation) : Micro services communicate with each other through the Rest interface. Spring Cloud provides the Feign framework to support Rest invocation. Feign enables THE Rest interface invocation of different processes to be performed in an elegant manner that behaves like the same process invocation.

Eureka

Netflix Eureka (Registration discovery) : In the micro-service mode, a large Web application is usually divided into many smaller Web applications (services). At this time, it is necessary to have a place to store the relevant information of these services, so that each small application can know each other. At this time, it is necessary to register in the registry. Each application registers its own information (IP address, port number, service name and other information) to the configured registry when it is started. The registry stores them. When services call each other, they can find the corresponding service information through the service name in the registry, so as to communicate. Registration and discovery services facilitate calls between microservices, eliminating the problem of hard coding. Services can obtain services from each other only by using the service ID of each other, without knowing the IP address and port number of each other.

Ribbon

Ribbon(Load Balancing) : Ribbon is a Load balancer released by Netflix that helps control the behavior of HTTP and TCP clients. After configuring the address list of service providers for the Ribbon, the Ribbon automatically assists service consumers with requests based on some load-balancing algorithm. The Ribbon provides many load balancing algorithms by default, such as polling, randomization, and so on. Of course, we can also implement custom load balancing algorithms for the Ribbon. In SpringCloud, when the Ribbon works with Eureka, it automatically gets a list of service providers’ addresses from EurekaServer and requests an instance of one of them based on a load balancing algorithm (multiple instances may be deployed on a microservice for reliability).

Hystrix

Hystrix(fuse) : When the service provider is very slow to respond, consumer requests to the provider are forced to wait until the provider responds or times out. In high-load scenarios, such problems can lead to resource exhaustion for service consumers or even system collapse (avalanche effect) if nothing is done. Hystrix is trying to prevent this kind of problem. Hystrix is a delay and fault tolerant library open-source by Netflix that isolates access to remote systems, services, or third-party libraries to prevent cascading failures, thereby improving system availability and fault tolerance. Hystrix implements delay and fault tolerance mainly through the following points.

Parcel request:

HystrixCommand (or HystrixObservableCommand) wraps the invocation logic for dependencies, with each command executed in a separate thread. This uses “command mode” in design mode.

Trip mechanism:

When the error rate of a service exceeds a certain threshold, Hystrix automatically or manually stops requesting the service for a period of time.

Resource isolation:

Hystrix maintains a small thread pool (or semaphore) for each dependency. If the thread pool is full, requests to the dependency are rejected immediately rather than queued up, speeding up failure determination.

Monitoring:

Hystrix can monitor operational metrics and configuration changes, such as successes, failures, timeouts, and rejected requests, in near real time.

Rollback mechanism:

Fallback logic is performed when a request fails, times out, is rejected, or when a circuit breaker is on. The fallback logic can be specified by the developer.

Zuul

Zuul(Microservices Gateway) : Different microservices generally have different network addresses, and external clients may need to invoke the interfaces of multiple services to fulfill a business requirement. For example, a mobile APP for movie ticket purchase may call the interfaces of multiple micro-services to complete the business process of ticket purchase at one time. If the client is allowed to communicate directly with each micro-service, the following problems will occur:

The client requests different microservices multiple times, increasing the complexity of the client.

Cross-domain requests exist and are complicated to process in certain scenarios.

Authentication is complex and each service requires independent authentication.

It is difficult to refactor, and as the project iterations, microservices may need to be reclassified. For example, you might combine multiple services into one or split a service into multiple services. Refactoring can be difficult to implement if the client communicates directly with the microservice.

Some microservices may use protocols that are not firewall/browser friendly and may be difficult to access directly.

The above problems can be solved by the micro-service gateway. The microservice gateway is an intermediate layer between the client and server, through which all external requests pass first. With the microservice gateway, the microservice gateway encapsulates the internal structure of the application, and the client only interacts with the gateway rather than directly invoking the interface of a particular microservice. In this way, development can be simplified. In addition, using a microservices gateway has the following advantages:

Easy to monitor. Monitoring data can be collected at the microservices gateway and pushed to external systems for analysis.

Easy to authenticate. Authentication can be done in the microservice gateway and then the request can be forwarded to the microservice on the back end instead of being authenticated in each microservice.

Reduce the number of interactions between the client and each micro-service.

Config

Spring Cloud Config (Unified Configuration Service) : For traditional monolithic applications, configuration files are often used to manage all configurations. For example, a single application developed by springBoot can put the configuration content in the application.yml file. If you need to switch environments, you can set multiple profiles and specify Spring.profiles. active={Profile} when starting the application. However, in microservices architecture, configuration management of microservices generally has the following requirements:

Centralized management configuration. An application using a microservice architecture may contain hundreds or thousands of microservices, so centralized management of the configuration is necessary. Different configurations in different environments. For example, data source configurations are different in different environments (development, test, pre-release, production, and so on). Dynamic adjustment during operation. For example, the data source connection pool size or fuse threshold can be dynamically adjusted based on the load of each microservice, and the microservice can be adjusted without stopping the configuration.

The configuration is automatically updated after modification. If the configuration changes, the microservice can automatically update the configuration. In summary, a common configuration management mechanism is essential for microservices architectures, and a common practice is to use configuration servers to manage configurations. Spring Cloud Bus uses Git or SVN to manage configurations and Kafka or RabbitMQ message bus to notify all applications, so as to automatically update configurations and refresh configurations of all microservice instances.

Zipkin

Sleuth+ZipKin(Tracking Service) : Sleuth and ZipKin together provide a graphical interface to view the latency of microservice requests and the dependencies of individual microservices. It is important to note that Spring Boot2 and above does not support Zipkin customization. You need to download the Zipkin JAR package from the official website.

other

Another thing that needs to be mentioned is spring Boot Actuator, which provides many monitoring endpoints.

For example, /actuator/info, /actuator/ Health, and /acutator/refresh can view the information, health status, and configuration update of microservices.

The last

I have compiled more than 1000 pages of Java interview materials from various companies in 2021 in PDF document, which will be updated and included in the document.