互聯網時代，我眼中的架構變遷

互聯網在變，架構也在變，架構的變遷亦是互聯網的變遷。因此，咱們有必要來聊聊互聯網的架構及其變遷。

何爲架構？往大的說，宇宙有架構，社會有架構，往小的說，建築要有架構，軟件要有架構，往玄乎的說，它由分工而來，迴歸總體而去，往實際的說，架構的核心就是爲了解決問題，包括業務的問題、人的問題。

立足互聯網行業，架構一般指的是技術架構，更具體一點的說是系統架構、軟件架構，或者是最多見的網站架構。本文就來探討一下互聯網時代，技術架構的演進過程及其優缺點，其中如有不足之處，還望指正，促進交流。

爲了方便表述，我姑且的把互聯網的架構演進過程分爲三個時代：單機時代、集羣時代和分佈式時代。三個時代並不是按照歷史時間順序排列，更多的是由團隊或產品所處的時期來決定。

單機時代

互聯網早期，比如杭研某個產品團隊初創之時，資源有限，人力不足，爲了快速開發一個產品，或上線一個網站，單機每每是一個不錯的選擇，此時會將應用程序、文件服務、數據庫服務等資源集中在一臺 Server 上。其中應用程序一般總體打包和部署，具體格式依賴於應用的語言和框架，例如 Java 的 WAR 文件、Rails 的目錄文件，此種架構一般稱爲單體架構。

單體架構

其系統架構圖每每長這個樣子：

 

 

圖-1: 單機時代-ALL IN ONE

優勢：如上文所述，簡單快速，易於開發，易於測試，易於部署
缺點：也很是顯著，只適合早期項目，變大後不易維護，且存在單點，升級須要停服

分層架構

明眼的人很快發現，此時的應用程序架構顯得雜亂無章，這在早期的 Web 開發中可能存在，好比使用 JSP+JDBC，ASP+ADO，但這顯然不是一個友好的標準架構，因而分層架構應運而生，分層架構以下圖所示，通常分爲表現層（presentation）、業務層（business）、持久層（persistence）和數據庫（database）。這其實也是最多見的 MVC 架構了。

 

 

 

圖-2: 單機時代-軟件架構-分層架構

改造以後的系統架構圖以下：

 

圖-3: 單機時代-分層架構

• 優勢：結構簡單，分工明確，分層測試，若是你不知道用什麼軟件架構時，推薦用它

• 缺點：擴展性差，迭代開發效率低，有時候層次過多致使流程複雜
  數據分離

添加了分層架構，應用上好看點了，團隊的開發效率有了必定的提高。此時業務量進一步增大，而且有了必定的用戶規模，逐漸發現一臺主機上應用和數據資源爭奪的很是厲害。由於每種服對硬件資源的要求是不一樣的，應用服務器須要更快的CPU，文件服務器須要更大的硬盤，數據庫服務器須要更大的內存和硬盤，因而決定把應用和數據服務分離，造成了以下架構：

 

 

圖-4: 單機時代-數據分離

• 優勢：資源分散，提升不一樣服務對硬件的利用率，方便維護

• 缺點：增長了資源消耗和網絡開銷，同時還存在單點

緩存登場

產品有了必定的口碑，用戶量持續增加，訪問開始頻繁，想提高訪問速度，緩存必不可少，閃亮登場。

 

圖-5: 單機時代-緩存登場

服務端緩存又能夠分爲本地緩存和遠程緩存，各有優劣，本地緩存訪問速度快，但數據量有限，並且後續集羣化不方便共享；遠程緩存能夠共享，能夠集羣，容量不受限制，但要注意緩存更新的問題。

• 優勢：簡單有效，減小對 DB 的查詢

• 缺點：增長邏輯判斷，不適合存儲大對象，此架構一樣有單點

讀寫分離

