平臺化三部曲之三流程編排-平臺化是舞臺，流程編排就是導演一場戲

在上兩篇ATA中，第一篇討論了平臺的擴充套件性(《從Eclipse平臺看交易平臺化》)，強調微核心和擴充套件機制實現,第二篇討論平臺的模組化開發(《Google Guice平臺模組化開發的果汁》)，強調業務隔離，鬆耦合。這這第三篇ATA中，想分享下平臺化中另一個重要方面，平臺的服務流程編排 （備註：本文以下提到交易系統，只是舉例，可以擴散為業務平臺系統）

像本文標題一樣，我們想象下，在舞臺上，有各種角色，導演根據劇本的設計的場景，讓這些角色，在他的編排下，完成不同劇情。

這和我們的業務平臺有很多共通之處。在我們的交易業務系統中，也有很多“角色”，比如各種中介軟體服務，各種業務系統，我們設計的各種業務，簡單類比來說就是編排這些“角色”一起完成一個特定的“劇情”。產品經理就是編劇，我們平臺化需要實現了一個“智慧導演“，能快速響應產品經理的這個編劇的設計，編排出不同的業務場景流程。 而且我們的業務舞臺裡，劇情不同，但是角色都是基本一樣的，其實就是用同樣的演員拍不同的劇情。 每一集的生產只是需要導演實現不同的編排，而且我們希望實現業務的時間和成本儘可能的低。大家都喜歡看美劇，美劇的製作可以說是流水化工業生產，編劇、導演、演員、 攝像、剪輯師等各工種分工合作，環環相扣，高效率生產,而且大家會注意到美劇的導演不重要，經常一個劇每集可能由不同的導演來導演。這是因為美劇的運作機制本身就完成了大部分導演的功能，這個機制裡有很多的規範和套路，從而不依賴導演的個人能力就從而可以快速完成各種劇集的製作，導演只需要按照規範套路來導演。

如果我們的業務系統有一套類似美劇製作體系裡的“導演”機制，我們的業務系統開發就可以真正圍繞業務本身快速構建，流水化生產了。

這個”導演”機制的功能換成我們的技術術語，就是”流程編排”的能力,是在業務系統驅動各種服務按照不同的流程完成某項業務需求。

“導演”的KPI

假設在平臺中我們要實現一個“導演”機制，那對這個導演的KPI應該怎麼設定呢，導演需要什麼素質和功能才是業務發展需求急需的。

導演的KPI：

1. 一個好的“導演”應該能很好的協調舞臺上的各種角色，指揮他們做正確的事情。
2. 能夠根據劇情設計，將各種角色資源按一定的流程完成各自的任務。

第一個KPI反應導演和不同的角色，不同的資源打交道，對資源進行呼叫的能力。

第二個KPI考核需要導演能按需而變，將複雜劇情分解，流水線一樣的完成各種資源的調配，生產新的劇集。

導演能做好1.2 也離不開配套機制，每個角色分工都各司其責，能夠響應請求完成任務。

在我們平臺化中，第一個KPI對應的就是平臺能夠對不同的系統，包括中介軟體，服務，業務系統呼叫的能力，在交易這種複雜系統中，平臺需要把各種呼叫隱藏在平臺內部，對外提供一個簡單一致的整合模型，從而可以保證平臺能和眾多其他系統一致溝通，簡化各種異構系統帶來的複雜性，這樣我們就可以說平臺實現的導演具有很好的協調能力。

第二個KPI對應的是平臺具有快速響應業務需求，快速調整業務處理流程，用流程抽象具體的業務處理過程，完成業務請求。

那麼我們來設計這個“導演機制”的實現，我們用“整合平臺”來實現這個“導演機制”。

整合平臺的背景

對於交易這樣的複雜業務系統，資料龐大並不是平臺增長的唯一方式。業務流程也可能在複雜性方面不斷增長。交易處理的資訊可能會是各種數量的並且任意數量組合的傳輸型別、過濾、增強以及路由等。

複雜的問題會在任何領域都出現，但是解決它們的總體策略通常是一樣的：分而治之。我們會將問題拆分為更容易解決的子問題。然後這些方案再按照與分解相反的方式組合在一起形成整體的解決方案。
通過觀察會發現這樣的問題是經常發生的；藉助於經驗，能夠識別出最優的方案。我所討論的就是模式

