一、尋找架構驅動力

人類自開始學會以智慧洗亮觀察世界的雙眼之后，就明白觀察事物不能淺嘗輒止停留在表面現象，而要去看透本質。通過本質規律去建模世界，才能以“一”推演萬物。種種推演的過程，皆是要去尋找某種驅動力量作為分析或建構的起點。

[[182450]]

例如，當我們要分析一個運動中的物體會形成如何的運動軌跡時，就需要尋找產生運動的力，包括初始的動力、重力、摩擦力以及其他可能干擾物體運動的力。有的力會推動者物體向前，例如初始動力以及與運動方向保持一致的作用力;有的力會阻礙物體的運動，如摩擦力或者空氣阻力等。通過分析這些力的方向及度量，大致可以描繪出物體可能的運動軌跡。

軟件系統的復雜度遠遠超過物體的運動模型(當然，從確定性角度講，軟件或許比物體的運動更簡單)，但其推演的過程卻是相似的，因為一個軟件系統并非完全獨立的存在，而是處在一個更大的生態環境圈中，包括客戶的需求與使用體驗、上游依賴系統、下游依賴系統、硬件與網絡環境、團隊技能水平等諸多因素縱橫交錯，顯式或隱式地對軟件架構的走向施加影響。這些影響因素就相當于是影響“軟件”這個物體運動的力量。架構師要做的工作就是要敏銳地從這些紛繁復雜如蛛網一般糾纏的力量中梳理出清晰的脈絡。

所謂“力”，其實是一種隱喻。雖然觀察軟件系統的視角如萬花筒一般繽紛多彩，然而若從“物理力學”的視角剖析架構，似乎更加準確直接。軟件系統正如物體一般，在各種影響力之下不停變化(運動)。不同的影響因素會決定著架構師的設計決策，而這些決策之間又相互影響著，或者相吸，或者相斥，絕對不能孤立看待。于是，架構分析與設計就變成了對軟件系統的影響力識別，這種設計的驅動力即我們所謂的RAID分析法。

二、RAID分析法

所謂RAID分析法，即識別軟件系統的風險(Risk)、假設(Assumption)、問題(Issue)、依賴(Dependency)，準確地說，就是：

• 評估風險
• 明確假設
• 分析問題
• 識別依賴

正如在《架構之美》中John Klein、David Weiss寫道：

這里所謂的“品質”，即我們常說的質量屬性(Quality Attribute)。對于架構師而言，業務需求導致設計復雜度的增加僅僅是一種量的變化;而質量屬性對設計的要求，則可能隨著復雜度的增加而產生質變。以分布式系統為例，隨著對消息隊列、分布式存儲、服務通信與集成的引入，在數據一致性、可靠性、安全、運維管理等諸多方面，產生的復雜度與單機系統不可同日而語，設計挑戰與難度幾乎與規模形成指數增長。

系統復雜度或許是沒有限制的，而人力卻有限。我們在開始軟件系統的建構與設計時，難免有考慮不周到之處，若是沒有掌握合理的設計方法而深陷浩瀚如滄海一般的各種需求中，牽扯到各個利益相關者的糾纏中，我們就可能會迷路、困惑，或者作出不適合當下場景的設計決策。

RAID分析在一定程度上可以幫助我們重拾正確的方向，尤其在處理質量屬性方面，頗有奇效。

我的建議是將RAID分析以Workshop的形式開展，召集團隊成員通過頭腦風暴來完成。由于將所有軟件系統可能面臨的問題分為了RAID四類，從而明確了討論的范圍與類別，使得參與者能夠以更加收斂更加清晰的思路參與進來。一個典型的RAID分析結果如下圖所示：

在進行RAID分析之前，我們需要明確這四個概念之間的區別。

三、風險與問題

風險(Risk)與問題(Issue)常常被人混淆在一起，而二者在概念上卻有其相關性。風險其實就是未來可能出現的問題。我們在軟件設計的過程中，一直都在未來與現實中徘徊。滿足現實，卻又需要預測未來。然而，未來是不可預測的，所有的預測其實都是一種想象;我們夸夸其談預測未來，其實不過是想象未來罷了。于是，現實與未來之間就開始了痛苦的拉鋸戰，我們既不能對未來做過多預測與判斷，卻又不能僅滿足于現狀，如何做到架構設計的恰如其分，在規避過度設計的同時，又能讓我們的架構能夠在未來需求發生變化時以最小的成本應對。我們真正要做到的是前瞻未來，評估風險就是讓我們能夠前瞻未來的瞭望鏡(這世上并沒有預測未來的魔法水晶球)。

