技術干貨 | 服務編排—Conductor

為方便理解Conductor的機制，我們不妨結合業(yè)務場景來講，如果我們要訪問應用A進行用戶信息查詢，傳統(tǒng)的處理方式如下：

傳統(tǒng)的處理方式耦合度非常高，當需要調整某個模塊時會涉及到其他模塊的接口的交互和穩(wěn)定性，從MVC到SOA，以及到現在的微服務，都在一定程度上解決模塊與模塊之間的耦合度問題。

我們接著拆分，如果接入SSO，增加認證方式，處理的方式就會變成如下形式：

這里把認證模塊獨立為一個應用對外提供服務，這就是我們耳熟能詳的SSO雛形。

接著對某些數據進行加密處理后再進行展現，我們如果不改造應用A又該怎么處理呢？當然增加API網關是可以達到相同的目的，處理方式變成如下：

API網關增加加密插件模塊，配置應用A對外提供服務，對訪問應用API的特定URL數據進行加密處理或解析相應的數據變量進行定位處理，雖然復雜些，但也能達到想要的效果，只不過一旦應用A需要加密的變量發(fā)生變化，API網關同樣存在重新調整的風險，耦合度還是太高。

現在我們再進一步場景細化，看看該如何處理。

如果要把應用A加密的數據給應用B來展現呢？或者B獲取到A的加密數據后進行處理，把處理后的數據再返回給應用A展現呢？（典型的有OCSP、證書的簽名與驗簽案例）。

當然如果非要用API網關解決也是可以的，但隨著業(yè)務的復雜度，API網關的業(yè)務邏輯耦合度會越來越高，崩潰只是時間問題。何況API網關是用來解決訪問安全問題的，并不適合處理復雜的業(yè)務邏輯問題。

那么該怎么解決類似的問題呢？

Conductor的架構為我們提供了優(yōu)雅解決這些問題的方法，它的處理模式如下：

從上圖我們可以看出Conductor是如何編排各個微服務的，由于整個機制為事件驅動模式，需要應用集成Conductor的客戶端SDK，任務分為System Task（在Conductor服務器的JVM內執(zhí)行，由Conductor管理）和Worker Task（由應用實現并在獨立的環(huán)境中運行）。

最后我們來看看Conductor的運行模式（如下圖—來自官網）

Worker作為應用端，可以用任何語言實現，這些任務通過REST API或gRPC機制與Conductor服務端通訊，以輪詢任務的方式執(zhí)行后再更新其狀態(tài)。Task Queues用于為Worker編排的任務，可以與SQS（Simple Queue Service）或發(fā)布與訂閱（Pub/Sub）機制進行交換，Conductor持久化模塊使用Dynomite（分布式的緩存系統(tǒng)）存儲狀態(tài)，以及用Elasticsearch（分布式多用戶能力的全文搜索引擎）用于索引后端，當然這些根據實際的業(yè)務需求都是可替換的。