市場反響不錯，業務也在持續增加，但性能又有所降低，分析整個架構，發現數據庫讀寫很是頻繁，甚至有些業務，讀大於寫，單臺數據庫服務器又成了瓶頸，此時就能夠嘗試作讀寫分離和主從複製了。

圖-6: 單機時代-讀寫分離

• 優勢：下降數據庫單臺壓力，從機的數量能夠靈活變動

• 缺點：架構開始變得複雜，維護難度加大

自此，單機時代的架構已然成型，「麻雀雖小五臟俱全」，初期已經能很好的支撐業務的運轉。但隨着業務的增加，各個模塊仍是可能出現瓶頸。而單機時代最大的問題，就是整個架構都存在單點，這個問題將在集羣時代一一解決。

集羣時代

單機時代，作了很多措施來緩解數據庫層的壓力，包括服務器分離、引入緩存、數據分離等，但隨着訪問量的猛增，對高可用的要求愈來愈高，減輕應用層壓力、解決單點問題是當務之急，這就是集羣時代須要作的事情。

負載均衡

代碼是架構的基礎，但前期改造代碼的工做量較大，若是人員變更頻繁，那風險就更高了，因此提升服務器性能，經常使用的手段仍是先將應用集羣化，作負載均衡。

 

圖-7: 集羣時代-負載均衡

• 優勢：去除應用層單點，可用性獲得保證，性能有所提升

• 缺點：這時要注意應用之間的一致性問題，好比對緩存的訪問，對Session的存儲

 

 

動靜分離

 

但願進一步下降應用服務器的壓力，能夠採用動靜分離技術。

動靜分離是讓動態網站裏的動態網頁，根據必定規則把不變的資源和常常變的資源區分開來，動靜資源作好了拆分之後，咱們還能夠根據靜態資源的特色將其作緩存操做，以加快響應速度。

在杭研內部，經常使用作法還會將先後端分離，後端應用提供 API，根據前端的請求進行處理，並將處理結果經過JSON格式返回至前端

 

圖-8: 集羣時代-動靜分離

• 優勢：減輕應用服務器壓力，緩存靜態文件，加快響應速度，先後端分離，開發能夠並行。

• 缺點：靜態文件緩存更新失效問題，先後端溝通成本提升

CDN 加速

內容分發網絡（Content Delivery Network），簡稱 CDN），能夠進一步加快網站相應，其原理是將源內容同步到全國各邊緣節點，配合精準的調度系統，將用戶的請求分配至最適合他的節點，使用戶能夠以最快的速度取得他所需的內容。

 

圖-9: 集羣時代-CDN 加速

• 優勢：解決網絡帶寬小、用戶訪問量大、網點分佈不均等問題，提升用戶訪問的響應速度，減輕應用負載壓力。

• 缺點：顯然成本上去了，CDN服務通常是按流量計費，同時也存在靜態文件緩存更新失效問題。

冗餘集羣

以上一個中型網站架構基本成型。當中型網站繼續向大型網站演進，最終的目標是要保證「三高」：高併發、高性能、高可用。以上架構基本能夠知足性能需求，接下來更多的是關注「高可用」，確保「無單點」。

此時，就要對關鍵的服務，作冗餘集羣負載。

理想狀況下，咱們將如下服務/應用都集羣化：

• 數據庫服務集羣

• 文件服務集羣

• 緩存服務集羣

• 應用服務集羣

• 負載均衡調度器集羣

• 靜態內容服務集羣

• CDN服務器集羣

 

圖-10: 集羣時代-冗餘集羣

• 優勢：去單點，高可用

• 缺點：數據有狀態問題、數據一致性問題，資源成本、人力維護成本都上去了

到此爲止，一個大型網站的架構也基本成型了，能「加機器」的地方都加完了，是否是就終結？固然不是！伴隨着 DT/分佈式 時代的到來，大流量和大數據的場景的出現，對應用提出了更高的要求，接下來就須要對應用程序開刀了。

分佈式時代

應用拆分

