網站的可擴展架構

1、可伸縮與可擴展—傻傻分不清楚

　　上篇筆記咱們學習了可伸縮架構，但在實際場合中，包括許多架構師也經常混淆可伸縮和可擴展，用可擴展表示伸縮性。那麼在此，跟隨做者咱們來理清這兩個概念，避免咱們之後對其傻傻分不清楚。

　　（1）擴展性（Extensibiltiy）

　　指對現有系統影響最小的狀況下，系統功能可持續擴展或提高的能力。咱們不由想到了面向對象中一大原則：開閉原則，對擴展開放，對修改封閉。也就說，當系統新增一個功能時，不須要對現有系統的結構和代碼進行修改。

　　（2）伸縮性（Scalability）

　　指系統可以經過增長（或減小）自身資源規模的方式加強（或減小）本身計算事務的能力。在網站架構中，一般是指利用集羣的方式增長服務器數量，從而提升系統的總體事務吞吐能力。

　　設計網站可擴展架構的核心思想是：模塊化，並在此基礎之上下降模塊間的耦合，提升模塊的複用性。在大型網站中，這些模塊經過分佈式部署的方式，獨立的模塊部署在獨立的服務器（集羣）上，從物理上分離模塊之間的耦合關係，進一步下降耦合性從而提升複用性。

2、利用分佈式消息隊列下降系統耦合性

　　上面咱們提到說要分離模塊之間的耦合，若是模塊之間不存在直接調用，那麼新增模塊或者修改模塊就對其餘模塊的影響最小，這樣系統的可擴展性無疑會更好一些。那麼，有沒有一種架構是基於如此考慮而設計的呢？因而，咱們將眼光轉向一個名叫「事件驅動」的架構。

2.1 事件驅動架構

　　根據事件驅動架構（Event Driven Architecture）的定義：經過在低耦合的模塊之間傳輸消息，以保持模塊的鬆散耦合，並藉助事件消息的通訊完成模塊間合做。典型的EDA架構就是操做系統中常見的生產者消費者模式。在大型網站架構中，具體實現手段有不少，可是最多見的是分佈式消息隊列。

　　如上圖所示，消息隊列利用發佈—訂閱模式工做，消息發送者發佈消息，一個或多個消息接受者訂閱消息。消息發送者是消息源，在對消息進行處理後發送至分佈式消息隊列，消息接收者從分佈式消息隊列獲取該消息後繼續進行處理。能夠明顯看出，發送者與接受者之間沒有直接耦合，消息發送者只需將消息發送給分佈式消息隊列即操做結束，而消息接受者也只須要從分佈式消息隊列獲取消息後進行處理，不須要知道該消息從何而來。所以，對於新增業務，只要對該類消息感興趣，便可訂閱該消息，對原有系統和業務沒有任何影響，從而實現網站業務的可擴展設計。

2.2 分佈式消息隊列

　　隊列是一種先進先出的數據結構，分佈式消息隊列則看以看做是將這種數據結構部署到獨立服務器上，應用程序看以經過遠程訪問接口使用分佈式消息隊列，進行消息存取操做，進而實現分佈式的異步調用。

　　如上圖所示，咱們能夠明確三個步湊：

　　①消息生產者應用程序經過遠程訪問接口將消息推送給消息隊列服務器，消息隊列服務器將消息寫入本地內存隊列後立刻返回成功響應給消息生產者。

　　②消息隊列服務器根據消息訂閱列表查找訂閱該消息的消費者應用程序，將消息隊列中的消息按照先進先出的原則將消息經過遠程通訊接口發送給消費者應用程序；

　　③消費者應用程序接收到推送過來的消息以後進行相關的一系列處理，過程終止；

PS：那麼，有沒有這樣一種狀況：消息隊列服務器宕機後致使消息丟失。事實上，這種狀況的確存在於實際的運維過程當中。那麼，咱們如何來避免呢？這時，做者給出了一個方案：若是消息隊列服務器宕機形成消息丟失，會將消息成功發送到消息隊列的消息存儲在消息生產者服務器，等消息真正被消息消費者服務器處理後才刪除消息。在消息隊列服務器宕機後，生產者服務器會選擇分佈式消息隊列服務器集羣中其餘的服務器發佈消息。

