以业务中比较常见的订单业务的下单业务逻辑为例：
- 用户创建订单后并至支付了相应金额
- 将订单状态更新为“已支付”
- 扣减相应的商品库存
- 通知商家进行发货
- 给用户增加相应的积分
1. Eureka
订单服务如何调用库存服务、仓储服务，或者积分服务？换句话说，订单服务怎么从哪里了解到库存服务、仓储服务，或者积分服务的位置信息（ip，端口），简单理解就是，A想要找B和C一起玩耍，A首先需要知道B和C的位置在哪里，才能过去找到他们。
为了解决上述问题，订单流程引入Eureka后，流程图如下图所示：
Eureka 是微服务架构中的注册中心，专门负责服务的注册与发现。如上述流程图所示，各个服务中都有一个 Eureka Client 组件，这个组件的作用就是将这个服务的信息注册到 Eureka Server中，而 Eureka Server 是一个注册中心，里面有一个注册表，保存了各服务的地址信息（所在的机器和端口号）。
即，订单服务需要调用别的业务时，只需要向Eureka Server询问所调用业务的地址信息即可。
简单来说：
- Eureka Client：负责将这个服务的信息注册到 Eureka Server 中
- Eureka Server：注册中心，里面有一个注册表，保存了各服务的地址信息（所在的机器和端口号）
2. Feign
引入Eureka后，订单服务确实知道库存服务、积分服务、仓库服务在哪里了，但是接下来的问题就是怎么调用呢？
java提供了远程网络连接的请求API，但需要设置各种请求属性，以下图为例
简单来说，就是引入Eureka后，A想要找B和C一起玩耍，A已经知道B和C的位置在哪里，但现在A想要过去，Java也提供了一套造车子的方法，所以现在的问题就是A想要找B和C，每次都需要造一个车子出来，然后开车去找B和C。
SpringCloud提供一个工具“Feign”为我们省略了这个过程，每次只需要直接开车去找B和C，而不是每次都先要造车子。
@FeignClient("B或者C的服务名")
public class A_Find_B_C{
@RequestMapping(value = "/test/{B_id}",method = HttpMethod.GET)
@ResponseBody
public Result find(@PathVariable("B_id") int id);
}
Feign Client 会在底层根据你的注解，跟你指定的服务建立连接、构造请求、发起请求、获取响应、解析响应，等等。
大致原理结合上图代码分析：
- 对某个接口（A_Find_B_C）定义了 @FeignClient 注解，Feign 就会针对这个接口创建一个动态代理
- 当调用A_Find_B_C这个接口时，本质就是会调用 Feign 创建的动态代理
- Feign的动态代理会根据你在接口上的 @RequestMapping 等注解，来动态构造出你要请求的服务的地址
- 最后针对这个地址，发起请求、解析响应
3. Ribbon
实际开发中，某个服务通常都是部署在多台机器上，如果订单服务部署了多台机器，当用户下单请求发过来时，Feign 怎么知道该请求哪台机器呢？
Ribbon 就是专门解决这个问题的。它的作用是负载均衡，会帮你在每次请求时选择一台机器，均匀的把请求分发到各个机器上
Ribbon 的负载均衡默认使用的最经典的 Round Robin 轮询算法
简单来说，就是如果订单服务对库存服务发起 10 次请求，那就先让你请求第 1 台机器、然后是第 2 台机器、第 3 台机器、第 4 台机器、最后一台机器，接着再来—个循环，第 1 台机器、第 2 台机器。。。以此类推。
此外，Ribbon 是和 Feign 以及 Eureka 紧密协作，完成工作的，具体如下：
- 首先 Ribbon 会从 Eureka Client 里获取到对应的服务注册表，也就知道了所有的服务都部署在了哪些机器上，在监听哪些端口号
- 然后 Ribbon 就可以使用默认的 Round Robin 算法，从中选择一台机器
- Feign 就会针对这台机器，构造并发起请求
4. Hystrix
以订单业务为例：订单服务在一个业务流程里需要调用三个服务。
假设订单服务线程池有 100 个线程可以处理请求，然后呢，积分服务不幸的挂了，每次订单服务调用积分服务的时候，都会卡住几秒钟，然后抛出—个超时异常。
如果系统处于高并发的场景下，大量请求涌过来的时候，订单服务的 100 个线程都会卡在请求积分服务这块，导致订单服务没有一个线程可以处理请求。
然后就会导致别人请求订单服务的时候，发现订单服务也挂了，不响应任何请求了。
上述即服务雪崩，如下图所示：
如上图，这么多服务互相调用，要是不做任何保护的话，某一个服务挂了，就会引起连锁反应，导致别的服务也挂。
比如积分服务挂了，会导致订单服务的线程全部卡在请求积分服务这里，没有一个线程可以工作，瞬间导致订单服务也挂了，别人请求订单服务全部会卡住，无法响应。
结合业务来看：支付订单的时候，只要把库存扣减了，然后通知商家发货即可。如果积分服务挂了，可以等它恢复之后，手动恢复数据
Hystrix 是隔离、熔断以及降级的一个框架
简单理解，Hystrix 会分成很多个小小的线程池，比如订单服务请求库存服务是一个线程池，请求仓储服务是一个线程池，请求积分服务是一个线程池。每个线程池里的线程就仅仅用于请求那个服务。
积分服务挂了，会咋样？当然会导致订单服务里那个用来调用积分服务的线程都卡死不能工作了，但由于订单服务调用库存服务、仓储服务的这两个线程池都是正常工作的，所以这两个服务不会受到任何影响。
熔断：
但是如果积分服务都挂了，每次调用都要去卡住几秒钟干啥呢？有意义吗？当然没有
所以我们直接对积分服务熔断不就得了，比如在 5 分钟内请求积分服务直接就返回了，不要去走网络请求卡住几秒钟，这个过程，就是所谓的熔断
降级：
每次调用积分服务，你就在数据库里记录一条消息，说给某某用户增加了多少积分，因为积分服务挂了，导致没增加成功。
这样等积分服务恢复了，你可以根据这些记录手工加一下积分。这个过程，就是所谓的降级。
4. Zuul
Zuul，也就是微服务网关。这个组件是负责网络路由的。
假设你后台部署了几百个服务，请求是直接从浏览器那儿发过来的。
打个比方：人家要请求一下库存服务，你难道还让人家记着这服务的名字叫做“xxx”？部署在 几 台机器上？就算记住这一个，你后台可有几百个服务的名称和地址呢？难不成人家请求一个，就得记住一个？
上面这种情况，压根儿是不现实的。所以一般微服务架构中都必然会设计一个网关在里面。
而且有一个网关之后，还有很多好处，比如可以做统一的降级、限流、认证授权、安全，等等。
总结：
- Eureka：各个服务启动时，Eureka Client 都会将服务注册到 Eureka Server，并且 Eureka Client 还可以反过来从 Eureka Server 拉取注册表，从而知道其他服务在哪里。
- Ribbon：服务间发起请求的时候，基于 Ribbon 做负载均衡，从一个服务的多台机器中选择一台。
- Feign：基于 Feign 的动态代理机制，根据注解和选择的机器，拼接请求 URL 地址，发起请求。
- Hystrix：发起请求是通过 Hystrix 的线程池来走的，不同的服务走不同的线程池，实现了不同服务调用的隔离，避免了服务雪崩的问题。
- Zuul：如果前端、移动端要调用后端系统，统一从 Zuul 网关进入，由 Zuul 网关转发请求给对应的服务。
