緊接著我們來聊聊可擴展性。

可擴展性是指，軟件系統具備面對未來需求變化而進行擴展的能力。系統可根據新的需求做出少量或者不需要修改，無需對整個系統進行重構或重建。

由于軟件系統變化多端，新的需求不斷提出，因此可擴展性非常重要。為解決可擴展性帶來的問題，面向對象思想的提出，設計模式的誕生更是將可擴展性發揮到了極致。幾乎所有的技術人員都重視可擴展性。

當涉及到軟件系統的可擴展性時，架構師面臨一個復雜的挑戰：如何預測未來的需求變化并為之提供擴展性，以便系統能夠在不需要大幅度修改或重建的情況下支持新的需求。這是因為軟件系統在發布后仍然可以不斷地修改和演進，導致新的需求不斷出現，而系統必須能夠應對這些變化。如果系統能夠以較小的修改量或甚至無需修改就能實現新需求，那當然是最理想的情況，否則就需要進行大規模修改或重構，這將極大地增加開發成本，也會導致程序員、產品經理和老板的不滿。因此，架構師必須嘗試預測所有可能的變化并設計出最佳的解決方案，以便在下一次需求到來時，能夠高效地滿足需求。但是，這個過程并不容易，因為架構師需要在考慮可擴展性和其他設計因素之間進行平衡，并且預測的結果也不總是準確的。同時，如果架構師忽略可擴展性，那么當新需求到來時，可能需要重構系統，這將導致前期投入的工作量白費。因此，架構師需要通過經驗和直覺來提高預測結果的準確性，同時也需要明確的標準來幫助評審和決策。

設計具備良好可擴展性的系統有兩個基本條件：

• 正確預測變化；
• 完美應對變化

但要達成這兩個條件，本身也是一件復雜的事情，我來具體分析一下。

預測變化

軟件系統與硬件或者建筑相比，有一個很大的差異：軟件系統在發布后，還可以不斷地修改和演進。

這就意味著 不斷有新的需求需要實現。

如果新需求能夠少改代碼甚至不改代碼就可以實現，那當然是皆大歡喜的，否則來一個需求就要求系統大改一次，成本會非常高，程序員心里也不爽（改來改去），產品經理也不爽（做得那么慢），老板也不爽（那么多人就只能干這么點事）。

要滿足這兩個條件，本身就是一件復雜的事情。作為架構師，總是試圖預測所有的變化，然后設計完美的方案來應對。當新需求真正來臨時，可以自豪地說：“這個我當時已經預測到了，架構已經完美地支持，只需要一兩天工作量就可以了！”

但是，預測變化的復雜性在于不能每個設計點都考慮可擴展性，也不能完全不考慮。而且所有的預測都存在出錯的可能性。架構師必須把握預測的程度和提升預測結果的準確性，這是一件很復雜的事情，沒有通用的標準可以簡單套用，更多是靠自己的經驗和直覺。因此，在架構設計評審時，常常出現兩個設計師對某個判斷爭得面紅耳赤的情況，原因在于沒有明確標準，不同的人理解和判斷有偏差，而最終又只能選擇其中一個判斷 有一句諺語：“唯一不變的是變化。”如果按照這個標準去衡量，架構師每個設計方案都要考慮可擴展性，例如：

• 架構師準備設計一個簡單的后臺管理系統，當架構師考慮用MySQL存儲數據時，是否要考慮后續需要用Oracle來存儲？
• 當架構師設計用HTTP做接口協議時，是否要考慮要不要支持ProtocolBuffer？
• 甚至更離譜一點，架構師是否要考慮VR技術對架構的影響從而提前做好可擴展性？

如果架構師在設計系統時每個點都考慮可擴展性，那么會讓其不堪重負，架構設計也會變得異常龐大，最終可能無法落地。但是如果架構師完全不考慮系統的可擴展性，那么可能會導致系統剛上線就需要重構，這意味著前期的大量投入將會白費。因此，在設計時需要適度考慮可擴展性，以提高系統的靈活性，但也需要合理平衡成本和效益。

同時，“預測”這個詞，本身就暗示了不可能每次預測都是準確的。如果預測的事情出錯，我們期望中的需求遲遲不來，甚至被明確否定，那么基于預測做的架構設計就沒什么作用，投入的工作量也就白費了。

綜合分析，預測變化的復雜性在于：

1. 不能每個設計點都考慮可擴展性。
2. 不能完全不考慮可擴展性。
3. 所有的預測都存在出錯的可能性。

對于架構師來說，如何預測變化的程度和提高預測的準確性是一個非常復雜的問題。目前沒有一套通用的標準可以簡單地應用，更多是根據架構師的經驗和直覺。因此，在架構設計評審時，經常會發生兩個設計師就某個判斷產生激烈爭議的情況。這是因為缺乏明確的標準，不同的人會有不同的理解和判斷偏差，最終只能選擇其中一個判斷。

2年法則

那么我們設計架構的時候要怎么辦呢？根據以往的職業經歷和思考，我提煉出一個“2年法則”供你參考： 只預測2年內的可能變化，不要試圖預測5年甚至10年后的變化。

當然，你可能會有疑問：為什么一定是2年呢？有的行業變化快，有的行業變化慢，不應該是按照行業特點來選擇具體的預測周期嗎？

理論上來說確實如此，但實際操作的時候你會發現，如果你要給出一個讓大家都信服的行業預測周期，其實是很難的。