這些模式被命名為企業整合模式(Enterprise Integration patterns), 由Gregor Hohpe和Bobby Woolf進行了分類和總結，他對我們進行復雜業務的解決方案提供裡整套的總結，為我們對複雜業務處理流程進行最優化實踐指導。

在這裡我們花點時間多瞭解下企業整合模式(Enterprise Integration patterns)，這些企業整合模式就是我們“導演機制”裡需要的套路，通過這些模式，我們可以針對複雜問題進行解耦組合，快速應對需求的變化。

企業整合模式

首先大家可以通過EIP的網站瞭解詳細資訊，EIPs對複雜業務系統開發有深遠影響，IBM，TIBCO等中介軟體提供者利用EIP商業實現為解決複雜業務開發提供了整套解決方案，在金融等領域取得很大成功。

EIP本質上可以非常簡單，通常表現為基本的操作如傳輸或過濾。最為重要的是，它們可以組合起來形成複雜的解決方案。這種組合本身也可以是模式。這種能力來源於所有的EAI模式具有相同的“介面（interface）”：資訊可以進出模式。這樣，模式就可以組合起來，這是通過接受一個模式的輸出，並將這個輸出作為另一個模組的輸入來實現的。熟悉linux命令的人對linux的命令管道的功能便利強大印象深刻，EIP很類似linux的pipe，但是他更強大。

首先，EIP模式背後的設計思想是基於鬆耦合，面向服務的架構，資料包裝成訊息在傳遞，以訊息驅動的方式協調各個服務，從而達到以標準化方式實現協議和服務。

EIP覆蓋以下的一些內容：

1. Messaging system
   
2. Messaging channel
   
3. Messaging custruction
   
4. Messaging routing
   
5. Messaging transformation
   
6. Messaging endpoint
   
7. System Management
   

廣義地來說，這說明覆雜業務問題就是模式的組合問題。這意味著解決問題，即便是很複雜的問題，將會簡化成尋找滿足需求的組合。實現自己的模式當前也會有大量的複雜性，但是這已經進行了隔離並且是可管理的。

上面的分析總結來說，就是將複雜性進行隔離和管理。通過EIPs模式，複雜的交易相關業務的實現的重點就是理解問題並識別出正確的模式，這有利於提高整體解決方案的質量。

企業整合模式或者EIPS對我們是有幫助的，因為它不僅給我們提供了問題的解決方案，並且也幫我們定義了我們所交流問題的本身。有了模式問題交流起來更容易。使用模式語言比描述需要解決的問題容易的多，就好像學習漢語比學習甲骨文要容易的多。

當我們用EIP來解決交易中涉及的複雜常見時，我們也將有一個更方便的語言在業務方，產品經理，開發團隊中溝通。

然後我們就可以在對交易，業務的各種功能進行解耦並通過模組化方式接入平臺基礎上，利用這些功能模組形成了交易流程中各個功能節點，將他們連線起來連起來，完成真正的複雜的業務流程。

整合平臺設計目標

當平臺的功能已外掛，模組的形式接入平臺後，我們需要一組模組一起完成一些複雜的業務功能。比如在交易系統中，下單這樣一個流程，就可能設計到多個模組提供的功能和服務。如何方便對這些流程以及服務進行編排是體現平臺能力的重要標誌。當一些業務需求需要對流程進行少量修改或者重新定製某些服務，而大部分流程功能保持不變是，平臺提供簡單方便的編排能力就可以滿足對業務的快速響應。

首先在這樣的流程體系中，一個複雜的業務流程需要和多種外部業務系統，中介軟體，資料庫系統,連線，呼叫本地服務或者遠端服務才能完成，如果我們希望平臺能夠以簡潔的方式對流程進行編排，平臺必須達到以下要求：

1. 簡化外部系統的連線呼叫方式，消除不同系統呼叫方式的差異，將系統的呼叫細節由平臺完成，對呼叫者透明，平臺提供一致的呼叫模式，同時該呼叫方式簡單有效。
2. 同時，對流程的描述提供DSL語言支援，簡化流程的設計，方便通過視覺化流程設計工具提高開發者流程設計能力.
3. 提供對流程的執行監控，實時追蹤業務執行情況。
4. 對流程的生命週期進行管理，可控制流程的啟動停止。
5. 高效的流程執行引擎，能針對流程進行計算能力調配控制。
6. 完善的流程錯誤處理報警機制。

