一、业务场景介绍先给大家讲业务场景。 假设我们现在要开发电子商务网站，实现支付订单的功能，流程如下。
1 )如果用户在创建订单后立即支付此订单，则必须将订单状态更新为“已支付”
2 )抵扣相应商品库存
3 )通知仓储中心，发货
4 )为用户此次购物增加相应积分
针对上述流程，需要订单服务、库存服务、仓库服务、积分服务。整个流程的大体思路如下
1 )用户对一个订单支付完毕后，就去寻找订单服务，更新订单状况
2 )订单服务调用库存服务，完成相应功能
3 )订单服务器调用仓库服务器，完成相应的功能
4 )点餐服务调用积分服务，完成相应功能
至此，支付订单的整个业务流程结束
下图清楚地说明了每个服务之间的调用过程。
是的！ 一旦有了业务场景，我们来看看Spring Cloud微服务架构中这些组件如何协作，各自的作用及其背后的原理。
二、Spring Cloud核心组件： Eureka考虑一下第一个问题。 订单服务如何调用库存服务、仓储服务或积分服务？
订餐服务不知道人的库存服务在哪个机器上哦！ 他想提出一个要求，却不知道发给谁，内心无能！
这个时候，轮到Spring Cloud Eureka出场了。 Eureka是微服务体系结构的注册中心，专门用于注册和发现服务。
请看下图。 让我们结合图详细分析一下整个过程。
如上图所示，库存服务、仓库服务和点服务都有一个Eureka Client组件，该组件专门用于向Eureka Server注册此服务的信息。 简单地说，就是告诉Eureka Server自己在哪个计算机上监听的端口。 以及Eureka Server是一个注册中心，里面有一个注册表，保存了各服务所在的机器和端口号。
订购服务也有eureka客户端组件。 这个Eureka Client组件对Eureka Server说：“库存服务是哪台机器？ 你在监听哪个端口？ 仓库服务呢？ 积分服务呢？把这些相关信息从Eureka Server的注册表中拉取到自己本地缓存起来。
此时，如果订购服务想叫库存服务，何不向自己当地的eureka客户端询问库存服务是哪台机器？ 要监听哪个端口？ 收到响应后，可以立即发送请求，调用库存服务调用抵扣库存界面！ 同样，订单服务器调用仓库服务器、积分服务器时，也类似于炮制。
总结：
eureka客户端：负责向Eureka Server注册此服务的信息
eureka服务器：注册中心。 包含注册表，其中包含每个服务所在的计算机和端口号
三. Spring Cloud核心组件： Feign目前在订单服务确实知道库存服务、积分服务、仓储服务在哪里的同时，监听到了任何端口号。 但是，发生了新的问题。 订购服务需要自己写很多代码，与其他服务建立网络连接，制造复杂的请求，然后发送请求，对最后返回的响应结果写很多代码进行处理吗？
这是在上述过程中翻译的代码片段。 一起来看看，体验一下这种绝望无助的感觉吧。
友情提示，前方高能：
读了上面的二维码，有没有觉得后背发凉出冷汗？ 事实上，当你进行服务间调用时，如果每次都手写代码，代码量至少比上面一段多数倍，所以这件事不是地球人能做到的。
那么，我们该怎么办呢？ 不要着急。 Feign已经为我们提供了优雅的解决方案。 如果使用Feign，你的订单服务调用库存服务的代码会怎么样？
看完上面的代码是什么感觉？ 你不觉得世界变干净了，又找到了活下去的勇气吗！ 没有用于建立底层连接、生成请求和分析响应的代码。 您只需直接在注释中定义FeignClient接口并调用该接口即可。 人的Feign Client根据你的评论，建立与你指定的服务的连接，构建请求，发起电话请求，获取响应，分析响应。 这一连串的烂摊子，人家Feign都给我做了。
问题是，Feign是如何做到这么神奇的呢？很简单，Feign的一个关键机制就是使用了动态代理一起看下图，结合图进行分析吧：
1 )首先，当您为某个接口定义@FeignClient注释时，Feign会为该接口创建一个动态代理
2 )下次调用该接口时，本质上是调用Feign创建的动态代理。 这是核心的中心
3 ) Feign的动态代理根据界面上的@RequestMapping等评论，动态构建所要求服务的地址
4 )最后对该地址发送请求，分析响应
总结：
Feign是一个更容易使用的HTTP客户端，采用接口方式。 您只需创建一个接口并在其中添加注释即可，将需要调用的其他服务的方法定义为抽象方法即可，而无需自己构建HTTP
请求。然后就像是调用自身工程的方法调用，而感觉不到是调用远程方法，使得编写 客户端变得非常容易。类似于 mybatis 的 @Mapper注解 。
四、Spring Cloud核心组件：Ribbon说完了Feign，还没完。现在新的问题又来了，如果人家库存服务部署在了5台机器上，如下所示：
192.168.169:9000
192.168.170:9000
192.168.171:9000
192.168.172:9000
192.168.173:9000
这下麻烦了！人家Feign怎么知道该请求哪台机器呢？
这时Spring Cloud Ribbon就派上用场了。Ribbon就是专门解决这个问题的。它的作用是负载均衡，会帮你在每次请求时选择一台机器，均匀的把请求分发到各个机器上。
Ribbon的负载均衡默认使用的最经典的Round Robin轮询算法。这是啥？简单来说，就是如果订单服务对库存服务发起10次请求，那就先让你请求第1台机器、然后是第2台机器、第3台机器、第4台机器、第5台机器，接着再来—个循环，第1台机器、第2台机器。。。以此类推。
此外，Ribbon是和Feign以及Eureka紧密协作，完成工作的，具体如下：
1）首先Ribbon会从 Eureka Client里获取到对应的服务注册表，也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口号。
2）然后Ribbon就可以使用默认的Round Robin算法，从中选择一台机器
Feign就会针对这台机器，构造并发起请求。
对上述整个过程，再来一张图，帮助大家更深刻的理解：
在微服务架构里，一个系统会有很多的服务。以本文的业务场景为例：订单服务在一个业务流程里需要调用三个服务。现在假设订单服务自己最多只有100个线程可以处理请求，然后呢，积分服务不幸的挂了，每次订单服务调用积分服务的时候，都会卡住几秒钟，然后抛出—个超时异常。
咱们一起来分析一下，这样会导致什么问题？
如果系统处于高并发的场景下，大量请求涌过来的时候，订单服务的100个线程都会卡在请求积分服务这块。导致订单服务没有一个线程可以处理请求
然后就会导致别人请求订单服务的时候，发现订单服务也挂了，不响应任何请求了
上面这个，就是微服务架构中恐怖的服务雪崩问题，
如下图所示：
如上图，这么多服务互相调用，要是不做任何保护的话，某一个服务挂了，就会引起连锁反应，导致别的服务也挂。比如积分服务挂了，会导致订单服务的线程全部卡在请求积分服务这里，没有一个线程可以工作，瞬间导致订单服务也挂了，别人请求订单服务全部会卡住，无法响应。
但是我们思考一下，就算积分服务挂了，订单服务也可以不用挂啊！为什么？
我们结合业务来看：支付订单的时候，只要把库存扣减了，然后通知仓库发货就OK了
如果积分服务挂了，大不了等他恢复之后，慢慢人肉手工恢复数据！为啥一定要因为一个积分服务挂了，就直接导致订单服务也挂了呢？不可以接受！
现在问题分析完了，如何解决？
这时就轮到Hystrix闪亮登场了。Hystrix是隔离、熔断以及降级的一个框架。啥意思呢？说白了，Hystrix会搞很多个小小的线程池，比如订单服务请求库存服务是一个线程池，请求仓储服务是一个线程池，请求积分服务是一个线程池。每个线程池里的线程就仅仅用于请求那个服务。
打个比方：现在很不幸，积分服务挂了，会咋样？
当然会导致订单服务里那个用来调用积分服务的线程都卡死不能工作了啊！但由于订单服务调用库存服务、仓储服务的这两个线程池都是正常工作的，所以这两个服务不会受到任何影响。
这个时候如果别人请求订单服务，订单服务还是可以正常调用库存服务扣减库存，调用仓储服务通知发货。只不过调用积分服务的时候，每次都会报错。但是如果积分服务都挂了，每次调用都要去卡住几秒钟干啥呢？有意义吗？当然没有！所以我们直接对积分服务熔断不就得了，比如在5分钟内请求积分服务直接就返回了，不要去走网络请求卡住几秒钟，这个过程，就是所谓的熔断！
那人家又说，兄弟，积分服务挂了你就熔断，好歹你干点儿什么啊！别啥都不干就直接返回啊？没问题，咱们就来个降级：每次调用积分服务，你就在数据库里记录一条消息，说给某某用户增加了多少积分，因为积分服务挂了，导致没增加成功！这样等积分服务恢复了，你可以根据这些记录手工加一下积分。这个过程，就是所谓的降级。
为帮助大家更直观的理解，接下来用一张图，梳理一下Hystrix隔离、熔断和降级的全流程：
说完了Hystrix，接着给大家说说最后一个组件：Zuul，也就是微服务网关。这个组件是负责网络路由的。不懂网络路由？行，那我给你说说，如果没有Zuul的日常工作会怎样？
假设你后台部署了几百个服务，现在有个前端兄弟，人家请求是直接从浏览器那儿发过来的。打个比方：人家要请求一下库存服务，你难道还让人家记着这服务的名字叫做inventory-service？部署在5台机器上？就算人家肯记住这一个，你后台可有几百个服务的名称和地址呢？难不成人家请求一个，就得记住一个？你要这样玩儿，那真是友谊的小船，说翻就翻！
上面这种情况，压根儿是不现实的。所以一般微服务架构中都必然会设计一个网关优秀的雪糕，像android、ios、pc前端、微信小程序、H5等等，不用去关心后端有几百个服务，就知道有一个网关，所有请求都往网关走，网关会根据请求中的一些特征，将请求转发给后端的各个服务。
而且有一个网关之后，还有很多好处，比如可以做统一的降级、限流、认证授权、安全等等。
七、总结：最后再来总结一下，上述几个Spring Cloud核心组件，在微服务架构中，分别xjwl：
Eureka：各个服务启动时，Eureka Client都会将服务注册到Eureka Server，并且Eureka Client还可以反过来从Eureka Server拉取注册表，从而知道其他服务在哪里
Ribbon：服务间发起请求的时候，基于Ribbon做负载均衡，从一个服务的多台机器中选择一台
Feign：基于Feign的动态代理机制，根据注解和选择的机器，拼接请求URL地址，发起请求
Hystrix：发起请求是通过Hystrix的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题
Zuul：如果前端、移动端要调用后端系统，统一从Zuul网关进入，由Zuul网关转发请求给对应的服务
以上就是我们通过一个电商业务场景，阐述了Spring Cloud微服务架构几个核心组件的底层原理。
文字总结还不够直观？没问题！我们将Spring Cloud的5个核心组件通过一张图串联起来，再来直观的感受一下其底层的架构原理：
最好能实现动手敲上一套，后面你会发现自己对SpringCould的理解远超其他人。专栏地址是：史上最简单的 SpringCloud 教程 | 终章
一个分布式系统最多只能同时满足一致性（Consistency）、可用性（Availability）和分区容错性（Partition tolerance）这三项中的两项。
C 一致性即更新操作成功并返回客户端完成后，所有节点在同一时间的数据完全一致。
A 可用性服务一直可用，而且是正常响应时间。
P 分区容错性即分布式系统在遇到某节点或网络分区故障的时候，仍然能够对外提供满足一致性和可用性的服务。
对于多数大型互联网应用的场景，一般保证满足 P 和 A，舍弃 C（一致性无法保证，退而求其次保证最终一致性）。虽然某些地方会影响客户体验，但没达到造成用户流失的严重程度。如原来同步架构的时候如果没有库存，就马上告诉客户库存不足无法下单。但在微服务框架下订单和库存可能是两个微服务对应两个数据库，用户下单时订单服务是立即生成的，很可能过了一会系统通知你订单被取消掉（最终一致性）。就像抢购“小米手机”一样，几十万人在排队，排了很久告诉你没货了，明天再来吧。
对于涉及到钱财这样不能有一丝让步的场景，C 必须保证。网络发生故障宁可停止服务，这是保证 CA，舍弃 P。
还有一种是保证 CP，舍弃 A。例如网络故障事只读不写。
BASEBASE 是 Basically Available(基本可用)、Soft state(软状态)和 Eventually consistent (最终一致性)三个短语的缩写。是对 CAP 中 AP 的一个扩展
基本可用：分布式系统在出现故障时，允许损失部分可用功能，保证核心功能可用。
软状态：允许系统中存在中间状态，这个状态不影响系统可用性，这里指的是 CAP 中的不一致。
最终一致：最终一致是指经过一段时间后，所有节点数据都将会达到一致。
BASE 解决了 CAP 中理论没有网络延迟，在 BASE 中用软状态和最终一致，保证了延迟后的一致性。BASE 和 ACID 是相反的，它完全不同于 ACID 的强一致性模型，而是通过牺牲强一致性来获得可用性，并允许数据在一段时间内是不一致的，但最终达到一致状态。
原文链接
https://blog.csdn.net/java_wxid/article/details/106901367