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

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

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

這里把認(rèn)證模塊獨立為一個應(yīng)用對外提供服務(wù)，這就是我們耳熟能詳?shù)腟SO雛形。

接著對某些數(shù)據(jù)進(jìn)行加密處理后再進(jìn)行展現(xiàn)，我們?nèi)绻桓脑鞈?yīng)用A又該怎么處理呢？當(dāng)然增加API網(wǎng)關(guān)是可以達(dá)到相同的目的，處理方式變成如下：

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

現(xiàn)在我們再進(jìn)一步場景細(xì)化，看看該如何處理。

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

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

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

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

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

最后我們來看看Conductor的運(yùn)行模式（如下圖—來自）

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