Spring Cloud核心组件工作原理 _服务

“
毫无疑问，Cloud 是目前微服务架构领域的翘楚，无数的书籍博客都在讲解这个技术。
不过大多数讲解还停留在对Cloud 功能使用的层面，其底层的很多原理，很多人可能并不知晓。
因此本文将通过大量的手绘图，给大家谈谈Cloud 微服务架构的底层原理。
实际上，Cloud 是一个全家桶式的技术栈，它包含了很多组件。本文先从最核心的几个组件，也就是、、Feign、、Zuul入手，来剖析其底层的工作原理。
业务场景介绍
先来给大家说一个业务场景，假设咱们现在开发一个电商网站，要实现支付订单的功能。
流程如下：
针对上述流程，我们需要有订单服务、库存服务、仓储服务、积分服务。
整个流程的大体思路如下：
至此，整个支付订单的业务流程结束。下面这张图，清晰表明了各服务间的调用过程：
好！有了业务场景之后，咱们就一起来看看Cloud 微服务架构中，这几个组件如何相互协作，各自发挥的作用以及其背后的原理。
Cloud 核心组件：
咱们来考虑第一个问题：订单服务想要调用库存服务、仓储服务，或者积分服务，怎么调用？
订单服务压根儿就不知道人家库存服务在哪台机器上啊！它就算想要发起一个请求，都不知道发送给谁，有心无力！
这时候，就轮到Cloud出场了。是微服务架构中的注册中心，专门负责服务的注册与发现。
咱们来看看下面的这张图，结合图来仔细剖析一下整个流程：
如上图所示，库存服务、仓储服务、积分服务中都有一个组件，这个组件专门负责将这个服务的信息注册到中。
说白了，就是告诉，自己在哪台机器上，监听着哪个端口。
而是一个注册中心，里面有一个注册表，保存了各服务所在的机器和端口号。
订单服务里也有一个组件，这个组件会找问一下：库存服务在哪台机器啊？监听着哪个端口啊？仓储服务呢？积分服务呢？
然后就可以把这些相关信息从的注册表中拉取到自己的本地缓存中来。
这时如果订单服务想要调用库存服务，不就可以找自己本地的问一下库存服务在哪台机器？监听哪个端口吗？
【Spring Cloud核心组件工作原理】收到响应后，紧接着就可以发送一个请求过去，调用库存服务扣减库存的那个接口！同理，如果订单服务要调用仓储服务、积分服务，也是如法炮制。
总结一下：
Cloud 核心组件：Feign
现在订单服务确实知道库存服务、积分服务、仓库服务在哪里了，同时也监听着哪些端口号了。

文章插图
但是新问题又来了：难道订单服务要自己写一大堆代码，跟其他服务建立网络连接，然后构造一个复杂的请求，接着发送请求过去，最后对返回的响应结果再写一大堆代码来处理吗？
这是上述流程翻译的代码片段，咱们一起来看看，体会一下这种绝望而无助的感受！！！
友情提示，前方高能：
看完上面那一大段代码，有没有感到后背发凉、一身冷汗？实际上你进行服务间调用时，如果每次都手写代码，代码量比上面那段要多至少几倍，所以这个事压根儿就不是地球人能干的。
既然如此，那怎么办呢？别急，Feign 早已为我们提供好了优雅的解决方案。来看看如果用 Feign 的话，你的订单服务调用库存服务的代码会变成啥样？
看完上面的代码什么感觉？是不是感觉整个世界都干净了，又找到了活下去的勇气！
没有底层的建立连接、构造请求、解析响应的代码，直接就是用注解定义一个 Feign接口，然后调用那个接口就可以了。