目前交易系統涉及的業務和流程也變得越來越複雜，正向交易流程，逆向交易流程，生活服務預約流程等等。設計到多個交易系統之間的互動，一個訂單從生成到完成，需要多個系統合作，不同型別的業務訂單設計的流程也很不相同，整合模式為我們解決這些業務的複雜性提供了很好的問題解決方案，讓我們對於業務和流程能更清晰的管理。

整合平臺設計的目的就是引入企業整合模式解決方案，為平臺提供對複雜業務的流程的隔離和編排。

整合平臺的實現

企業整合模式的實現有很多，大型中介軟體廠商如TIBCO，IBM都有自己企業整合模式實現，在開源領域，Spring Integration， Apache Camel都是其中的佼佼者。 這兩者對比中，本人更傾向Apache Camel，更成熟，有眾多的應用，活躍的社群和完備的官方文件支援

Camel是什麼

Apache Camel是Apache基金會下的一個開源專案,它是一個基於規則路由和處理的引擎，提供企業整合模式的Java物件的實現，通過應用程式介面 或稱為陳述式的Java領域特定語言(DSL)來配置路由和處理的規則。其核心的思想就是從一個from源頭得到資料,通過processor處理,再發 到一個to目的的.

Camel框架的核心是一個路由引擎，它允許你定義自己的路由規則，決定接受哪些訊息，做出決定如何處理，傳送這些訊息給其他目標。Camel用這種整合語言允許你定義複雜的路由規則。

Camel的基本原則之一是不會假設任何你需要處理的資料，這是很重要的一點，因為它給你們開發者一個整合任何系統的一個機會，不需要轉換你的資料為另外的一種公認格式。

Camel 提供了高水平的抽象，它允許你根據相同的api協議或者系統的資料型別整合各種各樣的系統。Camel的元件提供了特殊實現的介面api，其目的是給不同的協議和資料型別服務。Camel打破了傳統模式，它支援190多種不同的協議和資料型別，它的擴充套件性和模組性允許你實現你自己專有協議的無縫外掛。這些體系結構的選擇淘汰沒有必要的轉換，從而使camel更加的高效，易學。結果證明，camel是適合嵌入到其他專案中的，因為它提供了充足的處理能力。其他開源的專案，例如Apache ServiceMix和ActiveMQ已經使用camel作為企業整合的一種處理方式。

我們應該提問camel不是什麼，camel不是ESB，有些人稱camel是個輕量級的ESB，因為它支援路由、事務、監控、編制等。Camel 沒有一個容器或者一個可靠的訊息匯流排，但是它可以依賴例如開源的ESB或者前面提到的ServiceMix，由於以上原因，我們更喜歡把camel稱作超越一個ESB的整合框架。

Apache Camel的基本概念

• 端點(Endpoint)

  是Camel中的一個基本概念，Endpoint作為Camel系統中一個通道的端點，可以傳送或者接受訊息。在Camel中Endpoint使用URI來配置。在執行時Camel通過URI來查詢端點。端點的功能強大、全面而且又可維護。
  

• 元件(Component)

  Component是一些Endpoints URI的集合。他們通過Schema來連線（例如file:,jms:），而且作為一個endpoint的工廠。
  

• 路由(Route)

  顧名思義，Route，就是路由，它定義了Message如何在一個系統中傳輸的真實路徑或者通道。路由引擎自身並不暴露給開發者，但是開發者可以 自己定義路由，並且需要信任引擎可以完成複雜的傳輸工作。每個路由都有一個唯一的識別符號，用來記錄日誌、除錯、監控，以及啟動或者停止路由。路由也有一個輸入的Message，因此他們也有效的連結到一個輸入端點。路由定義了一種領域特有的語言（DSL）。Camel提供了java、scala和基於XM的Route-DSL, 路由可以使用過濾器、多播、接收列表、並行處理來定義，從而變得非常靈活。

