从生活角度解读微服务，通俗易懂

最新推荐文章于 2024-08-06 20:55:59 发布

猿猿满满

最新推荐文章于 2024-08-06 20:55:59 发布

阅读量683

点赞数

文章标签：微服务 microservices

本文链接：https://blog.csdn.net/Tom_sensen/article/details/122045994

版权

架构图是根据自己的理解，结合自己大学暑假实践绘制的微服务架构图，目前整体架构图还在慢慢改进，后期会更新图片，加入更多的自己理解的内容，如有大神路过，发现哪里有不对的，不吝指教！

一、Eureka（服务注册/发现）

在这里，董事长秘书（也有可能是其他的职能部门），充当的是Eureka（注册与发现，Eureka服务端）。在ABCD这四个厂区建立的时候，厂区的助理（Eureka客户端）会主动跑到董事长秘书那里报备一下厂区的地址、产品、产能等信息，董事长秘书会拿个小本本记一下，这就是所谓的服务注册，等有新的订单时，厂区的助理会问一下董事长秘书，iPhone1的耳机在哪里生产，这个时候董事长秘书会翻一下小本本说，在A区和D区都有生产，这就是所谓的服务发现。

二、Feign

现在知道哪个厂区生产什么产品了，每天产量也知道了，总不能让客户去口头描述说，我需要什么什么，大概需要多少多少吧，肯定是需要销售部门统计一个详细的供货单，里面包括了产品，数量，价格，收货日期等数据。这个填单子的过程就是构建请求的过程，等填完单子，销售部会根据单子的内容去找对应厂区负责人的进行生产，并且拿到最终的产品交付给客户。这个过程就对应了Feign的服务建立连接、构造请求、发起靕求、获取响应、解析响应。

三、Ribbon（负载均衡）

然后这哥们就会跑到厂区调度那里问一下，这个订单由哪个厂区负责做，总不能全都给A厂区吧，这会把A区员工给累死或者干离职的节奏啊！！

于是厂区调度会说A区和D区现在都比较闲，要不我抓阄吧，抓到谁谁做，如果你们再来订单的话，我就从这个厂区挨着顺序安排，这个时候，抓到了A，下次给D，在下次给A，在下次给D，依次类推。厂区调度就是所谓的负载均衡，抓阄就是所谓的随机算法，挨着顺序以此类推就是所谓的轮询算法。

四、Hystrix

1.熔断/降级

这里所体现的是熔断降级机制，在正常生产中，如果一个订单既有iPhone1的产品，也有iPhone3的产品，会同时交给A区和C区去做，肯定不会因为A区因为某些原因停产，C区也停产，这个时候，只需要A停产就行，C区正常生产，等到客户要的时候，我只需要把C区做完的产品交付给客户就行，说明一下A区停产的原因（相当于友好提示）这就是所谓的熔断，被熔断的服务，在多次请求无果后，可以走备用逻辑，或者返回一个友好的信息，比如在途中，C区正常生产，正常返回，而A区停产，可以向上反馈走备用逻辑（让D区生产），也可以返回一个友好的信息（比如实在不好意思啊，我们厂里停电了或者机器设备发生故障了无法生产，您稍等一下吧，走咱们去吃个饭。。。。）这就是所谓的降级

2.限流

在这里：一家手机公司总共有10个子公司，一下子涌进来10万的订单，但是我们的流水线只能承载1万/天的工作量，员工们要么累死了，要么全都吓跑了，人都没了，订单怎么做呢，公司肯定不愿看到这样的结果，就算是出于人道主义，也不会要求一天生产10万单的。那么就需要厂区经理合理的安排每天的产量了，比如每条产线一天生产1万。当这10家子公司来的时候，肯定有的子公司能够拿到等量的货，有的拿不到，那拿到货的自然就走了，没拿到的会一直来，总不能让人家干等吧，所以，在这个时候，拿不到货的，你可以跟人家说正在加班加点的做，要不去吃个饭？等等友好的说法，用到电商里面就是：10万请求，有的能够请求成功，浏览对应的页面，有的请求不成功或者超时，给一个友好提示：目前访问用户多，请稍后重试，这就是所谓的限流。