Loading... 《大话云原生》系列文章**期望用最通俗、简单的语言说明云原生生态系统内的组成及应用关系** 。此专栏的前两篇文章 * 《【大话云原生】煮饺子与docker、kubernetes之间的关系》 * 《【大话云原生】负载均衡篇-小饭馆的流量变大了》 欢迎品鉴! ### 文章目录 * * [一、服务接待中心与微服务网关](https://zimug.blog.csdn.net/article/details/123677328#_12) * [二、酒店内部通信录与服务注册中心](https://zimug.blog.csdn.net/article/details/123677328#_27) * [三、微服务的高可用](https://zimug.blog.csdn.net/article/details/123677328#_48) ## 一、服务接待中心与[微服务](https://so.csdn.net/so/search?q=%E5%BE%AE%E6%9C%8D%E5%8A%A1&spm=1001.2101.3001.7020)网关 老婆最近快过生日了,我答应她去旅游住一次五星级酒店。我查看了目的地的五星级酒店的价格,**决定只住一天** 。第一次住所以查看了一下特色服务项目:擦鞋、熨烫衣物、机场绿色通道、专车接送等等,几乎在酒店场所范围内一切可以让你懒出奇迹的项目都可以提供。没出息的时不我待,插入房卡,一键拨通前台电话要求提供衣物熨烫服务,不一会服务人员就将衣物取走了,20分钟后送了回来。真是太方便了! ![服务接待中心与微服务网关](https://img-blog.csdnimg.cn/09fec92e70a84ad99f6309c9b37160a9.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5a2X5q-N5ZOl5ZOl,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center) 五星级酒店所有的服务只有一个入口:服务接待中心。这个服务接待中心和微服务软件[架构](https://so.csdn.net/so/search?q=%E6%9E%B6%E6%9E%84&spm=1001.2101.3001.7020)中的网关功能真的是异曲同工啊 * 提供服务请求的唯一入口,也是面向用户提供服务唯一入口 * 对请求信息进行安全验证,因为我在入住时已经获得了房卡,这个房卡就像是在应用开发中的token(JWT、OAuth等登录认证方式都会发布令牌) * 有了这个房卡(令牌),我们才能通过服务接待中心请求服务项目。同样微服务网关也会进行权限验证后,才会提供API请求服务。 ## 二、酒店内部通信录与服务注册中心 其实我们仔细想一想,服务接待中心(微服务网关)提供面向用户的服务入口。那么酒店内部部门之间是不是只对外提供服务,不对内提供服务?显然不是的。举几个例子: * 各种部们几乎都依赖采购部采购的物品,所以一定会和采购部申请服务用品 * 服务部给客户送餐的时候,一定需要和餐饮部进行通信 对于微服务架构来说也是一样的,有的微服务直接面向用户提供服务,有的微服务是为系统内部服务提供服务。所以正确的架构方式是下面这样的。 ![酒店内部通信录与服务注册中心](https://img-blog.csdnimg.cn/de0a7a5177214b799ea84f4d3ab76f77.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5a2X5q-N5ZOl5ZOl,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center) 当服务之间存在调用关系,就存在一个问题:各个部门(各个服务)之间如何联系,联系方式是什么?其实就是需要建立一个酒店内部的通信录,这个通信录只在酒店内部使用。对于微服务架构而言同样需要这样一个通信录 * 在服务创建的时候,把自己的联系方式(ip、端口、服务名称)写在“通信录”上 * 在服务下线的时候,自己的联系方式从“通信录”上被划掉 这个服务之间的“通信录”,对于微服务架构而言就被叫做:**服务注册中心** 。常见的微服务注册中心有nacos、eureka、zookeeper等等。 ## 三、微服务的高可用 我们再考虑一个问题,这么大的酒店是不是只有一个服务部,只有一个采购部?当然不会,即使只有一个部门,也会分成多个小组。比如:服务部A小组负责1-3楼、服务部小组B负责4-6楼,依次类推(**这其实就是一个负载均衡算法** )。所以进一步完善的架构应该是下面这样的。 ![微服务的高可用](https://img-blog.csdnimg.cn/2676708c346c417fa010bd77da9327a3.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5a2X5q-N5ZOl5ZOl,size_20,color_FFFFFF,t_70,g_se,x_16#pic_center) * 一个部门分成多个组,一旦A组忙不过来,B组完全可以过来帮忙。但在大多数情况下按照负载算法各司其职。 * 一个好汉三个棒,有事大家一起扛。这在分布式服务架构中就是一种高可用的体现。 * 不会因为一个小组的罢工导致整个服务部门瘫痪。这在服务架构中体现的是容错性和副本备份机制。 每个部门虽然分成了多个小组,但也会有**该部门的统一的管理制度、服务标准** 。这个制度及服务标准统一制定,统一配置管理。对于微服务架构来说,也会有一个地方保存某一类微服务的统一配置信息,它就是**服务配置管理中心** 。我们常见的服务配置管理中心有nacos、Spring Cloud Config等。(nacos既可以充当服务注册中心,也可以充当配置管理中心) 最后修改:2022 年 03 月 28 日 © 允许规范转载 打赏 赞赏作者 支付宝微信 赞 0 如果觉得我的文章对你有用,请随意赞赏