• 處理器(Processor)

  Processor是router中的一個組成元素，用來訊息轉換和處理。
  

Apache Camel的主要功能

• 路由引擎

  路由引擎是camel的核心功能。路由引擎基於路由配置有選擇的對訊息進行路由。

• 企業整合模式

  針對複雜業務處理，Gregor Hohpe 和Bobby Woolf 發現了很多問題，並給出了響應的解決方案。他們編寫一本《Enterprise Integration Patterns》書，這本書對那些專業整合的人來說是必讀的書。接下來，它將幫助你理解又快又容易地理解camel。。

• Domain-speclfic language（DSL）

  Camel的domain-specific language（DSL） 對整合領域來說是一個主要的貢獻。Camel提供了多種DSLs。例如java、Scala，Groovy，它還允許以XML特定方式的路由規則。

• 可擴充元件庫

  Camle提供了超過190個元件的擴充庫。這些元件使camel用APIs連線傳送和理解資料的格式。

• 模組化、元件式體系結構

  Camel 有一個模組化體系結構，它允許任何元件載入到camel中對camel的功能進行擴充套件開發。

• 資料型別自動轉換

  Camel已經嵌入了150多種自動轉換的機制。你不在需要配置型別轉換規則，例如把byte arrays 轉換為 Strings。如果你需要一種camel沒有的轉換型別，你可以自己去建立屬於自己的Converter。

• 輕量核心

  Camel核心被認為是輕量級的，總共自由包加起來大約也就1.6MB，它只依賴Apache Commons Logging，資源的通用管理。這樣使camel更容易在你喜歡的任何地方嵌入或者部署。例如在標準的應用、web應用、spring應用、J2EE應用、JBI容器、OSGI bundle、java web start或者Google Appengine。Camel沒有被設計成一個server或者ESB，取而代之的是可以嵌入到你選擇的任何平臺中。

• 測試驅動

  Camel提供了測試工具箱，使測試你自己的camel應用更容易。這些測試工具在測試camel本身中廣泛應用。例如他們可以幫助你虛擬真正的endpoints。
  

在Camel提供的功能基礎上，我們可以打造一個基於阿里技術體系和業務系統的整合平臺，為複雜業務提供更高效的解決方案。

期望的整合平臺功能

目前阿里內部有眾多系統為整個交易相關提供各種服務，整個交易就是講這些系統聯合起來，

提供統一的整合模型

