[大话云原生]-五星级酒店的服务方式

xqlu

一、服务接待中心与微服务网关

老婆最近快过生日了，我答应她去旅游住一次五星级酒店。我查看了目的地的五星级酒店的价格，决定只住一天。第一次住所以查看了一下特色服务项目：擦鞋、熨烫衣物、机场绿色通道、专车接送等等，几乎在酒店场所范围内一切可以让你懒出奇迹的项目都可以提供。没出息的时不我待，插入房卡，一键拨通前台电话要求提供衣物熨烫服务，不一会服务人员就将衣物取走了，20分钟后送了回来。真是太方便了！

二、酒店内部通信录与服务注册中心

其实我们仔细想一想，服务接待中心（微服务网关）提供面向用户的服务入口。那么酒店内部部门之间是不是只对外提供服务，不对内提供服务？显然不是的。举几个例子：

• 各种部们几乎都依赖采购部采购的物品，所以一定会和采购部申请服务用品
• 服务部给客户送餐的时候，一定需要和餐饮部进行通信
  

对于微服务架构来说也是一样的，有的微服务直接面向用户提供服务，有的微服务是为系统内部服务提供服务。所以正确的架构方式是下面这样的。

当服务之间存在调用关系，就存在一个问题：各个部门（各个服务）之间如何联系，联系方式是什么？其实就是需要建立一个酒店内部的通信录，这个通信录只在酒店内部使用。对于微服务架构而言同样需要这样一个通信录

• 在服务创建的时候，把自己的联系方式(ip、端口、服务名称)写在“通信录”上
• 在服务下线的时候，自己的联系方式从“通信录”上被划掉
  

这个服务之间的“通信录”，对于微服务架构而言就被叫做:服务注册中心。常见的微服务注册中心有nacos、eureka、zookeeper等等。

三、微服务的高可用

我们再考虑一个问题，这么大的酒店是不是只有一个服务部，只有一个采购部？当然不会，即使只有一个部门，也会分成多个小组。比如：服务部A小组负责1-3楼、服务部小组B负责4-6楼，依次类推（这其实就是一个负载均衡算法）。所以进一步完善的架构应该是下面这样的。

• 一个部门分成多个组，一旦A组忙不过来，B组完全可以过来帮忙。但在大多数情况下按照负载算法各司其职。
• 一个好汉三个棒，有事大家一起扛。这在分布式服务架构中就是一种高可用的体现。
• 不会因为一个小组的罢工导致整个服务部门瘫痪。这在服务架构中体现的是容错性和副本备份机制。
  

每个部门虽然分成了多个小组，但也会有该部门的统一的管理制度、服务标准。这个制度及服务标准统一制定，统一配置管理。对于微服务架构来说，也会有一个地方保存某一类微服务的统一配置信息，它就是服务配置管理中心。我们常见的服务配置管理中心有nacos、Spring Cloud Config等。（nacos既可以充当服务注册中心，也可以充当配置管理中心）