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

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

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

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

單機時代

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

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

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