程序員過關斬將--論系統設計的高可擴展性
此文僅僅代表個人意見，并非行業標準
“MQ是萬能的高擴展方式?
“面向接口是萬能的高擴展方式?
說到系統設計的三高，每一高都是一個很龐大的話題，甚至可以用一本書甚至N本書來詳細闡述。其中高可擴展性是系統架構的眾多目標之一。歸根結底，系統的架構要為最終的業務服務，脫離業務來談架構其實比耍流氓更無恥。
在我們心目中最理想的軟件架構要像搭積木一樣簡單，并且快捷，而且高效。但是現實往往比996更殘酷，多數的系統在初期為了配合業務快速上線，擴展性這個指標并不理想。別的不談，一個系統要完美的做到“對修改封閉，對擴展開放”其實一點也不簡單，不知道你有沒有遇到過修改一個bug蹦出另外一個bug的痛苦經歷?
為了做到系統的高擴展性，其實有很多借鑒的案例，尤其是設計模式。但是今天我還是要說一說我自己的看法。無論什么樣的系統，抽象起來其實都是模塊和模塊之間的交互，這里模塊的含義是廣義的，即可以代表函數，也可以代表進程，甚至可以代表目前流行的微服務，如下圖所示
image
圖是不是很簡單?但是要想把A和B之間的交互做到高擴展其實并不容易，這要求系統的設計者必須要想辦法在滿足A和B正常交互的情況下盡量解耦A和B，只有正確的解耦，才能從容的應對A和B獨立擴展的業務需求
同一進程內
在同一進程內的情況是一種最常見的存在方式，對應到我們平時的代碼，表現為函數的調用，而這里的函數調用可以是同一模塊內的函數調用，比如最典型的三層架構中，業務層調用持久化層來進行數據的操作，如下代碼：
- //user 業務層
- public class UserBLL
- {
- UserDAL dal = new UserDAL();
- public int AddUser(User user)
- {
- //其他業務
- return dal.AddUser(user);
- }
- }
- //user持久化層
- public class UserDAL
- {
- public int AddUser(User user)
- {
- //進行數據庫操作
- return 0;
- }
- }
我真的希望實際項目中的代碼能像以上代碼這么簡單，畢竟代碼就和項目一樣，簡單即是美。這段代碼排除業務之外，從架構來講也有很多問題，用開頭的A和B的方式來表示，A代表的是UserBLL，B代表的是UserDAL，這里最容易看出的就是強耦合，即：A嚴重依賴于B，如果B有什么風吹草動，勢必會影響A的執行。
怎么辦呢?所以有了B的抽象層，對應到代碼上是IDAL接口層，當然這個抽象層應該是穩定的，如果三天兩頭修改抽象層，那說明抽象的有問題。A在執行上改為依賴IDAL，這是系統內設計最常見的面向接口設計模式，其實更準確的說，應該是面向抽象設計模式。由于引入了穩定的抽象層，不再穩定的實現層就可以根據實際的業務去修改，這里體現的是系統設計中依賴倒置的原則，當然為了實現依賴倒置，你可能需要使用IOC等技術來實現項目落地。
- //user 業務層
- public class UserBLL
- {
- IUserDAL dal = "依賴注入";
- public int AddUser(User user)
- {
- //其他業務
- return dal.AddUser(user);
- }
- }
- //user的持久化層抽象
- public interface IUserDAL
- {
- int AddUser(User user);
- }
- //user持久化層
- public class UserDAL: IUserDAL
- {
- public int AddUser(User user)
- {
- //進行數據庫操作
- return 0;
- }
- }
不同進程間
不同的進程之間互相協作是目前分布式模式下主要的交互方式，例如之前的SOA，現在的微服務，都是在利用分散在不同位置的模塊來組裝系統，這些模塊之間的通信是一個分布式系統必備的條件。
和進程內函數調用類似，分布式系統也可以抽象為A和B的關系模型，我們要解決的也是A和B能夠獨立變化的問題。現在假設A服務依賴于B服務，B服務由于壓力大需要擴容，會有哪些影響呢?
- B自己內部的狀態變化，如果B服務是有狀態的，擴展起來可能會設計到數據的遷移等操作，如果B是無狀態的，理論來說可以很方便的橫向擴展
- B的擴容對A或者其他依賴于B的系統有什么影響，依賴方能否做到自動適配，而不必修改任何配置
和進程內函數調用不同，進程間的通信需要通訊協議的支持，最常見的RPC調用都是基于TCP協議，Restfull基于http協議，使用這些協議底層都需要指定明確的IP和端口。所以需要某種解決方案在被依賴方擴展的時候，依賴方能夠得到感知。聰明的你可能想到了“注冊中心”，不錯，這也是注冊中心最主要的職責。
解決方案2
用注冊中心的方式，理論上屬于通知依賴方的方案，在依賴方感知被依賴方有擴展變動的時候，需要作出對應的變化。與之對應的其實我們也可以把變動封裝在被依賴方，這個時候就引入了以下代理模式，最常見的就是網關模式。
分布式系統使用網關到底是好還是壞?
其實代理模式非常常見，比如Nginx做反向代理，數據庫的中間件。這些設施都是對依賴方透明的，依賴方不會因為被依賴方實施了擴展而受影響。
解決方案3
目前很多業務下有一種很常見的場景，依賴方和被依賴方通信并不需要知道執行結果，最典型的場景像：新用戶注冊給用戶發歡迎郵件或者短信歡迎語。如果業務代碼中冗余了發郵件或者短信的代碼的話，一旦要添加新的歡迎方式就必須要修改業務代碼，無論你是否有抽象層，為了不影響主要的業務又最大化解耦系統，一般都會把這種非主要業務通過消息的方式分離出來。最常見的解決方案就是MQ。這也是典型發布訂閱模式，但是這種模式如上所說，調用方并不能實時的得到業務處理結果。
利用MQ來進行系統的解耦，來實現系統的高可擴展是一種非常常見的方式，優勢有很多，我不再闡述，但是需要注意消息的可靠性，因為消息經過了幾個環節之后，難保某個環節出現問題而丟失消息。
寫在最后
A和B之間的通信如果只是單向的話，可以理解為上下級關系，但是在微服務情況下，A和B很多時候是平行的互相調用的兄弟關系。有的架構師不贊成平行關系的微服務互相調用，這是有一定道理的，因為這很容易造成復雜的網絡調用模式，如果是符合MQ消息的形式通信，我也推薦首推利用MQ來解耦服務間的依賴。
高可擴展性系統的最終目標是在應對業務變化的時候，用最小的代價去實現。而如何實現系統的擴展性，并非只有以上所說的“面向接口編程”，利用MQ這些方式，你還知道哪些可以幫助系統擴展的解決方案嗎?歡迎你給我留言!!
“只要一提到解耦，有的“高手”一上來就說利用MQ，真的對嗎?如果調用方需要實時的業務處理結果呢?
本文轉載自微信公眾號「架構師修行之路」，可以通過以下二維碼關注。轉載本文請聯系架構師修行之路公眾號。
