隨著需要管理服務的增多，如何編排服務，成了一個很迫切的問題。本文就介紹幾種常見的微服務編排方式：

1、Orchestration 這種方式，和BPM、ESB的思想很相似，實現方案多是同步的。 首先要有一個流程控制服務，該服務接收請求，依照業務邏輯規則，依次呼叫各個微服務，並最終完成處理邏輯。 這種方法的好處是，流程控制服務時時刻刻都知道每一筆業務究竟進行到了什麼地步，監控業務成了相對簡單的事情。 這種方法的壞處是，流程控制服務很容易控制了太多的業務邏輯，耦合度過高，變得臃腫，而各個微服務退化為單純的增刪改查，容易失去自身價值。

為了便於理解，您可以把控制服務看作BPM、ESB引擎，微服務為BPM、ESB的各種元件。

2、Choreography 這種方式，可以看作一種訊息驅動模式，或者說是訂閱釋出模式，實現方案多是非同步的。 每筆業務到來後，各個監聽改事件的服務，會主動獲取訊息，處理，並可以按需釋出自己的訊息。 這種方法的好處是，耦合度低，每個服務都可以各司其職。 這種方法的壞處是，業務流程是通過訂閱的方式來體現的，很難直接監控每筆業務的處理，因此需要增加相應的監控系統，來保證業務順暢進行。

為了便於理解，您可以把不同佇列看作不同種類的訊息，微服務看作訊息處理函式。

3、API閘道器 API閘道器，可以看作一種簡單的介面聚合/拆分的方式。 每筆業務到來後，先到達閘道器，閘道器呼叫各微服務，並最終聚合/拆分需反饋的結果。 這種方法的好處是，對外介面相對穩定，可以利用LAN的頻寬，彌補因特網的不足。 這種方法的壞處是，只適合業務邏輯較為簡單的場景，業務邏輯過於複雜時，閘道器介面耦合度及複雜度會急劇升高，變得臃腫。

其實就是一個適配閘道器，比如對於Web端，可以一個頁面同時發起幾十個請求，而對於移動端，最好是一個頁面就幾個請求 。而採用API閘道器，後面的微服務可以是相同的。