在前面，咱們只是把應用程序作了分層架構，在創業初期或產品前期仍是一個不錯的選擇。雖然應用也作了集羣和負載均衡，但應用架構層面仍是「集中式」的。隨着業務愈來愈複雜，網站的功能愈來愈多，應用拆分勢在必行了。

• 優勢：應用解耦，分拆團隊負責，分而治之

• 缺點：架構變複雜

應用拆分以後，還伴隨着一個相互依賴、公共模塊的問題，特別是依賴於相同的邏輯或功能代碼。這時就能夠考慮將這些共用的服務提取出來，獨立部署，統一治理，提升重用度，這就是面向服務的架構（service-oriented architecture，縮寫 SOA）了。

消息隊列

應用拆分、服務獨立部署以後，仍是會出現一些通訊或依賴問題，這時就能夠引入消息隊列，提升吞吐量。

• 優勢：異步、解耦，提升吞吐量

• 缺點：消息消費延遲等問題

數據分庫

應用拆分以後，DB分庫理所固然，不然多個應用鏈接在單個數據庫上，鏈接數、QPS、TPS、I/O處理能力都很是有限。

• 優勢：DB分壓，下降耦合

• 缺點：數據訪問模塊冗餘、複雜

提到分庫，很多人會想到分表，這一塊我並未實踐過，很差下筆。但想來會引入更復雜的數據架構和數據一致性問題，並且市面身上成熟開源的分庫分表方案並無，保不許又是一個深坑。拆或不拆，也是一個值得思考的問題。

微服務架構

微服務架構（microservices architecture）一度成爲熱點，在文章、博客、大會演講上常常被說起。微服務並非憑空出現，有人說，它是面向服務的架構（SOA）的升級，在此以前，還有諸如集中式架構、分佈式的架構等。這裏借用一副抽象的圖來描述下常見的幾種架構：

圖-11: 分佈式時代-微服務架構-抽象對比

微服務架構由多個微小服務構成，每一個服務就是一個獨立的可部署單元或組件，它們是分佈式的，相互解耦的，經過輕量級遠程通訊協議（好比REST）來交互，每一個服務可使用不一樣的數據庫，並且是語言無關性的。它的特徵是彼此獨立、微小、輕量、鬆耦合，又能方便的組合和重構，猶如《超能陸戰隊》中的微型機器人，個體簡單，但組合起來威力強大。

圖-12: 分佈式時代-微服務架構

• 優勢：擴展性好，服務之間耦合性低，服務間相互獨立，容易部署，易於開發，方便測試每個服務

• 缺點：容易過分關注服務的大小，可能拆分的很細，致使系統依賴於大量的微服務，而服務之間的相互通訊也會變得複雜，系統集成複雜度增長，很難實現原子性操做。

微服務之因此這麼火，另外一個緣由是由於 Docker 的出現，它讓微服務有一個很是完美的運行環境，Docker 的獨立性和細粒度很是匹配微服務的理念，Docker的優秀性能和豐富的管理工具，讓你們對微服務有了必定的信息，歸納來講 Docker 有以下四點適合微服務：

• 獨立性：一個容器就是一個完整的執行環境，不依賴外部任何的東西。

• 細粒度：一臺物理機器能夠同時運行成百上千個容器。其計算粒度足夠的小。

• 快速建立和銷燬：容器能夠在秒級進行建立和銷燬，很是適合服務的快速構建和重組。

• 完善的管理工具：數量衆多的容器編排管理工具，可以快速的實現服務的組合和調度。

固然，好的架構和技術，要應用於實踐、讓用戶承認才行，這就須要在微服務架構和 Docker 技術之上有豐富的場景化應用。網易蜂巢也在積極探索微服務架構和容器雲平臺的場景化服務，歡迎一塊兒來實踐落地。

至此，架構變遷的三個時代介紹完成。總的來講架構不是一成不變的，時間不停，進步不止，人如此，架構依然。