理解服务治理中的服务编制（Orchestration）和服务协同（Choreography）的区别对于建立有效的服务体系结构至关重要。下面对这两个概念进行解释：
服务编制（Service Orchestration）：
在服务编制中，有一个中心化的控制器（通常是一个服务或调度引擎）负责协调和管理整个服务流程。该控制器指导和执行服务调用的顺序和条件，决定服务之间的交互方式。服务的执行顺序、条件和数据流都由编制引擎进行管理。这种方式类似于一个指挥官在军队中指挥士兵的行动，是一种集中式的控制模式。服务协同（Service Choreography）：
在服务协同中，服务之间通过相互协作来完成整个业务流程，没有一个中心化的控制点。每个服务都知道它何时以及如何响应其他服务的请求，而无需中心控制器的干预。服务之间通过定义良好的接口和协议来实现协同，彼此之间是平等的。这种方式类似于舞蹈中的舞者，它们相互协作而无需中心指挥。
🔆 ESB（Enterprise Service Bus）原指企业消息总线，是SOA重要的组成，这里借用下这一概念，在微服务中，ESB可以更轻量，比如Nginx或是Zuul等。
我们可以看出Orchestration编制是有中心化调度服务以协调各组件通信的方式，以用户注册流程为例：
各服务间都通过ESB进行数据通信，用户注册后会向ESB发送调用活动服务的用户注册接口，ESB会将对应的请求路由给活动服务，活动服务收到请求并处理后又向ESB发送调用卡券服务生成卡券，调用积分服务生成积分，ESB路由此请求给卡券服务和积分服务。
ESB模式的优势包括：
- 解耦合： 各个服务之间通过ESB进行通信，彼此之间不需要直接知道对方的实现细节，实现了解耦合。
- 可扩展性： 当需要添加或修改某个服务时，只需在ESB上进行配置，而不需要修改所有服务的代码。
ESB模式的问题包括：
- 单点故障： 如果ESB成为单点故障，整个系统可能会受到影响。在设计中需要考虑高可用性的架构。
- 性能： ESB的性能可能受到系统规模和负载的影响。在高负载场景下，可能需要考虑性能优化和合理的扩展策略。
相反，Choreography编排协同则是去中心化的、点对点的通信的方式，还是以注册为例：
所有的请求都是直接调用对应的服务，没有ESB，这带来的直接好处是性能的提升，但它与Orchestration一样存在一定的服务耦合，比如用户服务就需要感知到卡券服务及活动服务，活动服务需要感知到卡券服务，我们可以引入事件架构（见下一篇）以避免这一问题。
从微服务所面对的场景分析，服务协同更为合适，这也是微服务下主流的服务治理方案