分析現在存在的問題，評估未來風險，將是這場拉鋸戰的關鍵制高點。在判定優先級時，問題往往高于風險，需要在解決現有問題的前提上，考慮未來風險的應對方案。譬如說，系統目前存在的問題是性能堪憂，那么除了必要的調優手段外，我們可以通過提高系統的可伸縮性來改進性能。然而，要保證系統的可伸縮性，就需要保持服務的無狀態，并在設計系統的各個分層時都需要支持水平擴展，則可能引入數據不一致以及系統欠穩定的風險。

四、假設

我們往往會忽略為系統給定假設(Assumption)，而事實上，這種假設往往代表了關鍵的架構約束。

架構約束是一種非常重要的驅動力。Roy Fielding在其論文Architectural Styles and the Design of Network-based Software Architectures(《架構風格與基于網絡的軟件架構設計》)中如此勾勒出約束的重要性：

我們在明確假設時，需要將這些約束甄別出來，以之作為架構設計的驅動力。例如，對于一個移動APP，我們明確假設：用戶在斷開網絡連接時，能夠正常地查閱個人信息與產品信息。這個假設就對軟件架構提出約束，即在APP的客戶端需要緩存數據信息，并在用戶連接WIFI時，能夠自動同步客戶端數據到服務端。

某些假設則是系統功能性的重要約定，好似契約一般，需要在整個設計與實現階段需要遵從。例如假設電商系統需要調用的推薦系統為第三方系統，那么在設計時就需要明確推薦系統公開的接口，系統之間如何集成，當推薦系統的服務發生變更時，客戶方該如何應對。這些都會直接影響我們的設計決策。

五、依賴

在軟件設計中，我們無時不刻不在與依賴作斗爭。依賴本身是無善無惡的，關鍵在于我們該如何分解(內聚)，如何協作(耦合)，這就是我們需要遵循的高內聚低耦合設計原則。在架構層面，情況更顯復雜，除了系統內部的依賴之外，還需要考慮系統外部上游與下游的依賴。尤其是跨越物理邊界(可以視為一個進程)之間的通信，會直接影響到可靠性、性能、可伸縮性等諸多質量屬性。

DDD的Context Map定義了九種Bounded Context之間的映射關系，其中包括防腐層、開放主機服務與發布語言表達的就是Bounded Context之間的集成關系。如果我們能夠在架構之處識別出系統存在的依賴，再結合Cockburn提出的六邊形架構對其進行更加直觀的可視化，找出依賴途經的端口(Port)與適配器(Adapter)，然后確定依賴之間的通信(集成)方式，幾乎就可以得出整個軟件系統應用邏輯架構與物理架構的雛形了。

下圖將六邊形架構與識別的依賴結合起來：

六、實施RAID分析的案例

在多個系統的架構設計或Inception階段，我通過運用RAID分析法驅動系統的軟件架構設計，效果頗佳，雖然在細節處還欠缺精細，但從大處著手，卻可以幫助我們高屋建瓴地分析與架構整個系統。以下是針對某版本升級系統的RAID分析案例。

七、評估風險

通常而言，對風險的識別可以引導我們對系統質量屬性的思考，利益相關者可

以充分表達對這些屬性的擔心，從而驅動我們去尋找解決方案。

1. 穩定性

在這次RAID分析中，有利益相關者明確提出了對穩定性的擔憂。系統的多個模塊駐留在不同的節點中，部分模塊還是以嵌入方式駐留在主控板上。由于業務需要，模塊之間的通信相對頻繁，主要的通信協議為Telnet與SSH。從舊有的系統表現來看，跨界點之間的通信在穩定性方面表現欠佳。基于這一問題，我們在后續的架構設計中對此進行了深入分析，除了保證通信實現自身的健壯性與異常處理之外，我們還決定在主控板一端設計粗粒度的接口，一次性地傳遞版本升級需要的信息，減少不必要的通信。

2. 可擴展性

