軟件設計要素初探：組件化思想

在 「軟件設計要素初探」 一文，嘗試從軟件設計的總體角度，綜合討論了軟件設計的各類要素。本文討論用於系統劃分的組件化思想。

概述

將整個系統劃分爲若干正交的緊密關聯的子系統，以及高內聚低耦合的小而美的模塊與微服務，理清職責、交互與邊界。劃分的基本原則是「識別、分離和組合關注點」。每一個子系統一定有其核心關注點和基礎關注點，而基礎關注點中交疊的部分，便是子系統交互定義的基礎。

組件化

組件化是可靈活組合和可定製的前提，是構建大型軟件應用的核心思想。組件化的基本技巧是「識別和分離關注點」。內心沒有「關注點」概念的開發者，寫代碼時比較隨意，在實現功能時無心識將多個關注點摻雜在一塊兒，當關注點發生變化須要重組時，「for-ififelseif-for-ifelseif-switch」的噩夢開始誕生了。而善於「識別和分離關注點」的開發者則會想辦法把這些關注點解耦開，實現成簡潔可組合的短小函數、方法和類，並置於該歸屬的地方。組件化的另外一個基本技巧是「面向接口編程」：先建立所須要的組件接口，而後建立基於組件接口的應用骨架，最後根據需求和場景建立和注入具體實現。儘管有時這種作法顯得「有點過分設計」，卻更有易於理解系統流程。

組件化能夠從不一樣粒度上進行。

(1) 單個應用。單個應用內的組件化，主要是將單一關注點的邏輯功能組件化，可以靈活組合和配置；亦可將緊密關聯的小組件串聯成更大粒度的更實用的組件。好比一個訂單導出應用，其流程是：訂單搜索 -> 訂單詳情獲取與拼接 -> 訂單過濾 -> 詳情數據格式化 -> 結合報表模板生成報表 -> 上傳報表文件。將每一個步驟定義成一個組件接口(訂單搜索組件接口、獲取詳情組件接口、訂單過濾組件接口、訂單詳情格式化組件接口、報表生成器組件接口、上傳文件組件接口)，再定義一個全局控制器，將組件接口串聯成導出流程，而具體的導出實現只要傳入指定組件接口的具體實現便可。訂單搜索能夠從DB查詢，亦能夠從 ES 查詢；訂單詳情能夠從API接口獲取，亦能夠從Hbase獲取。爲保證大批量數據導出的性能，減小業務數據庫和業務接口的壓力，推薦使用 ES + Hbase 組合。

組件化以後，亦容易實現可定製化。 好比有的導出只須要導出 ES 表裏的記錄；有的導出只須要導出 Hbase 表裏的記錄；而略微複雜的導出則須要從 ES 和 Hbase 同時獲取數據。這就須要根據參數配置對組件進行靈活組合。

(2) 多個應用構成了更大粒度的領域服務組件。一些互聯網企業開始推行「服務化架構」，每一個服務化工程就是一個組件。好比訂單管理組件可由訂單搜索/訂單詳情/數據同步/發貨組件/訂單導出組件等組成；交易服務組件可由下單服務組件、訂單管理組件、逆向交易組件以及輔助組件(好比交易消息推送組件、覈銷組件)組成。

(3) 多個特定領域服務組件構成更大粒度的行業服務。好比交易、營銷、商品、會員等服務組件可構成電商SAAS的雲服務能力。好比擁有完整微商城能力並致力於移動零售領域的有贊雲。

組件協做

嘗試從更大範圍的系統領域來思考和設計組件以及組件之間的協做結構。好比訂單導出須要從ES和Hbase搜索訂單和獲取訂單詳情，而ES和Hbase的訂單數據則依賴於從消息、DB或API接口進行數據獲取和存儲的數據同步組件。所以，大數據存儲設計、數據同步對於訂單導出的總體設計尤其重要。

訂單導出的比較棘手的一個問題是，數據源一般來自於多個分散的業務表，這樣致使同步設計重並且不靈活。若是制定一種標準，須要導出的字段必須落在下單表的字段或擴展字段裏，那麼就能夠有效地解決數據源分散的問題，而集中精力於解決導出可擴展可配置的問題。此時，下單、同步、導出成爲密切關聯的一體化設計。當從單系統上難以尋求解決方案時，不妨從更大系統範圍去發現。

建立組件，定製組件，設計和複用組件協做結構，組合出更大結構的組件，從而可以建立更大型更綜合的大規模軟件系統。

設計優良的系統，一般有一個清晰的組件化的骨架。組件化的骨架，就是可定製和可擴展的基礎支撐。