當整合平臺就緒時，我們期望他能夠將各個業務系統通過整合方式連線起來，作為平臺的能力擴充套件對外輸出。從這個平臺出發，業務開發者將不需要直接面對各種複雜的業務系統，然後開發對這些系統的服務呼叫程式碼，平臺會完成這些基礎部分，然後提供一個抽象的一致的訪問形式，完全消除系統之間的差異。
所有的外部系統成為了平臺的服務。平臺對這些整合的系統提供了更簡化的訪問形式，方便流程指令碼的設計編寫。比如利用Camel的component功能，實現對業務系統，中介軟體系統的整合封裝，從而使每個服務，每個業務都可以以URI定址的方式完成呼叫，舉例來說：對TOC增加超時可能就是將資料傳給如下的地址：
.to(“toc://insertTimeout?type=13”)

這樣，所有外部系統，都可以用URI這個簡單格式表達出來，所有複雜的細節實現都由整合平臺自身完成。

這種在http中廣泛使用的URL形式將極大的簡化我們隊服務的呼叫形式,從而為DSL化流程提供可能。
整合平臺期望能夠對阿里內部所有的系統提供這種標註化的URI訪問形式。

這樣對開發的好處顯而易見：

1. 每一個開發新人在阿里開發都要去熟悉各種中介軟體系統，這些都有一定的學習成本。及時在熟悉後，開發人員也會碰到各種問題，比如HSF呼叫ar包依賴，需要維護版本升級等因素。
2. 各個業務系統之間由於架構不同，提供服務的形式多種多樣，用一個標準的規範去統一起來，對後續的業務開發效率極有好處。
3. 更明確的分工，中介軟體，業務系統能跟規範自己的能力透出，實現面向服務的架構，系統之間更加解耦。開發團隊可以分為提供基礎設計，提供業務能力和開發業務等不同維度，協作開發，避免各自缺乏溝通或者深度耦合。
4. 簡化後的服務URI可以為DSL形式的流程指令碼設計提供基礎，形成業務人員，產品經理和開發人員都能夠溝通的邏輯。

DSL快速流程設計

對流程的設計和實現可以很好的體現軟體的現代化程度，從程式語言的發展趨勢來看，都是為了能跟高效的完成流程的實現，比如目前我們是用java等程式語言來實現一個業務流程，最近領域語言的發展可以更高效抽象，貼近自然語言的方式來實現邏輯。我們經常在真正編寫程式寫一些虛擬碼，這些虛擬碼跟接近問題本身，處理業務邏輯。 將流程以DSL語言的方式來設計和實現，可以快速的響應需求變化。 以前要編寫大量程式碼的業務邏輯可以轉化成用DSL設計一些子流程，並將子流程組合起來形成一個大的流程。

Camel的DSL語言為我們的流程設計提供了很好的工具。 讓我們對流程編排有一個語言級別的支援。 我們只需要描述流程從開始到結束需要執行的路徑。 同時這種DSL語言可以很好的以圖形化的實現表現和設計，我們可以讓非程式開發人員有可能成為流程的開發著。

我們來看一個DSL流程的例子：

    from("direct:buyNow")
        .split().method("orderSplitter").to("direct:orderAssigment");
    
    from("direct:orderAssignment").recipientList().method("orderRouter");
    
    from("seda:bizType_200?concurrentConsumers=80")
     .to("bean:biztype200Handler?method=prepareOrder").to("direct:orderCreated");
    from("seda:biztype_1001?concurrentConsumers=3")
    .to("bean:bieztype1001handler?method=prepareOrder").to("direct:orderCreated");
    
    from("direct:orderCreated")
        .aggregate(new OrderAggregationStrategy())
   .method("orderPayment", "oderPay").completionTimeout(5 * 1000L);

這段DSL有一些功能，根據業務型別進行識別路由，對每個業務型別，執行不同的流程，然後都執行到訂單建立成功。 每個業務流程需要的機選能力也可以調配。 訂單建立成功後，可以繼續驅動走向訂單付款的流程。

從這段例子可以看到，業務邏輯的實現被極大的簡化，業務開發人員根本就不需要了解什麼是HSF等該如何呼叫。
如果這樣一段DSL基本可以完成一個下單的流程，那麼我們維護和開發新的業務的代價也就可想而知有極大的提高。 DSL的學習成本很低，新的業務開發只需要參考老的業務DSL實現，做一些更改即可。

業務開發輔助工具

當整合平臺通過EIP模式建立起來，同時具有DSL流程描述語言，那麼我們就而已通過開發一些業務輔助工具更高效的開發業務。 比如：

1. 視覺化業務流程設計工具
   提供給業務和開發人員類似Visio的輔助視覺化開發工具，讓業務設計人員能夠視覺化的設計業務流程。
2. 業務流程模擬測試工具
   流程設計完成後，可以對流程的輸入和輸出進行mock測試，輸入不同的條件，檢測不同的結果，從而保證流程開發的質量。
3. 整合平臺執行監控工具
   整合平臺完成了一個資料接入，資料處理，資料流出的資料網，就像鐵路網一樣，資料通過設計好的流程路徑被處理分流，這些標準的方式為我們的實施視覺化監控提供了可能。我們可以實施的跟蹤資料處理過程，當有錯誤，某些點壓力增大時能及時調整（比如限流，引流等），為業務穩健執行提供了更高層的保障。

總結

目前阿里的電商系統已經形成了一個龐大的生態，各種新老系統，中介軟體在一起完成業務功能。 我們在維護系統，開發新業務的過程中，感受到了越來越大的壓力。舊的系統必須維護改造，新的系統業務能夠快速發展，新舊系統之間都需要互聯互通，同時我們又期望維護和開發成本都可以降低，企業整合模式為我們提供一種解決方案，如果我們能有效的在阿里實施EIP，將會對我們系統的架構升級，服務能力，業務快速發展提供保障。

最後期望發起一個專案，對apache camel做阿里相關技術的擴充套件開發，然後contribute回到apache社群，希望有興趣的團隊可以一起合作, Let`s ride the camel。