風險對擴展性的識別，幫助我們確立了一個架構原則，就是版本規格包的結構不應該影響到主控板的系統。這是因為主控板系統的版本升級受到的制約最多，我們不希望當產品發生變化時，影響整個版本管理系統。

3. 性能

當需要升級的系統數量較多時，系統的版本升級過程會變得緩慢。而業務需求有要求了系統不能長期處于shutdown狀態，否則會增加運營成本。因此，升級過程通常會選在凌晨，并且要求在較短時間內完成整個升級工作，故而性能可謂重中之重。

我們考慮采用并發方式為每個待升級系統進行升級。升級過程是一個獨立的過程，卻又牽涉到較為復雜的業務流程以及跨節點通信。由于部署限制，后臺只能部署在一個JVM之上，通過啟動多個并發線程來處理升級業務。執行升級時，需要加載配置文件到內存中，若同時啟動的線程數過多，則可能導致OutOfMemory異常。這個風險的識別及時地為我們敲響了警鐘。我們為此安排了技術Spike，以期找到合適的配置項，在性能與可靠性之間進行***權衡。

八、明確假設

假設(Assumption)可以是關鍵的架構約束，也可以是系統功能性的約定。架構約束既可能是設計的阻力，也可以成為動力。經過討論，我們基本上確定了兩條最為重要的假設：

系統必須支持雙向兼容。這個假設的提出，則要求我們在開發過程中，只要接口已經發布，就不能再修改接口。除修復缺陷外，我們不能刪除舊有功能，只能增加新功能。即使舊有功能已被新功能取代，為保持兼容性，我們也不能刪除，但可以將其置為@deprecated標注。

版本升級過程中,若前后操作具有依賴關系，則必須保證事務的一致性，要么全部成功，要么全部失敗。事實上，這一條假設也是對質量屬性“可靠性”的一個回應。

九、分析問題

整個RAID的識別都針對技術層面，而非管理層面。因此我們識別的問題也限

制在技術范圍。

在我們識別出來的問題中，最致命的一個問題是關于模塊NVUM的加載。NVUM是一個JAR包。它并非一個獨立運行的系統，而是由管理系統動態加載。之所以選擇動態加載，而非靜態依賴，原因包括：

• NVUM由我們項目組維護，管理系統則屬于另外一個項目，兩邊的版本計劃完全不一致。網管系統為一個Client-Server系統，相對成熟，目前已被獨立地部署到全球多個外場。若采用靜態依賴，就需要我們將其納入到網管系統中。但NVUM的版本更新更加頻繁，外場不可能因為NVUM一個模塊的調整，而付出頻繁更新管理系統的代價。
• 管理系統負責監控外場各設備的運轉狀況。雖然系統的重啟(耗時數十分鐘)并不會影響設備的功能，但卻可能在重啟過程中，因為未能及時掌控設備狀態，而導致無法及時發現問題。必須避免這種事故的發生。換言之，管理系統的重啟代價太高，不能經常重啟。

JAR包的動態加載可以通過URLClassLoader來實現，又或者選擇OSGI。前者需要充分驗證其穩定性，后者則過于重型，成本太高。另外，動態加載方式對于模塊設計而言存在設計約束，即我們需要將NVUM分為interface和impl兩個模塊，且必須保證interface的穩定性。

另一個方案是采用腳本，例如選擇能夠運行在JVM上的Groovy腳本語言。我們只需要在Java中調用Groovy提供的GroovyShell，就能直接讀取groovy腳本文件;然后調用run()方法即可執行腳本。

十、識別依賴

除了NVUM與管理系統，NVUM與主控板，主控板與其他設備之間的依賴外，牽涉到的依賴還有很多。有的屬于輸入依賴，有的則屬于輸出依賴。此外，還有版本制作工具等系統也會受到NVUM的影響。同時，NVUM還需要訪問內建的文件系統，通過FTP讀取諸多外部文件。通信則可能采用Telnet、SNMP、SSH等多種協議。

這些依賴的識別便于確定本系統對其他系統可能造成的影響，事先識別有利于我們及時做好溝通，同時還需要就一些架構約定以及接口定義達成一致意見。依賴的識別也有利于我們設計系統的物理架構，考慮系統的部署方式。

【本文為51CTO專欄作者“張逸”原創稿件，轉載請聯系原作者】

戳這里，看該作者更多好文