文章开始之前我给大家推荐一个人工智能学习网站首先说我之前是完全不涉及人工智能领域的但是我尽然看懂了以后老哥我就要参与人工智能了。如果你也想学习点击跳转到网站《大话云原生》系列文章期望用最通俗、简单的语言说明云原生生态系统内的组成及应用关系。此专栏的前两篇文章《【大话云原生】煮饺子与docker、kubernetes之间的关系》《【大话云原生】负载均衡篇-小饭馆的流量变大了》欢迎品鉴一、服务接待中心与微服务网关老婆最近快过生日了我答应她去旅游住一次五星级酒店。我查看了目的地的五星级酒店的价格决定只住一天。第一次住所以查看了一下特色服务项目擦鞋、熨烫衣物、机场绿色通道、专车接送等等几乎在酒店场所范围内一切可以让你懒出奇迹的项目都可以提供。没出息的时不我待插入房卡一键拨通前台电话要求提供衣物熨烫服务不一会服务人员就将衣物取走了20分钟后送了回来。真是太方便了五星级酒店所有的服务只有一个入口服务接待中心。这个服务接待中心和微服务软件架构中的网关功能真的是异曲同工啊提供服务请求的唯一入口也是面向用户提供服务唯一入口对请求信息进行安全验证因为我在入住时已经获得了房卡这个房卡就像是在应用开发中的token(JWT、OAuth等登录认证方式都会发布令牌)有了这个房卡令牌我们才能通过服务接待中心请求服务项目。同样微服务网关也会进行权限验证后才会提供API请求服务。二、酒店内部通信录与服务注册中心其实我们仔细想一想服务接待中心微服务网关提供面向用户的服务入口。那么酒店内部部门之间是不是只对外提供服务不对内提供服务显然不是的。举几个例子各种部们几乎都依赖采购部采购的物品所以一定会和采购部申请服务用品服务部给客户送餐的时候一定需要和餐饮部进行通信对于微服务架构来说也是一样的有的微服务直接面向用户提供服务有的微服务是为系统内部服务提供服务。所以正确的架构方式是下面这样的。当服务之间存在调用关系就存在一个问题各个部门各个服务之间如何联系联系方式是什么其实就是需要建立一个酒店内部的通信录这个通信录只在酒店内部使用。对于微服务架构而言同样需要这样一个通信录在服务创建的时候把自己的联系方式(ip、端口、服务名称)写在“通信录”上在服务下线的时候自己的联系方式从“通信录”上被划掉这个服务之间的“通信录”对于微服务架构而言就被叫做:服务注册中心。常见的微服务注册中心有nacos、eureka、zookeeper等等。三、微服务的高可用我们再考虑一个问题这么大的酒店是不是只有一个服务部只有一个采购部当然不会即使只有一个部门也会分成多个小组。比如服务部A小组负责1-3楼、服务部小组B负责4-6楼依次类推这其实就是一个负载均衡算法。所以进一步完善的架构应该是下面这样的。一个部门分成多个组一旦A组忙不过来B组完全可以过来帮忙。但在大多数情况下按照负载算法各司其职。一个好汉三个棒有事大家一起扛。这在分布式服务架构中就是一种高可用的体现。不会因为一个小组的罢工导致整个服务部门瘫痪。这在服务架构中体现的是容错性和副本备份机制。每个部门虽然分成了多个小组但也会有该部门的统一的管理制度、服务标准。这个制度及服务标准统一制定统一配置管理。对于微服务架构来说也会有一个地方保存某一类微服务的统一配置信息它就是服务配置管理中心。我们常见的服务配置管理中心有nacos、Spring Cloud Config等。nacos既可以充当服务注册中心也可以充当配置管理中心