網際網路在變，架構也在變，架構的變遷亦是網際網路的變遷。所以，我們有必要來聊聊網際網路的架構及其變遷。

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

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

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

單機時代

網際網路早期，好比杭研某個產品團隊初創之時，資源有限，人力不足，為了快速開發一個產品，或上線一個網站，單機往往是一個不錯的選擇，此時會將應用程式、檔案服務、資料庫服務等資源集中在一臺 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 技術之上有豐富的場景化應用。網易蜂巢也在積極探索微服務架構和容器雲平臺的場景化服務，歡迎一起來實踐落地。

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