架構設計的立方體擴充套件

小飛鶴發表於2017-09-14
架構套件

轉自：http://blog.csdn.net/houjixin/article/details/53675741


本文是對《架構即未來》一書第20章的總結； 

1. 立方體擴充套件是指X、Y、Z軸三個方向的擴充套件方式； 
2. X軸擴充套件，指水平擴充套件，這種方式簡單易於實現，它要求服務必須是無狀態的，部署1個和部署多個是一樣的，這樣可以根據系統當前的業務承載量來部署所需數量的服務例項，一般情況下，該業務需要與服務註冊、治理、發現機制相結合，當一個服務A被水平擴充套件了一個新例項ai時，所依賴它（呼叫了它）的其他服務C需要能及時的發現這個新起來的ai，並且能把自己的對A的其他例項的呼叫分出來一部分到ai上，這種負載均衡機制一般有兩種實現方式： 
（1） 在呼叫方程式中整合服務發現和負載均衡功能；如下圖所示，這種方式實現負載，對呼叫方有影響，因為呼叫方在使用服務時還要整合它的服務發現和負載均衡相關功能模組。 
這裡寫圖片描述 
（2） 將服務發現和負載均衡做到中間代理中；這種方式所有的請求操作都是經過代理進行轉發，當被呼叫服務A進行擴充套件時，由負載均衡器發現並連線到新啟動的A服務例項，這些動作對於呼叫方C來說都是透明的；這種方式相對於第一種方式，會有一點效能損失。能起這種負載均衡作用的開源軟體包括lvs，nginx（第四層負載均衡功能）； 
這裡寫圖片描述 
3. Y軸擴充套件，書中將Y軸擴充套件定義為按照交易處理的資料型別、交易任務或者兩者的組合進行任務分割的過程。可以簡單理解為將系統按照業務進行拆分，這就像工廠裡的工人，當工人的所幹的事情非常多時他什麼都幹不好，因此需要將工人進行分組，一部分人專門幹一樣事情；這裡的Y軸擴充套件也是類似，當系統或者業務變得複雜時，我們就需要按照業務將系統分佈不同的模組，每個模組專門幹一件或一組相關聯的業務，Y軸拆分之後，每個被拆分出來的服務完成一個獨立的子功能或者子業務；例如一個系統原來有AC兩個子功能組成，所有需要A和C功能的請求都會落到該系統上，隨著業務量的增長，該系統被分為了A系統（完成A功能）和C系統（完成C功能），所有需要A功能的請求都被轉到了A服務上，所有需要C功能的請求都被轉發到了C服務上，從而實現對原系統的擴充套件。 
4. Z軸擴充套件，Z軸擴充套件可以按照兩個方向去理解：（1）特殊人物要特殊對待，例如微博中，普通使用者和那些大V的訪問量時嚴重的不一樣，當某個大V發表一個言論是，可能對在短時間內造成很大的壓力，這個時候我們就可以把這些特殊的資料單獨拉出來處理，這樣他們訪問量大的時候對別的使用者的訪問就不會受到影響；（2）將使用者分組，還是以微博為例，當使用者量比較少的時候，可能一個服務配合一組快取和資料庫就能應付所有使用者，當使用者量、訪問量增大時，就需要將使用者進行拆分，將一部分使用者，例如按照ID取模將使用者分到不同的服務中，這樣系統的承載量就會增加； 
5. 立方體擴充套件中，比較難以理解的是Y軸擴充套件和Z軸擴充套件的區別，書中的介紹讓跟感覺很混亂。根據個人理解，可以通過下面的例子進行理解區分： 
例如我們在設計一個類似qq或者微信的IM服務時，需要構建一個使用者資訊系統，該系統用於管理使用者的個人資訊（例如使用者的賬號、暱稱、註冊時間、手機號、郵箱等等）、好友關係和群組關係，當我們的使用者量非常小的時候，可以將這些資訊和操作都放在一個服務中完成，隨著訪問量的增加，我們很快就發現現有的服務（包括請求處理和資料的存取）已經扛不住訪問量，這時候我們就考慮將系統查分為兩個服務：使用者資訊服務和使用者關係服務，使用者資訊服務管理（包括儲存）使用者個人資訊，使用者關係服務管理（包括儲存）使用者關係（包括好友關係和群組資訊），這個拆分就是Y軸拆分，它是按照業務的不同進行的拆分；隨著使用者量的繼續增長，我們發現使用者資訊服務又扛不住了，包括訪問量和儲存，這時候我們就需要再次對使用者資訊服務進行拆分，假設我們想把使用者資訊服務拆分為10個子服務，第i個子服務負責取模後為i的使用者的請求，拆分時按照使用者ID對10取模，然後將對應的使用者分到0~9個使用者資訊服務中，例如ID為1000153的使用者訪問使用者資訊服務時它的請求將會被分到第3個子服務中，這個拆分動作就是Z軸拆分。

相關文章