Use of Basic Springboot 2.0 version Spring-cloudSpring Cloud and Spring boot version matching relationship
| spring Cloud |
spring Boot |
| finchley |
Spring boot 2.0.x compatible, spring boot 1.5.x |
| dalston and Edgware |
Spring boot 1.5.x compatible, spring boot 2.0.x |
| camden |
compatible with spring boot 1.4.x and spring boot 1.5.x |
| brixton |
compatible with spring boot 1.3.x and spring boot 1.4.x |
| Angel |
Compatible with spring Boot 1.2.x |
from spring Cloud to spring boot version matching, you can see that if your project uses a spring boot version above 2.0, you must use the Spring cloud version asFinchley.release Version This version has some differences from the previous version d, which is mainly about the simple use of the Spring Cloud F versionI also have a set of the basic use of Spring-cloud in the demo, below I come to the details of the project where the GitHub address is:Https://github.com/yihec/springCloud
First of all, the use of the following module: 1. The first is eureka-server this is a service registry, all services will be managed on this, in applicationIncrease on@EnableEurekaServer annotations, the Eureka Server can be deployed to be highly available, each of which replicates the registered service state to the other server, and then opens the URL http://localhost:1001/can see each registered service information 2.config-server Configuration Center, save each service configuration in Git, for unified Session Management configuration file, add @enableconfigserver annotations on application. 3.server-1 and Server-2 are both service producers, in addition to local services, in addition to server-1 in the use of feign calls Server-2 interface, feign encapsulated HTTP Call service method, Causes the client to invoke the method directly as if it were a local method, similar to how the remote service is exposed in Dubbo, except that Dubbo is based on a private binary protocol, and feign is essentially an HTTP client. A spring Cloud circuit breaker Hystrix is also used, the following is a detailed description of the Hystrix:<1> service demotion: When invoking an interface, you can implement a fallback method, when the request backend service has an exception, The value that can be returned by using the fallback method. The return value of the fallback method is typically the default value of the setting or from the cache .<2> breaker: When the Hystrix command requests a backend service failure quantity exceeds a certain percentage (default 50%), The circuit breaker switches to the open State (open). At this point, all requests fail directly and are not sent to the backend service. The circuit breaker remains in the open state for a period of time (default of 5 seconds) and automatically switches to the semi-open state (Half-open). This will determine the return of the next request, if the request succeeds, the circuit breaker is switched back to the closed circuit (CLOSED), or re-switch to open mode (open). The ability to self-detect and recover .<3> resource isolation: In Hystrix, resource isolation is achieved primarily through the thread pool. Usually when used, we divide multiple thread pools according to the invocation of the remote service. For example, call the command of the product service into the a thread pool and call the command of the account service into the B-thread pool. The main advantage of this is that the operating environment is isolated. This will not affect other services of the system, even if the code that invokes the service has a bug, or if it is otherwise exhausted by its own online pool. But the cost is that maintaining multiple thread pools can bring additional performance overhead to the system. If you are strict with performance and are confident that you are invoking the serviceThere is no problem with the client code, you can use Hystrix's signal mode (semaphores) to isolate the resource . in addition, when the service is more and more, you need to use the service link tracking (Spring Cloud Sleuth) in the spring When the cloud is F, you don't have to build Zipkin server yourself, just download the jar: https://dl.bintray.com/openzipkin/maven/io/zipkin/java/ Zipkin-server/then use Java-jar to start, and then open the http://localhost:9411/interface, I called the Server-2 interface in Server-1, and then click on the dependency analysis, you can see the detailed call situation 4:service-zuulRouting Gateways(Zuul) service, Zuulis an integral part of the microservices architecture, providing services such as dynamic routing, monitoring, security, and authorization. This can be done in a uniform, such as exception handling, authorization authentication and so on. In fact, with springUriThe filter is a bit like, first all the requests go through here first, and then throughfilter processing, jump to different pages5:hystrix-dashboardCircuit Breaker monitoring (Hystrix Dashboard)in the micro-service architecture, a circuit breaker model is presented to ensure the usability of the program and prevent the network from causing the error. The condition of the circuit breaker reflects the usability and robustness of a program, which is an important indicator. The Hystrix dashboard is a component that acts as a circuit breaker state, providing data monitoring and a friendly graphical interface. start the Server-1 project and enter the URLHttp://localhost:2001/hystrix, the unable to connect to Command Metric Stream will appear in version Springboot 2.0. Exception information, which needs to be configured at this timeservletAnd thenin the interface, enter:Http://localhost:2001/hystrix.stream, 2000, AA (title, Random take); Click OK. Then call the interface to enter the URLHttp://localhost:2001/HelloServer2, the following page appears, which is the prompt for the service invocation errorFinally start Server-2, interface call success above is about Spring-cloud some simple use, which have doubts or wrong place, I hope everyone message points out, thanks! Reference: 70148833/https://gitee.com/ Didispace/springcloud-learning
Use of Basic Springboot 2.0 version Spring-cloud
