服务治理这个词相信很多读者都听过，而其核心在于对服务调用的管理，这里就涉及到服务编制（Orchestration ）与协同（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一样存在一定的服务耦合，比如用户服务就需要感知到卡券服务及活动服务，活动服务需要感知到卡券服务，我们可以引入事件架构（见下一节）以避免这一问题。
从微服务所面对的场景分析，服务协同更为合适，这也是微服务下主流的服务治理方案。
下一节：在讨论事件驱动之前我们先思考上一节服务协同中用户注册例子描述的场景，其对应的用户服务伪代码如下：