重繪商旅邏輯架構有感

標籤：系統設計   邏輯架構   架構設計   技術架構   

    商旅系統一做就是三年，這期間系統由初建到流暢運行，架構上經曆了許多次的重構和整理。重新回首，整理一下系統，談談自己對邏輯架構的設計實踐的一些感想。

    商旅系統前後邏輯圖如下所示：

  這張圖是商旅系統最新整理系統邏輯圖，與最初相比，有比較多有趣的地方，值得評鑒。

分層架構的清晰。

    原有三層的分層架構依舊保留，進行了更進一步的抽象，比如系統管理平台和作業平台細分內容沒有進行展示；將應用服務層CC的子系統架構模糊化，定義CC作業平台為渠道端子系統，其服務層和支撐層是子系統內部技術架構，不在總體邏輯架構圖展示；對外聯和業務系統所屬服務進行了適當合并；資料層幾乎全部重新定義。由於整個系統龐大，子系統眾多，在每個分層類，進行了適當的主題與的劃分，這些變更使得邏輯架構對於分層、子系統、模組的職責更為清晰。

    使用層的本質思想有：1）將系統的大型邏輯結構組織為獨立的、職責相關的離散層，清晰、內聚，並且關注分離；2）協作和耦合從較高層到較低層進行，避免從較低層到較高層的耦合。

    使用層有助於解決下面的問題：1）源碼的變更波及整個系統；2）應用邏輯和介面顯示交織在一起，難以複用和分布；3）技術邏輯和商務邏輯交織在一起，難以複用、分布和替換；4）領域之間的高度耦合，難以為不同開發人員清晰地界定和分配任務

    關於分層的優劣也是一直存在爭論，這裡不做贅述。刀可傷人也可助人，關鍵看怎麼用。架構設計上，使用分層是有助於進一步理解系統，就是達到了目的。後面的邏輯架構圖，也還需要進一步完善。分層內一個個方框代表的子系統，粗細粒度大致相當，但還有一些較粗的可進一步展開，如作業平台和網站，規模是比較大的，可以再次橫向分層；業務資料等資料庫，可以通過Schema縱向劃分。

資料層的問題。

    從前後的架構圖相比，資料層新增的東西比較多，變動最多的地方往往也是問題的最多的地方。運行過程中資料庫的許多問題，與邏輯架構設計關聯的有以下幾個。

    第一個問題是業務資料和非業務資料的劃分，定義不夠明確，也就是資料的縱向分層規劃。這可能是由於項目組織架構的關係，我們是分組開發，每個開發組依照自己的經驗和習慣，對業務資料和非業務資料進行分解存放；還有對公用資料的引用、關聯和映射，比較混亂，使得在資料庫這塊有不少的關連接。

    第二個問題是在資料層的劃分中，遺漏了檔案資料、快取資料和報表結算資料的分離。首先是檔案資料，開發、測試過程都是單點，而部署是多點，這樣很多存放於應用伺服器的檔案沒有辦法被其他節點共用；然後訪問的方式有的是通過流的方式讀取，有的是通過HTTP的網站訪問，還需要一些專門的檔案同步工具在前後端子系統之間進行檔案同步。這些處理過於複雜，導致營運同事經常報故障說XXX檔案又點不開了，或者無法下載。緩衝和報表、結算庫的分離是與效能有關的，最初設計中的忽略，於是大家在開發的時候，複雜的低頻率而又需要長時間計算啟動並執行商務邏輯和簡單的邏輯一起放到了主庫中，業務高峰時段會導致CPU消耗達到100%，耗掉硬體資源，從而影響正常業務運行。

職責間協作。

    邏輯架構關心的不僅僅是如何將系統分為不同部分，還關心各部分之間是如何互動的。而識別協作，並將具有共性的協作抽象成通用機制，是邏輯架構設計的重點和痛點。前面的圖裡未做描述，從最新的圖來看，渠道層和服務層之間，是通過遠程調用，走的是Hessian協議；服務層和資料層之間是方法調用，利用了JDBC等中介軟體技術。層與層之間的分離是比較清晰的。實際的運行過程中，服務層的各個子系統，也需要相互調用，資料層各單元也存在著同步資料的連結，層內部的協作，較難抽象出新的串連件邏輯單元，目前通用的方法是如果存在交叉調用，就繼續往下放到資料層。比如營銷和客戶兩個服務需要相互調用，那麼往往委託給預存程序實現，分層和分離難以協調的少部分邏輯，放在資料庫實現裡解決，取一個平衡。

關於邏輯架構設計。

    邏輯架構重在描述系統的職責劃分和職責間的協作關係，它是軟體的宏觀組織圖。之所以稱為邏輯架構，是因為並未決定如何在不同的作業系統進程或網路中物理的電腦上對這些與元素進行部署。

    層和子系統的粗細粒度，需要考慮在建系統的特點。根據系統大小，邏輯結構可以大到分層和子系統，也可以小到模組或者一個個的類。但不管如何劃分，需要針對系統的主要組成部分，強調內聚的職責。還需要描述層次的調用原則，如較高層可以調用較低層，反之則不然。

    嚴格的分層架構中，層只能調用與其相鄰的下層的服務，一般用於網路通訊協定應用。而在商旅這樣的資訊系統中，我們採用了比較寬鬆的分層架構，較高的層可以調用其下任何層的服務。

    邏輯架構的最佳來源是用例分析。基於用例的分析方法會使邏輯架構的設計變得有序——通過對每個關鍵用例的分析，從邏輯上將用例實現為一組功能塊的特定組合，最後綜合這些用例分析成果，將一個個獨立的協作歸納合并成整個軟體系統的邏輯架構。而在用例分析方法產生之前，功能模組的確定多多少少帶有些“硬”想出來的味道，特別是並不直接承載業務功能的模組有時比較容易遺漏，直到大規模編程實現階段才發現。

重繪商旅邏輯架構有感