Before explaining the principle , Let's take a look at one of the most classic business scenarios , Such as the development of an e-commerce website , To realize the function of payment order , The process is as follows ：
After creating an order , If the user pays for the order immediately , We need to update the order status to “ Paid ”
Deduct the corresponding inventory of goods
Inform the storage center , Make delivery
Add corresponding points to the user's purchase
Above , Application scenarios and core competitiveness of microservices ：
To reduce the coupling ： Each microservice focuses on a single function , And clearly express the service boundary through a well-defined interface . Because of its small size 、 Low complexity , Each microservice can be completely controlled by a small-scale development team , Easy to maintain high maintainability and development efficiency .
Independent deployment ： Because microservices have independent running processes , So each microservice can also be deployed independently . No compilation required when a microservice changes 、 Deploy the entire application . An application composed of microservices is equivalent to a series of parallel publishing processes , Make publishing more efficient , At the same time, reduce the risk to the production environment , Ultimately reduce application lead time .
Flexible selection ： Microservices architecture , Technology selection is decentralized . Each team can meet the needs of its own services and the current situation of industry development , Free choice of the most suitable technology stack . Because each microservice is relatively simple , So the risk of upgrading the technology stack is lower , It is possible to completely reconstruct a microservice .
Fault tolerance mechanism ： When a build fails , Under the traditional framework of single process , Faults are likely to spread in the process , Make application global unavailable . In the microservices architecture , Faults are isolated in a single service . If the design is good , Other services can be retried 、 Implementation of application level fault tolerance by stable degradation and other mechanisms .
Flexible expansion ： Single block architecture application can also realize horizontal expansion , It is to copy the whole application to different nodes . When different components of the application differ in the expansion requirements , Microservice architecture reflects its flexibility , Because each service can be expanded independently according to actual needs .
Dubbo For standard Spring Cloud Microservices ：
Background analysis ：Dubbo, Is the core framework of Alibaba's service-oriented governance , And is widely used in China's Internet companies ;Spring Cloud It's famous Spring Family products . Alibaba is a commercial company , Although there are many top-level projects open-source , But in terms of overall strategy , Still serve their own business .Spring Focus on R & D of enterprise level open source framework , It is widely used both in China and in the world , Develop common 、 Open source 、 Robust open source framework is their main business .
Activity contrast ：Dubbo Is a very good service governance framework , And in service governance 、 Grayscale Publishing 、 The ratio of traffic distribution Spring Cloud not so bad , In addition to Dangdang net on the basis of the increase of rest Support outside , It's been more than two years and there's hardly any update . Problems in use , Submitted to the GitHub Of Issue There are few replies . contrary Spring Cloud Since its development to the present , It's still developing at a high speed , from GitHub You can see the frequency of code submission and the time interval between releases , Now? Spring Cloud Upcoming release 2.0 edition , In the later stage, it will be more perfect and stable .
The platform architecture ：Dubbo Framework just focuses on governance between services , If we need to use configuration center 、 Distributed tracking needs to be integrated by itself , This is used invisibly Dubbo The difficulty will increase .Spring Cloud Almost all aspects of service governance are considered , What's more Spring Boot The general's support , It is very convenient and simple to develop .
The future of Technology ：Dubbo Small and medium-sized companies also benefit from it . After so many years of development , More advanced technologies and concepts have emerged in the Internet industry ,Dubbo A little pity .Spring Introduction Spring Boot/Cloud It's also because of many reasons .Spring The lightweight framework that was first promoted , With the continuous development, it is more and more huge , With more and more integration projects , Configuration files are getting more and more confusing , Slowly deviate from the original idea . With the development of so many years , Microservices 、 Distributed link tracking and other new technical concepts ,Spring There is an urgent need for a framework to improve the previous development model , That's why it appears Spring Boot/Cloud project , We are now visiting Spring Official website , Will find Spring Boot and Spring Cloud It has been put in the first two of the three items highlighted on the homepage , so Spring The importance of these two frameworks .Dubbo The implementation is as follows ：
Spring Cloud Realize the idea ：
principle ： In charge of service registration and discovery , That is, the name of the microservice is registered with Eureka, You can go through Eureka Find microservices , Without modifying the configuration file of the service call .
analysis ：Spring Cloud Encapsulates the Netflix company-developed Eureka Module to achieve service registration and discovery , Adopted c-s Design framework ,Eureka Server A server that serves as a service registration function , He's a service registry . And other micro services of the system , Use Eureka The client connects to Eureka Server And keep your heart beating . In this way, the maintenance personnel of the system can use Eureka Server To monitor the normal operation of each micro service in the system .Spring Cloud Some other modules （ such as Zuul） You can go through Eureka Server To discover other micro services in the system , And execute the relevant logic .
Eureka Server Provide service registration service , After each node is started , Will be in Eureka Server Register in , such Eureka Server The service registry in will store information about all available service nodes , The information of the service node can be directly seen in the interface .
Eureka Client It's a Java client , For simplification Eureka Server Interaction , The client also has a built-in 、 Use polling （round-robin） Load balancer of load algorithm . After the app starts , Will Eureka Server Send a heartbeat （ The default period is 30 second ）, To prove that the current service is available . If Eureka Server At a certain time （ Default 90 second ） No heartbeat received from client ,Eureka Server This service node will be removed from the service registry .
Eureka Server Self-protection mechanism
If in 15 Within minutes 85% None of the nodes had a normal heartbeat , that Eureka The client and registry are considered to have a network failure , Here's what happens ：
Eureka No longer removes from the registry services that should have expired because the heartbeat has not been received for a long time
Eureka Registration and query requests for new services can still be accepted , But it will not be synchronized to other nodes （ This ensures that 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 It can well cope with the situation that some nodes lose contact due to network failure , And don't like ZooKeeper That paralyzes the entire registration service .
Eureka and ZooKeeper
The famous CAP The theory points out that , A distributed system cannot be satisfied at the same time C（ Uniformity ）、A（ Usability ） and P（ Partition tolerance ）. Because partition fault tolerance in distributed systems must be guaranteed , So we have to be in A and C Weigh against .
ZooKeeper Guarantee CP
When querying the registry for a list of services , We can tolerate the registry returning registration information from a few minutes ago , But cannot accept service directly down Fall is not available . in other words , Service registries require more availability than consistency . however ZooKeeper There's a situation like this , When Master When a node loses contact with another node due to a network failure , The remaining nodes will be rerun leader The election . The problem lies in , The election leader The time is too long ,30 ~ 120s, And throughout the election ZooKeeper Clusters are not available , This caused the registration service to crash during the election . In a cloud deployment environment , Because of network problems ZooKeeper Cluster lose Master Nodes are things that happen with a high probability , Although the service will eventually be restored , But prolonged unavailability of registration due to long election times is intolerable .
Eureka Guarantee AP
Eurek Give priority to usability at design time .Eureka All nodes are equal , Several node failures will not affect the work of normal nodes , The remaining nodes can still provide registration and query services . and Eureka The client of Eureka Registration or if the connection is found to have failed , Will automatically switch to other nodes , As long as you have one Eureka still , The registration service is guaranteed to be available （ Guaranteed availability ）, The information may not be up to date （ Strong consistency is not guaranteed ）.
besides ,Eureka There is also a self-protection mechanism , See above .
Eureka It can well cope with the situation that some nodes lose contact due to network failure , And don't like ZooKeeper That paralyzes the entire registration service .
Eureka As a pure service registry, it is better than ZooKeeper more “ major ”, Because the registration service is more important is availability , We can accept that we can't achieve consistency in the short term .
Ribbon and Feign
In the microservices architecture , Business will be split into a separate service , The communication between service and service is based on HTTP RESTful Of .Spring Cloud There are two ways to call services , One is Ribbon+RestTemplate, The other is Feign.
be based on Netflix Ribbon Using polling strategy to achieve a set of client load balancing tools .
Client load balancing ： Load balancing Zuul When a gateway sends a request to an application of a service , If a service starts multiple instances , Would pass Ribbon To send a certain service instance through a certain load balancing strategy .Spring Cloud Medium Ribbon, The client will have a list of server addresses , Through load balancing algorithm before sending the request （ Such as simple polling , Random connection, etc ） Choose a server , Then visit .
Load balancing ： Used to distribute the workload across multiple servers to improve the site 、 application 、 The performance and reliability of a database or other service .
The benefits of using load balancing are obvious ： When in a cluster 1 One or more servers down When , None left down The server guarantees the continued use of the service ; Assign access pressure to servers , There is no rush hour to cause the system cpu A sharp rise in .
There are several strategies for implementing load balancing , Common are ： Random （Random）, polling （RoundRobin）, Consistent Hashing （ConsistentHash）, Hash （Hash）, weighting （Weighted）
Ribbon The default policy for is polling
Traditionally, in Java Code access RESTful service , In general use Apache Of HttpClient, But this method is too cumbersome to use .Spring Provides a simple and convenient template class to operate , This is it. RestTemplate.
Feign It's a statement http client . Use Feign Can make writing http The client is simpler , It's used to define an interface , Then add comments on it , Avoid calling the target microservice , It needs constant analysis / encapsulation json Tedious data .Spring Cloud in Feign Integrated by default Ribbon, And on and on Eureka combination , Load balancing is implemented by default .
Ribbon and Feign The difference between
Feign The goal is to write Java Http The client becomes easier
In the use of Ribbon+ RestTemplate when ,Ribbon Need to build http request , simulation http Request and use RestTemplate Send to other services , The steps are rather tedious . utilize RestTemplate Yes http Encapsulation processing of requests , To form the - Set template call method . But in actual development , Because there may be more than one call to a service , Often an interface is called in multiple places , So we usually encapsulate some client classes for each microservice to package the calls of these dependent services . therefore ,Feign On this basis, we make further encapsulation , It's up to him to help us define and implement the definition of the dependent service interface .
stay Feign Under the realization of , We just need to create an interface and use annotations to configure it （ It used to be Dao Mark... On the interface Mapper annotation , Now it's a microservice interface with a Feign Annotations can be ）, You can complete the interface binding to the service provider , Simplified use Spring Cloud Ribbon when , Development volume of auto encapsulation service calling client .
Feign Integrated Ribbon
Ribbon The load balance of client is realized by polling , And with the Ribbon The difference is ,Feign It's a declarative one Web Service client , Make writing Web Service clients become very easy , Just create an interface , Then add comments on it , Just call it like a local method , It doesn't feel like a remote method call .SpringCloud in Feign Integrated by default Ribbon, And on and on Eureka combination , Load balancing is implemented by default .
Ribbon and Nginx The difference between
Server side load balancing Nginx
Nginx All requests from the client are handed over to Nginx, from Nginx Carry out load balancing request forwarding , It belongs to server-side load balancing . Requested by Nginx Forwarding on the server side . Client load balancing Ribbon,Ribbon It's from Eureka Get the service registration information list on the registry server , Cache locally , Then implement the polling load balancing strategy locally . Both in the client to achieve load balancing .
Differences in application scenarios
Nginx It is suitable for load balancing on the server side , such as ：Tomcat,Ribbon Suitable for and in microservices RPC Remote call to realize local service load balancing , such as ：Dubbo、Spring Cloud All of them adopt local load balancing .
If there are more than ten micro service services at present , Order , goods , Users and so on , Obviously, the client doesn't have to deal with each service one by one , This requires a unified entrance , It's the service gateway .API Gateway all client requests through this gateway access background services . He can use a certain routing configuration to determine a certain URL Which service handles . And from Eureka Get registered services to forward requests .
Zuul It includes two main functions of request routing and filtering , It's a unified entrance to all kinds of services , It's also used to provide monitoring 、 to grant authorization 、 Security 、 Scheduling, etc .
Routing functions ： Responsible for forwarding external requests to specific microservice instances , It is the foundation of realizing the unified access from outside .
Filter function ： Is responsible for intervening in the processing of the request , Is to implement request verification 、 Service aggregation and other functions .
Zuul and Eureka Integration ： take Zuul Register yourself as Eureka Application under service governance , Simultaneously from Eureka Get messages from other microservices , That is to say, the access to microservices in the future is through Zuul Jump to get .
Be careful ：Zuul The service will eventually register in Eureka, Provide the agent + route + Three functions of filtering .
The core principle
Zuul The core is a series of filters, Its effect can be compared Servlet Framework of the Filter, perhaps AOP.
There is no direct communication between the filters , But through Request Context（ Context ） Data transfer .
Zuul The filter is made by Groovy It's written in , These filter files are placed Zuul Server On the specific directory below ,Zuul These directories are regularly polled , The modified filter will be loaded dynamically Zuul Server For filtering requests .
Zuul Load balancing ：Zuul Intercept the corresponding API Prefix request forwarding , Forward to the corresponding serverId On , stay Eureka The same service serverId It can correspond to multiple services , In other words, register two instances with different ports of the same service node , however serverId It's the same Zuul When doing forwarding, it will be combined with eureka-server It has the effect of load balancing .
Types of filters ：
PRE（ In front of ）： This filter is invoked before the request is routed . We can use this filter for authentication 、 Current limiting 、 Parameter calibration and adjustment, etc .
ROUTING（ route ）： This filter routes requests to microservices . This filter is used to build requests to microservices , And use Apache HttpClient or Netfilx Ribbon Request microservice .
POST（ After ）： This filter is executed after routing to the microservice . This filter can be used to add a standard to the response HTTP Header、 Collect statistics and indicators 、 Send the response from the microservice to the client 、 Log etc. .
ERROR（ error ）： This filter is executed when an error occurs at another stage .
Zuul and Nginx
Zuul Although in terms of performance and Nginx No comparison , But it also has its advantages .Zuul Authentication is provided , Dynamic routing , monitor , elastic , Security , Edge services such as load balancing , When the team is small , When there is no specific responsibility for routing development , Use Zuul When gateway is a good solution to get started quickly .
Nginx and Zuul It can be used with , Give full play to their advantages , Use Nginx As load balancing, it can achieve high concurrency request forwarding ,Zuul As a gateway .
Zuul and Ribbon Load balancing
Zuul Support Ribbon and Hystrix, Also can realize the load balance of the client . our Feign It's not about load balancing and Hystrix Yes, I don't know ？ since Zuul Has been able to achieve , Then our Feign Is it necessary ？
It can be understood in this way ：
Zuul The only interface exposed to the outside world is equivalent to routing controller Request , and Ribbonhe and Fegin Routing service Request .
Zuul Load balance the outermost request , and Ribbon and Fegin What we do is the micro services in the system service Load balancing of calls to .
Hystrix Is an open source library for dealing with latency and fault tolerance in distributed systems , In a distributed system , Many of the calls that depend on the rabbit will fail , For example, timeout. 、 Abnormal etc. ,Hystrix To ensure that in the case of a dependency problem , It doesn't cause the overall service to fail , Avoid cascading faults , To improve the flexibility of distributed systems .Hystrix Is to solve the avalanche effect .
When calling between multiple microservices , Suppose microservices A Call microservices B Micro service C, Microservices B Micro service C Call other microservices , That's what's called “ Fan out ”. If the call response time of a microservice on the fan out link is too long or unavailable , On the service A More and more system resources will be occupied by the call of , And then cause the system to crash , So-called ” Avalanche effect ”.
Fusing mechanism is a micro service link protection mechanism to deal with avalanche effect .
When a microservice of the delete link is unavailable or the response time is too long , The service will be degraded , And then fuse the call of the node's microservice , Come back quickly ” Wrong response information . When it is detected that the microservice call response of this node is normal, the call link will be restored . stay SpringCloud The fusing mechanism in the framework passes through Hystrix Realization .Hystrix Will monitor the status of calls between microservices , When a failed call reaches a certain threshold , The default is 5 Seconds 20 Call failure will start the fusing mechanism . The note of the fusing mechanism is @HystrixCommand.
The overall resources are running short , Suffer to turn off some services first , To get through the difficulties , Turn it back on .
Hystrix Monitoring and circuit breakers
We just need to add Hystrix label , It can realize the monitoring of this interface and the function of circuit breaker .
Hystrix Dashboard Monitor dashboard , Provides an interface , You can monitor the time consumed by service calls on each service .
Hystrix Turbine Monitoring aggregation
Use Hystrix monitor , We need to open the monitoring information of each service instance to view . and Turbine It can help us aggregate the monitoring information of all service instances to a local system . In this way, you don't need to open one page by one and view them one by one .
Zuul Security mechanism
Signature mechanism , In order to prevent interface data tampering and repeated calls , Add interface parameter verification mechanism ,sig The signature algorithm is MD5（appKey+appSecret+timestamp）,appKey It's assigned to the client ID,appSecret Is the key assigned to the client ,timestamp by unix Time stamp , Requested URL The effective time is 15 minute .
Token Mechanism , The user will return a access_ token, The client can access the resources after logging in , Need to be in Authorization Head use Bearer New mode token, Such as head(“Authorization”,” Bearer token”).
Hystrix Design principles
Resource isolation （ Thread pool isolation and semaphore isolation ） Mechanism ： Limit the use of resources to call distributed services , A problem with one service will not affect other service calls .
Current limiting mechanism ： The current limiting mechanism is mainly to set the highest of all types of requests in advance QPS threshold , If it is higher than the set threshold, it will directly return , No more calls to subsequent resources .
Circuit breakers ： When the failure rate reaches the threshold, degradation will be triggered automatically （ For example, due to network failure 、 The failure rate caused by overtime is really high ）, The fast failure triggered by fuse will recover quickly .
Degradation mechanism ： Over time demotion 、 When resources are insufficient （ Thread or semaphore ） Downgrade 、 Abnormal operation degradation, etc , After degradation, you can cooperate with the degradation interface to return the supporting data .
Cache support ： Provides request caching 、 Request merge implementation .
Through near real-time statistics / monitor / Alarm function , To improve the speed of fault detection .
Through near real-time properties and configuration of hot modification function , To improve the speed of troubleshooting and recovery .
Spring Cloud Config It is a configuration management solution for distributed system . Microservice means to split the business in a single application into a sub service , The granularity of each service is relatively small , So the system There will be a lot of services in . Because each service needs the necessary configuration information to run , So a centralized 、 Dynamic configuration management facilities are essential .Spring Cloud Provides ConfigServer To solve this problem , Every one of us serves from I have one with me application.yml Management of hundreds of profiles .
Inconvenient to maintain , Multiple people modify the configuration file at the same time , Constant conflict , It's hard to maintain
Configure content security and permissions , Mainly for online configuration , Generally not open to development , Only operation and maintenance have permission, so you need to isolate the configuration file , Not in the project code
Update configuration items need to be restarted , Every time you update the configuration file, you need to restart the project , Very time consuming . After using the configuration center , The configuration can be updated in real time congfig Server and Config Client combination Spring Cloud Bus To achieve automatic configuration refresh .
Configuration files are stored remotely Git（ such as GitHub,Gitee Waiting for the warehouse ）,config-server From the far end Git Pull configuration file , And save to local Git.
Local Git and config-server The interaction is bidirectional , Because when the far end Git When not accessible , From the local Git Get profile .
config-client（ That is, each micro service ）, from config-server Pull configuration file .
Config Server： Provide storage of configuration files 、 Provide the contents of the configuration file in the form of an interface .
Config Client： Get data through the interface 、 And based on this data to initialize their own applications .
Summarized below ：