可擴(kuò)展性指系統(tǒng)為了應(yīng)對將來需求變化而提供的一種擴(kuò)展能力，當(dāng)有新的需求出現(xiàn)時(shí)，系統(tǒng)不需要或者僅需要少量修改就可以支持，無須整個(gè)系統(tǒng)重構(gòu)或者重建。
由于軟件系統(tǒng)固有的多變性，新的需求總會(huì)不斷提出來，因此可擴(kuò)展性顯得尤其重要。設(shè)計(jì)具備良好可擴(kuò)展性的系統(tǒng)，有兩個(gè)基本條件：正確預(yù)測變化、完美封裝變化。但要達(dá)成這兩個(gè)條件，本身也是一件復(fù)雜的事情。
預(yù)測變化
軟件系統(tǒng)與硬件或者建筑相比，有一個(gè)很大的差異：軟件系統(tǒng)在發(fā)布后還可以不斷地修改和演進(jìn)，這就意味著不斷有新的需求需要實(shí)現(xiàn)。因此作為架構(gòu)師，總是試圖去預(yù)測所有的變化，然后設(shè)計(jì)完美的方案來應(yīng)對。
“預(yù)測”這個(gè)詞，本身就暗示了不可能每次預(yù)測都是準(zhǔn)確的，如果預(yù)測的事情出錯(cuò)，我們期望中的需求遲遲不來，甚至被明確否定，那么基于預(yù)測做的架構(gòu)設(shè)計(jì)就沒什么作用，投入的工作量也就白費(fèi)了。
綜合分析，預(yù)測變化的復(fù)雜性在于：
- 不能每個(gè)設(shè)計(jì)點(diǎn)都考慮可擴(kuò)展性。
- 不能完全不考慮可擴(kuò)展性。
- 所有的預(yù)測都存在出錯(cuò)的可能性。
對于架構(gòu)師來說，如何把握預(yù)測的程度和提升預(yù)測結(jié)果的準(zhǔn)確性，是一件很復(fù)雜的事情，而且沒有通用的標(biāo)準(zhǔn)可以簡單套上去，更多是靠自己的經(jīng)驗(yàn)、直覺，所以架構(gòu)設(shè)計(jì)評審的時(shí)候經(jīng)常會(huì)出現(xiàn)兩個(gè)設(shè)計(jì)師對某個(gè)判斷爭得面紅耳赤的情況，原因就在于沒有明確標(biāo)準(zhǔn)，不同的人理解和判斷有偏差，而最終又只能選擇一個(gè)判斷。
應(yīng)對變化
預(yù)測變化是一回事，采取什么方案來應(yīng)對變化，又是另外一個(gè)復(fù)雜的事情。即使預(yù)測很準(zhǔn)確，如果方案不合適，則系統(tǒng)擴(kuò)展一樣很麻煩。
第一種應(yīng)對變化的常見方案是將“變化”封裝在一個(gè)“變化層”，將不變的部分封裝在一個(gè)獨(dú)立的“穩(wěn)定層”。
無論是變化層依賴穩(wěn)定層，還是穩(wěn)定層依賴變化層都是可以的，需要根據(jù)具體業(yè)務(wù)情況來設(shè)計(jì)。例如，如果系統(tǒng)需要支持 XML、JSON、ProtocolBuffer 三種接入方式，那么最終的架構(gòu)就是上面圖中的“形式 1”架構(gòu)，也就是下面這樣。
如果系統(tǒng)需要支持 MySQL、Oracle、DB2 數(shù)據(jù)庫存儲(chǔ)，那么最終的架構(gòu)就變成了“形式 2”的架構(gòu)了，你可以看下面這張圖。
無論采取哪種形式，通過剝離變化層和穩(wěn)定層的方式應(yīng)對變化，都會(huì)帶來兩個(gè)主要的復(fù)雜性相關(guān)的問題。
1. 系統(tǒng)需要拆分出變化層和穩(wěn)定層
對于哪些屬于變化層，哪些屬于穩(wěn)定層，很多時(shí)候并不是像前面的示例（不同接口協(xié)議或者不同數(shù)據(jù)庫）那樣明確，不同的人有不同的理解，導(dǎo)致架構(gòu)設(shè)計(jì)評審的時(shí)候可能吵翻天。
2. 需要設(shè)計(jì)變化層和穩(wěn)定層之間的接口
接口設(shè)計(jì)同樣至關(guān)重要，對于穩(wěn)定層來說，接口肯定是越穩(wěn)定越好；但對于變化層來說，在有差異的多個(gè)實(shí)現(xiàn)方式中找出共同點(diǎn)，并且還要保證當(dāng)加入新的功能時(shí)原有的接口設(shè)計(jì)不需要太大修改，這是一件很復(fù)雜的事情。
第二種常見的應(yīng)對變化的方案是提煉出一個(gè)“抽象層”和一個(gè)“實(shí)現(xiàn)層”。抽象層是穩(wěn)定的，實(shí)現(xiàn)層可以根據(jù)具體業(yè)務(wù)需要定制開發(fā)，當(dāng)加入新的功能時(shí)，只需要增加新的實(shí)現(xiàn)，無須修改抽象層。這種方案典型的實(shí)踐就是設(shè)計(jì)模式和規(guī)則引擎。下面以設(shè)計(jì)模式為例來說明這種方案的復(fù)雜性。
以設(shè)計(jì)模式的“裝飾者”模式來分析，下面是裝飾者模式的類關(guān)系圖。
圖中的 Component 和 Decorator 就是抽象出來的規(guī)則，這個(gè)規(guī)則包括幾部分：
- Component 和 Decorator 類。
- Decorator 類繼承 Component 類。
- Decorator 類聚合了 Component 類。
這個(gè)規(guī)則一旦抽象出來后就固定了，不能輕易修改。例如，把規(guī)則 3 去掉，就無法實(shí)現(xiàn)裝飾者模式的目的了。
裝飾者模式相比傳統(tǒng)的繼承來實(shí)現(xiàn)功能，確實(shí)靈活很多。例如，《設(shè)計(jì)模式》中裝飾者模式的樣例“TextView”類的實(shí)現(xiàn)，用了裝飾者之后，能夠靈活地給 TextView 增加額外更多功能，比如可以增加邊框、滾動(dòng)條、背景圖片等，這些功能上的組合不影響規(guī)則，只需要按照規(guī)則實(shí)現(xiàn)即可。但裝飾者模式相對普通的類實(shí)現(xiàn)模式，明顯要復(fù)雜多了。本來一個(gè)函數(shù)或者一個(gè)類就能搞定的事情，現(xiàn)在要拆分成多個(gè)類，而且多個(gè)類之間必須按照裝飾者模式來設(shè)計(jì)和調(diào)用。
Ps: 順便理解一下設(shè)計(jì)模式的核心。
設(shè)計(jì)模式的核心就是，封裝變化，隔離可變性。
規(guī)則引擎和設(shè)計(jì)模式類似，都是通過靈活的設(shè)計(jì)來達(dá)到可擴(kuò)展的目的，但“靈活的設(shè)計(jì)”本身就是一件復(fù)雜的事情，不說別的，光是把 23 種設(shè)計(jì)模式全部理解和備注，都是一件很困難的事情。
本節(jié)總結(jié)
什么是架構(gòu)的可擴(kuò)展性
業(yè)務(wù)需求、運(yùn)行環(huán)境方面的變化都會(huì)導(dǎo)致軟件系統(tǒng)發(fā)生變化，而這種軟件系統(tǒng)對上述變化的適應(yīng)能力就是可擴(kuò)展性。
可擴(kuò)展性可以理解為是一種從功能需求方面考慮的軟件屬性，屬性就會(huì)存在好壞之分。
按照可擴(kuò)展性的定義，一個(gè)具備良好可擴(kuò)展性的架構(gòu)設(shè)計(jì)應(yīng)當(dāng)符合開閉原則：對擴(kuò)展開放，對修改關(guān)閉。衡量一個(gè)軟件系統(tǒng)具備良好可擴(kuò)展性主要表現(xiàn)但不限于：
- 軟件自身內(nèi)部方面。在軟件系統(tǒng)實(shí)現(xiàn)新增的業(yè)務(wù)功能時(shí)，對現(xiàn)有系統(tǒng)功能影響較少，即不需要對現(xiàn)有功能作任何改動(dòng)或者很少改動(dòng)。
- 軟件外部方面。軟件系統(tǒng)本身與其他存在協(xié)同關(guān)系的外部系統(tǒng)之間存在松耦合關(guān)系，軟件系統(tǒng)的變化對其他軟件系統(tǒng)無影響，其他軟件系統(tǒng)和功能不需要進(jìn)行改動(dòng)。反之，則是一個(gè)可擴(kuò)展性不好的軟件系統(tǒng)。
為什么要求架構(gòu)具備良好的可擴(kuò)展性
伴隨業(yè)務(wù)的發(fā)展、創(chuàng)新，運(yùn)行環(huán)境的變化，對技術(shù)也就提出了更多、更高的要求。能夠快速響應(yīng)上述變化，并最大程度降低對現(xiàn)有系統(tǒng)的影響，是設(shè)計(jì)可擴(kuò)展性好的架構(gòu)的主要目的。
如何設(shè)計(jì)可擴(kuò)展性好的架構(gòu)
面向?qū)ο笏枷搿⒃O(shè)計(jì)模式都是為了解決可擴(kuò)展性的而出現(xiàn)的方法與技術(shù)。
設(shè)計(jì)具備良好可擴(kuò)展性的系統(tǒng)，有兩個(gè)思考角度：
- 從業(yè)務(wù)維度。對業(yè)務(wù)深入理解，對可預(yù)計(jì)的業(yè)務(wù)變化進(jìn)行預(yù)測。
- 從技術(shù)維度。利用擴(kuò)展性好的技術(shù)，實(shí)現(xiàn)對變化的封裝。
在業(yè)務(wù)維度。對業(yè)務(wù)深入理解，對業(yè)務(wù)的發(fā)展方向進(jìn)行預(yù)判，也就是不能完全不考慮可擴(kuò)展性；但是，變化無處不在，在業(yè)務(wù)看得遠(yuǎn)一點(diǎn)的同時(shí)，需要注意:警惕過度設(shè)計(jì)；不能每個(gè)設(shè)計(jì)點(diǎn)都考慮可擴(kuò)展性；所有的預(yù)測都存在不正確的可能性。
在技術(shù)維度。預(yù)測變化是一回事，采取什么方案來應(yīng)對變化，又是另外一個(gè)復(fù)雜的事情。即使預(yù)測很準(zhǔn)確，如果方案不合適，則系統(tǒng)擴(kuò)展一樣很麻煩。第一種應(yīng)對變化的常見方案是將“變化”封裝在一個(gè)“變化層”，將不變的部分封裝在一個(gè)獨(dú)立的“穩(wěn)定層”。第二種常見的應(yīng)對變化的方案是提煉出一個(gè)“抽象層”和一個(gè)“實(shí)現(xiàn)層”。
在實(shí)際工作場景中的解決方案
在實(shí)際軟件系統(tǒng)架構(gòu)設(shè)計(jì)中，常通過以下技術(shù)手段實(shí)現(xiàn)良好的可擴(kuò)展性:
- 使用分布式服務(wù)（框架）構(gòu)建可復(fù)用的業(yè)務(wù)平臺(tái)。
- 使用分布式消息隊(duì)列降低業(yè)務(wù)模塊間的耦合性。
分布式服務(wù)框架
利用分布式服務(wù)框架（如 Dubbo）可以將業(yè)務(wù)邏輯實(shí)現(xiàn)和可復(fù)用組件服務(wù)分離開，通過接口降低子系統(tǒng)或模塊間的耦合性。新增功能時(shí)，可以通過調(diào)用可復(fù)用的組件實(shí)現(xiàn)自身的業(yè)務(wù)邏輯，而對現(xiàn)有系統(tǒng)沒有任何影響。可復(fù)用組件升級變更的時(shí)候，可以提供多版本服務(wù)對應(yīng)用實(shí)現(xiàn)透明升級，對現(xiàn)有應(yīng)用不會(huì)造成影響。分布式消息隊(duì)列
基于生產(chǎn)者 - 消費(fèi)者編程模式，利用分布式消息隊(duì)列（如 RabbitMQ）將用戶請求、業(yè)務(wù)請求作為消息發(fā)布者將事件構(gòu)造成消息發(fā)布到消息隊(duì)列，消息的訂閱者作為消費(fèi)者從消息隊(duì)列中獲取消息進(jìn)行處理。通過這種方式將消息生產(chǎn)和消息處理分離開來，可以透明地增加新的消息生產(chǎn)者任務(wù)或者新的消息消費(fèi)者任務(wù)。
