微服務下技術實踐思考 -- 業務與應用架構設計

企業級微服務架構設計實踐須要從宏觀到微觀層面的思考，主要分爲業務架構、應用架構、技術架構和開發設計方法論。

1、業務架構思考

要建設企業的信息系統首先要明確系統的需求，而要制定系統需求則首先要明確系統對於企業來說要解決哪些問題，哪些參與對象以及如何參與，而後再考慮如何使用信息化手段來優化提高生產力，這就是業務架構須要解決的問題。

1. 業務領域識別

主要明確業務操做的業務主體，業務功能，和業務邊界，這裏是對業務功能的理解與設想。業務領域的理解須要使用領域驅動設計的思想作戰略層面的設計，明確各領域的職責，劃分好領域的邊界。

領域的劃分並無一個統一的標準，是根據企業的實際狀況綜合利弊而得出的，主要的原則是高內聚低耦合，將此業務領域強關聯的業務包括進來，將其它領域的業務剝離出去。對於一些模棱兩可的業務歸屬，須要認真對待，分析業務結果的本質再去判斷如何歸屬。若是出現太多的相似業務存在，須要考慮以前的業務領域的識別是否正確。

業務領域功能設計是一個持續的過程，是應該有一個能力地圖的，是有對此領域所提供的能力有一個長線的規劃。只有這樣才能當某項業務操做流程出現的時候才清楚如何去設計功能歸屬。

2. 業務流程梳理

業務流程形象的表述就是多個業務操做之間業務結果的傳遞。從整個業務系統的宏觀層面上看，業務結果是在各業務領域間傳遞的，業務流程的設計須要保持業務結果的獨立性和複用性，對傳遞方式要求規範性和通用性。從業務領域的微觀層面上看，業務結果是在各業務操做間傳遞的，業務流程的設計須要保持簡便性。

3. 業務模型建設

這部分是業務架構的價值所在，深入認識業務領域做用，透視衆多業務流程，理清業務操做本質，把握業務發展軌跡，造成業務建設原則，構建業務架構模型。

業務的抽象須要深入理解業務操做背後的業務邏輯，切勿簡單地去實現現有的需求，充分考慮業務模型的通用性和多變性，去適配將來業務的不斷髮展。需求細節的變化是多種多樣的，但爲了實現目標的述求基礎上是不變的，應今後出發，站在業務解決問題的角度出發來創建業務模型。

2、應用架構思考

應用架構須要定義整個產品有哪些業務系統，它們是如何集成的，內部是怎麼劃分的，它們是怎麼聯繫起來的。

1.應用劃分

• 業務需求 ：應用的劃分很大程度來源於業務架構的分析，是業務模型的結果顯現。
• 技術現狀 ：考慮到實際技術的支撐狀況，須要去平衡性能與穩定性的要求。一些應用服務的特色是業務簡單，響應容忍度低，受衆面廣，穩定性高；一些應用服務的特色是業務複雜，響應容忍度高，受衆面小，有接受必定的故障率。
• 物理環境 ：在一些複雜的網絡環境中，可能會出現一些服務須要和不一樣網絡環境中的其它服務進行交互的需求，從而致使應用的拆分。
• 安全要求 ：應用服務中所涉及的安全等級有可能不同，有一些是對外的服務，有一些是對內的API，它們的安全認證方式也不同。
• 系統迭代 ：因爲系統的不斷升級可能會出現不兼容的狀況，因爲人員的更迭老版本維護起來愈來愈吃力，因爲技術架構的革新出現不適配的狀況

2. 應用交互

主要包括兩種方式，一種是阻斷式的同步方式，強關聯操做；另外一種是觸發式的異步方式，是弱關聯操做。

2.1 強關聯交互

用於流程操做中必需的步驟，強一致性，主要使用遠程接口調用。此種方式要求調用與被調用方都必須及時響應，反應迅速，系統耦合度較高，執行流程較複雜。在系統設計中儘可能減小此類方式的調用，必須調用時須要關注被調用方的響應時間。

2.2 弱關聯交互

用於流程操做中本應用不關心的其它操做，應用只須要把消息發出，須要使用此消息的應用進行訂閱，主要使用消息中間件。此種方式使用的是異步方式，不要求訂閱方及時響應，系統耦合度低，默認狀況下沒有一致性要求，可實現最終一致性。在系統設計中儘可能使用此類方式，以便提升整個系統的響應速度和結構的穩定性。

2.3 消息傳輸的形式

行爲標識的傳輸 ：包括行爲對象的類型，行爲對象的狀態以及行爲對象的標識代碼

{"code":"XP0000000000000D6001","notice":"PRODUCT","noticeAction":"MODIFY"}

這種方式傳輸的內容簡單，量小，格式統一，訂閱方接收到消息後須要再次經過遠程接口查詢行爲對象，此處結果能夠制定化，但增長了額外的調用開銷且須要保持雙方通信穩定性

行爲對象的傳輸 ：傳遞的內容是整個行爲對象，而行爲的識別可由消息路由去配置

{"code":"XP0000000000000D6001","name":"XXX","statue":"MODIFY","id":"XXX" ...}

這種方式傳輸的內容體積較大，格式不一致，訂閱方接收到消息後可直接獲得行爲對象，無須再次請求接口，但行爲對象的格式是固定的，沒法制定化，爲了適配更多的訂閱方需求每每須要把整個對象傳遞出去，傳輸消耗大，若是消息在消息服務器中堆積較多可能嚴重影響服務器性能。

兩種形式有不同的應用場景，可根據須要選擇。通常狀況下若是行爲對象自己內容較小，爲了不二次請求能夠直接傳輸行爲對象，若是行爲對象內容較大，可只傳輸行爲標識。