從哪些方面擴展你的系統 - 系統性能擴展立方體

在上一篇文章《分佈式系統的構建原則》中總結了分佈式系統的幾個原則，擴展性是其中很是重要的一個原則，而對於擴展性則是咱們工程團隊多年以來不懈的追求，因此，咱們單獨展開，寫一寫有關擴展性的內容。

在各類不一樣的領域中，深耕的組織和團隊都不約而同的嘗試、發現和總結軟件架構模式，最後都類似的得出共同的軟件架構特徵，你們都但願系統更健壯、具備適應能力、更好的知足現代化的需求。
而這些特徵其實背後無疑都指向一個共同的很是重要的實現原則，擴展性！

擴展性從不一樣的角度大體能夠分爲 功能擴展性 和 性能擴展性 ，

功能擴展，

1. 系統是否能方便靈活的增長新功能，或者新的實現，能讓你的系統更快的響應需求的變化，大神們在實踐中總結出來的各類設計模式基本上都是爲了解決這個問題，響應變化；
2. 功能之間鬆耦合，非強依賴，有必定的容錯和降級能力，組件相互隔離，失敗的擴散控制的組件內部，可以獨立恢復，保證部分失敗，不會阻斷系統的可用性。

其實回頭想一想，計算機，操做系統在這方面設計和抽象的很是有遠見，馮諾依曼對計算機抽象的5個部分，相對都能作到獨立工做、獨立擴展、獨立恢復，例如現代化的Internet、USB、Type-C等都是被兼容的設備，你們都屬於input/output，而在大部分狀況下，一些擴展的設備發生故障，整個計算機仍是能夠繼續工做。

馮諾依曼1945年的論文《First Draft of a Report on the EDVAC》提出的計算機架構，可以適應上百年甚至更久，不得不說這是一種偉大的設計！

假如你可能要問，若是CPU壞了呢，計算機還能工做嗎？
你能夠試想一下，想象一臺更大的計算機，某個CPU組成的計算機多是整個大型計算機的一個input或者output呢？

 

性能擴展，

當今，流量紅利爆發，特別是To C的系統，上線後，性能每每會成爲公司和開發團隊關注的焦點。
功能方面能不能方便擴展，追的上需求的發展，是工程團隊首要考慮的，而上線之後能不能扛得住流量的考驗則是老闆和投資人比較關注的，
那咱們來討論一下如何提高系統的吞吐量，保證SLA。

在負載均衡下部署多個系統實例，運行多個程序副本，是擴展性能最直接的辦法，《The Art of Scalability》中文名《架構即將來》一書中談到擴展模型，包括X-axis、Y-axis、Z-axis三個緯度進行擴展，提高系統的吞吐量，而多實例這個方法被稱爲是橫向擴展，即：X-axis。
這個模型叫作擴展立方體（Scale Cube），比較符合微服務盛行的當下，讓擴展更具備針對性。

 

 

 

X-axis scaling

由多個程序副本同時運行，組成一個集羣，由負載均衡統一調度分配流量，例如，一個系統由N個副本同時工做，那每一個副本處理的流量爲 1/N，在擴展性方面，這是一個簡單，有效的方案，咱們一般稱爲橫向擴展，或者水平擴展。

簡單的辦法，每每會損失一些細節和靈活性，總結下來有三個缺點，

1. 沒法局部擴展，每一個系統副本有相同的要求，這就須要咱們投入更多的資源，每一個系統須要配比相同的配置，包括服務器和數據庫等；
2. 沒法局部恢復、問題修復代價比較大，須要更新全部系統副本，會形成必定概率的服務不可用；
3. 系統的複雜性沒有解決，其實就是康威定律，隨着系統不斷的開發，系統的複雜性也會不斷的升高，增長CICD的難度，和部署週期。

Y-axis scaling

水平擴展是整個系統多副本運行，平分流量從而提高總體性能，而Y-axis擴展是對這個服務進行拆分，讓一個大的系統裂變爲多個小服務，獨立部署，讓擴展更具針對性。
拆分的指導思想是把職責相關的功能拆分爲一個服務，相似單一職責原則，通常有基於動詞和基於名詞倆種拆分方法，例如上傳文件服務是基於動詞拆分出來的服務，用戶管理則是基於名詞的拆分。
這樣一來，水平擴展的幾個問題都被解決了，結合X-axis，能夠局部擴展，局部更新。

其實，這就是微服務。

Z-axis scaling

上面倆個都是基於服務級別的擴展，它們可能面臨同一個問題，卻沒法經過以上倆種擴展方案去解決，是服務所依賴的數據庫的性能問題。
因此，Z-axis就派上用場了，數據分區。
若是說Y-axis是對服務的職責單一化，那Z-axis是對數據庫的職責單一化，部署多個數據庫服務，在業務層，也就是服務層，對這些數據庫進行邏輯分類使用，例如，VIP用戶和普通用戶使用不一樣的數據庫，不一樣地區的用戶數據存儲在不一樣的數據庫等等，分散存儲，以減輕數據庫的壓力。
若是須要查詢或者排序的話，就須要訪問全部數據庫，獲得聚合結果，而後在服務層作合併處理。
注意，數據拆分會增長系統的複雜度，事務和數據遷移或重新分配都是比較棘手的問題，固然，咱們能夠藉助一些成熟的方案甚至數據庫系統來化解，但要求咱們深諳數據拆分之道。

其實，這就是分庫分表，或者分佈式數據庫的應用場景。

小結

擴展立方體，給咱們擴展系統提供了思路，須要咱們根據本身系統的實際架構和壓力狀況來衡量並制定合適的擴展方案，並非X、Y、Z都要用上。
再者，這個模型也是宏觀指導，影響一個系統的性能包括CPU、內存、IO（網絡、磁盤）等諸多因素，須要咱們像個老中醫同樣，經過望聞問切等多種手段，定位系統性能瓶頸，而後採起有效的擴展措施，例如，若是一個系統是網絡IO密集型，瓶頸在於基礎設施網絡，這種狀況下，你如何擴展也起不到效果，可能須要
的是升級硬件、提升網絡利用率、壓縮input、output、採用異步流傳輸、縮短調用鏈、改變交互方式（響應式、異步、非阻塞）等措施，才能真正解決痛點。

但若是是一個大型系統，面臨性能問題，按照Scale Cube模型，總體擴展思路總結一下大概是，先垂直拆分、後水平擴展，包括服務拆分，數據庫拆分，拆分原則是職責單一，用動詞或名詞拆分法，而後對服務和數據庫根據壓力狀況，適當的水平擴展。

參考

1. https://microservices.io/articles/scalecube.html

原文出處：https://www.cnblogs.com/xguo/p/10551950.html