Spring Cloud底层原理与核心组件 _spring原理

题记
最初因项目要用 Cloud，匆忙到网上找资料找案例学习了一番，没有做什么归纳总结。现在回顾一下，感觉好多点在记忆中有些模糊了，此次通过文档加以巩固及学习，顺便特此感谢在之前学习中为我带来帮助的方志朋与石杉老师！
概述
Cloud是目前微服务架构领域的翘楚，这里通过业务场景表述一下：为什么需要 Cloud，它能做些什么（即：底层工作原理）？它是通过哪些核心组件来实现这些功能的（即：、、Feign、、Zuul组件）？
一、业务场景介绍
先来给大家说一个业务场景，假设咱们现在开发一个电商网站，要实现支付订单的功能，流程如下：
针对上述流程，我们需要有订单服务、库存服务、仓储服务、积分服务。整个流程的大体思路如下：
至此，整个支付订单的业务流程结束
下图这张图，清晰表明了各服务间的调用过程：
有了业务场景之后，咱们就一起来看看 Cloud微服务架构中，这几个组件如何相互协作，各自发挥的作用以及其背后的原理。
二、 Cloud核心组件：
咱们来考虑第一个问题：订单服务想要调用库存服务、仓储服务，或者是积分服务，怎么调用？
咱们来看看下面的这张图，结合图来仔细剖析一下整个流程：
如上图所示，库存服务、仓储服务、积分服务中都有一个组件，这个组件专门负责将这个服务的信息注册到中。说白了，就是告诉，自己在哪台机器上，监听着哪个端口。而是一个注册中心，里面有一个注册表，保存了各服务所在的机器和端口号
订单服务里也有一个组件，这个组件会找问一下：库存服务在哪台机器啊？监听着哪个端口啊？仓储服务呢？积分服务呢？然后就可以把这些相关信息从的注册表中拉取到自己本地缓存起来。
这时如果订单服务想要调用库存服务，不就可以找自己本地的问一下库存服务在哪台机器？监听哪个端口吗？收到响应后，紧接着就可以发送一个请求过去，调用库存服务扣减库存的那个接口！同理，如果订单服务要调用仓储服务、积分服务，也是如法炮制。
总结一下：
三、 Cloud核心组件：Feign
现在订单服务确实知道库存服务、积分服务、仓库服务在哪里了，同时也监听着哪些端口号了。但是新问题又来了：难道订单服务要自己写一大堆代码，跟其他服务建立网络连接，然后构造一个复杂的请求，接着发送请求过去，最后对返回的响应结果再写一大堆代码来处理吗？
这是上述流程翻译的代码片段，咱们一起来看看，体会一下这种绝望而无助的感受！！！
友情提示，前方高能：
看完上面那一大段代码，有没有感到后背发凉、一身冷汗？实际上你进行服务间调用时，如果每次都手写代码，代码量比上面那段要多至少几倍，所以这个事儿压根儿就不是地球人能干的。
既然如此，那怎么办呢？别急，Feign早已为我们提供好了优雅的解决方案。来看看如果用Feign的话，你的订单服务调用库存服务的代码会变成啥样？
看完上面的代码什么感觉？是不是感觉整个世界都干净了，又找到了活下去的勇气！没有底层的建立连接、构造请求、解析响应的代码，直接就是用注解定义一个接口，然后调用那个接口就可以了。人家Feign 会在底层根据你的注解，跟你指定的服务建立连接、构造请求、发起靕求、获取响应、解析响应，等等。这一系列脏活累活，人家Feign全给你干了。
那么问题来了，Feign是如何做到这么神奇的呢？很简单，Feign的一个关键机制就是使用了动态代理。咱们一起来看看下面的图，结合图来分析：