另外，有關於分佈式消息隊列的實踐能夠採用NoSQL產品來構建，例如Redis就提供了隊列數據類型，能夠方便地構建分佈式消息隊列，若是你有興趣，也能夠參閱個人另外一篇博文：《使用Redis做爲消息隊列服務應用場景案例》

3、利用分佈式服務打造可複用的業務平臺　　

　　若是說分佈式消息隊列經過消息對象分解系統耦合性，不一樣子系統處理同一個消息；那麼分佈式服務則經過接口分解系統耦合性，不一樣子系統經過相同的接口描述進行服務調用。

3.1 巨無霸的應用系統帶來的問題

　　網站由小到大的演化過程當中，表現爲整個網站是由單一系統逐步膨脹發展變化而來的，隨着網站功能的日益複雜，網站應用系統會逐漸成爲一個巨無霸，以下圖所示。能夠看出，一個應用中聚合了大量的應用和服務組件，這個巨無霸給整個網站的開發（編譯麻煩、代碼分支管理困難）、維護（新增業務困難）和部署（部署困難）都帶來了巨大的麻煩。

3.2 拆分，拆分仍是拆分

　　解決方案仍是咱們屢次提到的拆分，將模塊獨立部署，下降系統耦合性。拆分又分爲：橫向拆分和縱向拆分。這裏咱們再次回顧一下這兩種方式：

　　（1）縱向拆分：將一個大應用拆分爲多個小應用，若是新增的業務較爲獨立，那麼就直接將其設計部署爲一個獨立的Web應用系統；

　　（2）橫向拆分：將能夠複用的業務拆分出來，獨立部署爲分佈式服務，新增業務只須要調用這些分佈式服務便可，不須要依賴於具體的模塊代碼。若是模塊內業務邏輯發生變化時，只要接口保持一致就不會影響業務程序和其餘模塊。

4、可擴展的數據結構

　　傳統的關係數據庫爲了保證關係運算（經過SQL語句）的正確性，在設計表結構的時候就須要制定表的Schema—字段名稱、數據類型等，還要遵循制定的設計範式（例如：1NF、2NF、3NF等等）。這些規範帶來的一個問題就是僵硬的數據結構難以面對需求變動帶來的挑戰，有些系統設計者經過預先設計一些冗餘字段來應付（在我所實習的一年裏，我見過不少次這種設計，雖然能夠解決問題，但從設計學來講，真的好Shit），但這顯然是一種糟糕的數據庫設計。

　　那麼，有木有辦法可以作到可擴展的數據結構設計呢？是否能夠不須要修改表結構就能夠新增字段呢？答案是確定的，目前許多NoSQL數據庫使用的ColumnFamily（列族）設計就是一個解決方案。ColumnFamily最先在Google的BigTable中使用，這是一種面向列族的稀疏矩陣存儲格式。或許這麼說你們仍是不明白，但能夠經過下圖來理解：

　　這是一個學生基本信息表，不一樣學生的聯繫方式不一樣，選修的課程也不一樣，並且在未來會有更多的聯繫方式和課程加入這張表，若是按照傳統的數據庫設計，不管提早預設多少冗餘字段都不夠用，捉襟見肘，疲於應付。而是用ColumnFamily結構的NoSQL數據庫，建立表的時候，只須要指定ColumnFamily的名字，無需指定字段（Column），能夠在數據寫入時再指定，經過這種方式，數據表能夠包含數百萬的字段，使應用程序的數據結構能夠隨意擴展。

5、利用開放平臺建設網站生態圈

　　網站的價值在於爲他的用戶創造價值，大型網站爲了更好地服務本身的用戶，會開發更多的增值服務，會把網站內部的服務封裝一些調用接口開放出去，供外部的第三方開發者使用，這個提供開放接口的平臺被稱做開放平臺。第三方開發者利用這些開放的接口開發應用程序（APP）或者網站，爲更多的用戶提供價值。這樣一來，網站、用戶、第三方開發者相互依賴，造成一個網站的生態圈，即爲用戶提供更多的價值，也提升了網站和第三方開發者的競爭能力和盈利能力。

　　目前BAT等國內互聯網巨頭都建設有本身的開放平臺，力圖利用本身龐大的用戶羣吸引第三方開發者，打造一個更加龐大的航母戰鬥羣，在市場競爭中呼風喚雨，立於不敗之地。