我之所以說要預測2年，是因為變化快的行業，你能夠預測2年已經足夠了；而變化慢的行業，本身就變化慢，預測本身的意義不大，預測5年和預測2年的結果是差不多的。所以“2年法則”在大部分場景下都是適用的。

應對變化

假設架構師經驗非常豐富，目光非常敏銳，看問題非常準，所有的變化都能準確預測，是否意味著可擴展性就很容易實現了呢？也沒那么理想！因為預測變化是一回事，采取什么方案來應對變化，又是另外一個復雜的事情。即使預測很準確，如果方案不合適，則系統擴展一樣很麻煩。

方案一：提煉出“變化層”和“穩定層”

第一種應對變化的常見方案是： 將不變的部分封裝在一個獨立的“穩定層”，將“變化”封裝在一個“變化層”（也叫“適配層”）。這種方案的核心思想是通過變化層來 隔離變化。

無論是變化層依賴穩定層，還是穩定層依賴變化層都是可以的，需要根據具體業務情況來設計。

如果系統需要支持XML、JSON、ProtocolBuffer三種接入方式，那么最終的架構就是“形式1”架構；如果系統需要支持MySQL、Oracle、DB2數據庫存儲，那么最終的架構就變成了“形式2”的架構了。

無論采取哪種形式，通過剝離變化層和穩定層的方式應對變化，都會帶來兩個主要的復雜性相關的問題。

1. 變化層和穩定層如何拆分？

對于哪些屬于變化層，哪些屬于穩定層，很多時候并不是像前面的示例（不同接口協議或者不同數據庫）那樣明確，不同的人有不同的理解，導致架構設計評審的時候可能吵翻天。

1. 變化層和穩定層之間的接口如何設計？

對于穩定層來說，接口肯定是越穩定越好；但對于變化層來說，在有差異的多個實現方式中找出共同點，并且還要保證當加入新的功能時，原有的接口不需要太大修改，這是一件很復雜的事情，所以接口設計同樣至關重要。

例如，MySQL的REPLACE INTO和Oracle的MERGE INTO語法和功能有一些差異，那么存儲層如何向穩定層提供數據訪問接口呢？是采取MySQL的方式，還是采取Oracle的方式，還是自適應判斷？如果再考慮DB2的情況呢？

看到這里，相信你已經能夠大致體會到接口設計的復雜性了。

方案二：提煉出“抽象層”和“實現層”

第二種常見的應對變化的方案是： 提煉出一個“抽象層”和一個“實現層”。如果說方案一的核心思想是通過變化層來隔離變化，那么方案二的核心思想就是通過實現層來 封裝變化。

因為抽象層的接口是穩定的不變的，我們可以基于抽象層的接口來實現統一的處理規則，而實現層可以根據具體業務需求定制開發不同的實現細節，所以當加入新的功能時，只要遵循處理規則然后修改實現層，增加新的實現細節就可以了，無須修改抽象層。

方案二典型的實踐就是設計模式和規則引擎。考慮到絕大部分技術人員對設計模式都非常熟悉，我以設計模式為例來說明這種方案的復雜性。

下面是設計模式的“裝飾者”模式的類關系圖。

圖中的Component和Decorator就是抽象出來的規則，這個規則包括幾部分：

1. Component和Decorator類。
2. Decorator類繼承Component類。
3. Decorator類聚合了Component類。

這個規則一旦抽象出來后就固定了，不能輕易修改。例如，把規則3去掉，就無法實現裝飾者模式的目的了。

裝飾者模式相比傳統的繼承來實現功能，確實靈活很多。例如，《設計模式》中裝飾者模式的樣例“TextView”類的實現，用了裝飾者之后，能夠靈活地給TextView增加額外更多功能，包括可以增加邊框、滾動條和背景圖片等。這些功能上的組合不影響規則，只需要按照規則實現即可。

但裝飾者模式相對普通的類實現模式，明顯要復雜多了。本來一個函數或者一個類就能搞定的事情，現在要拆分成多個類，而且多個類之間必須按照裝飾者模式來設計和調用。

規則引擎和設計模式類似，都是通過靈活的設計來達到可擴展的目的，但“靈活的設計”本身就是一件復雜的事情，不說別的，光是把23種設計模式全部理解和備注，都是一件很困難的事情。

1寫2抄3重構原則

那么，我們在實際工作中具體如何來應對變化呢？Martin Fowler在他的經典書籍《重構》中給出一個“Rule of three”的原則，原文是“Three Strikes And You Refactor”，中文一般翻譯為“事不過三，三則重構”。

而我將其翻譯為“1寫2抄3重構”，也就是說你不要一開始就考慮復雜的可擴展性應對方法，而是等到第三次遇到類似的實現的時候再來重構，重構的時候采取隔離或者封裝的方案。

舉個最簡單的例子，假設你們的創新業務要對接第三方錢包，按照這個原則，就可以這樣做：

• 1寫：最開始你們選擇了微信錢包對接，此時不需要考慮太多可擴展性，直接快速對照微信支付的API對接即可，因為業務是否能做起來還不確定。
• 2抄：后來你們發現業務發展不錯，決定要接入支付寶，此時還是可以不考慮可擴展，直接把原來微信支付接入的代碼拷貝過來，然后對照支付寶的API，快速修改上線。
• 3重構：因為業務發展不錯，為了方便更多用戶，你們決定接入銀聯云閃付，此時就需要考慮重構，參考設計模式的模板方法和策略模式將支付對接的功能進行封裝。

小結

今天我從預測變化和應對變化這兩個設計可擴展性系統的條件，以及它們實現起來本身的復雜性，為你講了復雜度來源之一的可擴展性，共勉！