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