编制与协同设计

服务治理这个词相信很多读者都听过，而其核心在于对服务调用的管理，这里就涉及到服务编制（[Orchestration](https://en.wikipedia.org/wiki/Orchestration_(computing)) ）与协同（Choreography ，也有称编排），两者很容易混淆，中文翻译更是词不达意（如Google翻译将Service Orchestration和Service Choreography都翻译成服务编排，百度翻译Service Choreography为服务编舞），本书使用编制与协同是为更好区别两者，为明确意图下文直接使用英文单词。

单从字面看Orchestration为管弦乐曲，由一人负责指挥与调控各个乐师，而Choreography为舞蹈，各个舞蹈者多为对等关系，没有统一的协调者。事实上也是如此，Orchestration需要类似ESB的服务总线来统一管理调度各个服务间的通讯，而Choreography更强调的是各服务自治，各自自己去调用需要的服务，相对而言更去中心化。

🔆 ESB（Enterprise Service Bus）原指企业消息总线，是SOA重要的组成，这里借用下这一概念，在微服务中，ESB可以更轻量，比如Nginx或是Zuul等。

我们可以看出Orchestration是有中心化调度服务以协调各组件通信的方式，以用户注册流程为例：

各服务间都通过ESB进行数据通信，用户注册后会向ESB发送调用活动服务的用户注册接口，ESB会将对应的请求路由给活动服务，活动服务收到请求并处理后又向ESB发送调用卡券服务生成卡券，调用积分服务生成积分，ESB路由此请求给卡券服务和积分服务。

我们可以在ESB中做集中式的权限管控、日志处理等增强操作，这是它很大的优势，但也带来了不少的问题，存在中心化的ESB，所有请求都要经由ESB，所以在性能、扩展性、灵活性上会比较差。

相反，Choreography则是去中心化的、点对点的通信的方式，还是以注册为例：

所有的请求都是直接调用对应的服务，没有ESB，这带来的直接好处是性能的提升，但它与Orchestration一样存在一定的服务耦合，比如用户服务就需要感知到卡券服务及活动服务，活动服务需要感知到卡券服务，我们可以引入事件架构（见下一节）以避免这一问题。

从微服务所面对的场景分析，服务协同更为合适，这也是微服务下主流的服务治理方案。