1. Spring-cloud is based on Spring-Boot. The difference between spring-Boot and traditional Spring projects is that the framework built by thin configuration is lighter and faster to use
2. The difference between spring-Cloud and traditional projects is
The former is distributed and the latter is a single architecture. Distributed means that each sub-project is independent between services and some services support multiple other service calls [equivalent to simplifying repetitive code]. Of course, two important services are needed in this distribution
2.1 Gateway services (equivalent to ‘distributing’ to different routes) 2.2 Authentication services (Limited private back-end requests require permissions, which may be login permissions or role permissions)
3. Service Registration and discovery:
Registries typically use Eruke, followed by service providers and service consumers
Eruke [High Availability Service Registry] :1. You can have multiple registries 2. Multiple registries can register with each other. 3. When one of the registries dies, the others can still provide services
4. Service consumers: Ribbon and Feign are commonly used
4.1 Spring Cloud Ribbon
4.1.1 Spring Cloud Ribbon is a set of client load balancing tools based on Netflix Ribbon. It is a client load balancer based on HTTP and TCP. RibbonServerList can be configured on the client to configure the server list for polling access to balance load.
4.1.2 Retry Mechanism
4.1.3 Eagle-load mode
4.2 Spring Cloud Feign
4.2.1. The Ribbon is a load balancer based on HTTP and TCP clients. The Ribbon is also used in Feign.
4.2.2.Spring Cloud Feign is a set of declarative service invocation clients based on Netflix Feign implementation.
It makes writing Web service clients much easier. We can bind the Web service interface simply by creating the interface and configuring it with annotations. It has pluggable annotation support, including Feign annotations and JAX-RS annotations. It also supports pluggable encoders and decoders. Spring Cloud Feign also extends support for Spring MVC annotations and integrates Ribbon and Eureka to provide a load-balancing HTTP client implementation.
5. Service fault-tolerant protection (Hystrix service degradation, dependency isolation, circuit breaker)
Service degradation: Specify the method of service degradation by adding the @hystrixCommand annotation to the function that executes the logic. This annotation identifies which service will be lost if the service fails. Dependency isolation: If the new service is unstable or has problems, it will not affect the application of other requests.
Circuit breaker: In distributed architecture, the function of circuit breaker mode is similar. When a service unit fails (similar to short circuit), the fault monitoring of the circuit breaker (similar to blowing a fuse) directly cuts off the original main logic call.
5.1 How do I obtain triggered exceptions in Hystrix downgrade logic
Hystrix has two different ways of getting triggered exceptions
Above the implementation of the same section method of annotation, when using inheritance way through getFailedExecutionException method can obtain to trigger a downgrade exception information.
5.2 Do not use Hystrix
5.3 Using Hystrix to Resolve the Exception thrown by internal calls
The class callback method for an exception occurs, this method is to see if an exception is thrown if HystrixBadRequestException is directly after handling exceptions are thrown here not trigger circuit breakers), rather than into the callback methods
5.4 Requesting a Merger
Dependencies in microservice architectures are usually implemented through remote invocation, where the most common problems are communication consumption and connection count occupancy. In the case of high concurrency, the total communication time consumption will become less ideal as the number of communication increases. At the same time, queuing and response delays occur because of limited resources in the thread pool that depends on the service. To optimize these two issues, Hystrix provides HystrixCollapser to implement a merge of requests to reduce communication consumption and thread count.
The solution
Method 1 inheritance override method,
In the constructor above, we set the time delay property for the request aggregator, which collects requests for a single User in this time window and merges them into a single batch at the end of the time window. The following getRequestArgument method returns the given single request parameter userId, and createCommand and mapResponseToRequests are the two cores of the request consolidator: createCommand: The collapsedRequests parameter in the method preserves all requests to acquire a single User that were collected in the deferred time window. Get the parameters of these requests to organize the batch request command instance UserBatchCommand we prepared above. MapResponseToRequests: The method is executed after the batch command instance UserBatchCommand is triggered, where the batchResponse parameter holds the result of the batch request command returned by the organization in createCommand. The collapsedRequests parameter represents each of the merged requests. Here we complete the batch to single request transformation by iterating through the batch result batchResponse object and returning results for each pre-merge individual request in collapsedRequests.
Method 2 [Implementing the request aggregator with annotations],
Here we use @hystrixProperty (name=”timerDelayInMilliseconds”, value =” 100″) to set the merge window to 100 milliseconds
Note: Latency of the request command itself. If the request command that depends on the service is itself a high-latency command, then a request aggregator can be used.
This article is from: Programmer Ken, exclusive platform CSDN, SegmentFault, Jianshu, Open Source China (OSChina), Nuggets, reprint please indicate the source.