随着需要管理服务的增多，如何编排服务，成了一个很迫切的问题。本文就介绍几种常见的微服务编排方式：
1、Orchestration
这种方式，和BPM、ESB的思想很相似，实现方案多是同步的。
首先要有一个流程控制服务，该服务接收请求，依照业务逻辑规则，依次调用各个微服务，并最终完成处理逻辑。
这种方法的好处是，流程控制服务时时刻刻都知道每一笔业务究竟进行到了什么地步，监控业务成了相对简单的事情。
这种方法的坏处是，流程控制服务很容易控制了太多的业务逻辑，耦合度过高，变得臃肿，而各个微服务退化为单纯的增删改查，容易失去自身价值。
为了便于理解，您可以把控制服务看作BPM、ESB引擎，微服务为BPM、ESB的各种组件。
2、Choreography
这种方式，可以看作一种消息驱动模式，或者说是订阅发布模式，实现方案多是异步的。
每笔业务到来后，各个监听改事件的服务，会主动获取消息，处理，并可以按需发布自己的消息。
这种方法的好处是，耦合度低，每个服务都可以各司其职。
这种方法的坏处是，业务流程是通过订阅的方式来体现的，很难直接监控每笔业务的处理，因此需要增加相应的监控系统，来保证业务顺畅进行。
为了便于理解，您可以把不同队列看作不同种类的消息，微服务看作消息处理函数。
3、API网关
API网关，可以看作一种简单的接口聚合/拆分的方式。
每笔业务到来后，先到达网关，网关调用各微服务，并最终聚合/拆分需反馈的结果。
这种方法的好处是，对外接口相对稳定，可以利用LAN的带宽，弥补因特网的不足。
这种方法的坏处是，只适合业务逻辑较为简单的场景，业务逻辑过于复杂时，网关接口耦合度及复杂度会急剧升高，变得臃肿。
其实就是一个适配网关，比如对于Web端，可以一个页面同时发起几十个请求，而对于移动端，最好是一个页面就几个请求
。而采用API网关，后面的微服务可以是相同的。