Spring-Cloud核心组件及底层原理( 二 ) _服务

那就一个个来盘她吧
Cloud核心组件之一：[j?’ri:k?]
那么问题来了，订单服务想要调用库存服务、仓库服务、积分服务，如何调用？
订单服务压根儿就不知道人家库存服务在哪台机器上啊!它就算想要发起一个请求，都不知道发送给谁，有心无力!
这时候，就轮到Cloud出场了。是微服务架构中的注册中心，专门负责服务的注册与发现。
咱们来看看下面的这张图，结合图来仔细剖析一下整个流程：
如上图所示，库存服务、仓储服务、积分服务中都有一个组件，这个组件专门负责将这个服务的信息注册到中。
说白了，就是告诉，自己在哪台机器上，监听着哪个端口。
而是一个注册中心，里面有一个注册表，保存了各服务所在的机器和端口号。
订单服务里也有一个组件，这个组件会找问一下：库存服务在哪台机器啊?监听着哪个端口啊?仓储服务呢?积分服务呢?
然后就可以把这些相关信息从的注册表中拉取到自己的本地缓存中来。
这时如果订单服务想要调用库存服务，不就可以找自己本地的问一下库存服务在哪台机器?监听哪个端口吗?
收到响应后，紧接着就可以发送一个请求过去，调用库存服务扣减库存的那个接口!同理，如果订单服务要调用仓储服务、积分服务，也是如法炮制。
总结一下：
：负责将这个服务的信息注册到中。
：注册中心，里面有一个注册表，保存了各个服务所在的机器和端口号。
Cloud核心组件之二：Feign
现在订单服务确实知道库存服务、积分服务、仓库服务在哪里了，同时也监听着哪些端口号了。
但是新问题又来了：难道订单服务要自己写一大堆代码，跟其他服务建立网络连接，然后构造一个复杂的请求，接着发送请求过去，最后对返回的响应结果再写一大堆代码来处理吗?
这是上述流程翻译的代码片段，咱们一起来看看，体会一下这种绝望而无助的感受!!!
友情提示，前方高能预警：
看完上面那一大段代码，有没有感到后背发凉、一身冷汗?实际上你进行服务间调用时，如果每次都手写代码，代码量比上面那段要多至少几倍，所以这个事压根儿就不是地球人能干的。
既然如此，那怎么办呢?别急，Feign 早已为我们提供好了优雅的解决方案。来看看如果用 Feign 的话，你的订单服务调用库存服务的代码会变成啥样?
看完上面的代码什么感觉?是不是感觉整个世界都干净了，又找到了活下去的勇气!
没有底层的建立连接、构造请求、解析响应的代码，直接就是用注解定义一个 Feign接口，然后调用那个接口就可以了。
人家 Feign会在底层根据你的注解，跟你指定的服务建立连接、构造请求、发起请求、获取响应、解析响应，等等。这一系列脏活累活，人家 Feign 全给你干了。
那么问题来了，Feign 是如何做到这么神奇的呢?很简单，Feign 的一个关键机制就是使用了动态代理。
咱们一起来看看上面的图，结合图来分析：
首先，如果你对某个接口定义了 @ 注解，Feign 就会针对这个接口创建一个动态代理。
接着你要是调用那个接口，本质就是会调用 Feign 创建的动态代理，这是核心中的核心。
Feign的动态代理会根据你在接口上的 @ 等注解，来动态构造出你要请求的服务的地址。
最后针对这个地址，发起请求、解析响应。
Cloud核心组件之三：
说完了 Feign，还没完。现在新的问题又来了，如果人家库存服务部署在了 5 台机器上。
如下所示：
192.168.169:9000