概述
隨著互聯網的發展，網站應用的規模不斷擴大。需求的激增，帶來的是技術上的壓力。互聯網系統架構也因此也不斷的演進、升級、迭代。從單一應用，到垂直拆分，到分布式服務，到SOA，以及現在火熱的微服務架構等，還有在google帶領下來勢洶涌的Service Mesh。
作為一名合格的架構師，有必要對架構的前世今生足夠了解，這樣方能把握現在，預見未來。下面一起看一看互聯網系統架構演變的歷程。
單體系統架構
這是最傳統最原始的站點系統架構，互聯網開啟之初常用的架構。單體系統一般功能與流量都很小，只需一個應用，將所有功能都集中在一個系統中，并部署在一臺服務器上，以減少部署節點和成本。例如，將用戶模塊、問答模塊、考試模塊等都做在一個系統中，以一個應用的形式部署在一臺服務器上。
單體系統架構
集群架構
當站點流量增加而一臺主機已無法應對其訪問量時，可通過搭建集群增加主機的方式提升系統的性能。這種方式稱為水平擴展。
集群架構
分布式架構
當站點訪問量逐漸增大，集群架構的水平擴展所帶來的效率提升越來越小。此時可以將項目拆分成多個功能相對獨立的子系統以提升效率。例如用戶系統、問答系統、考試系統等。這種稱為垂直擴展。
分布式架構
微服務架構
當子系統越來越多時， 發現它們可能同時都擁有某功能相同或相似的模塊，于是將這些在整個項目中冗余的功能模塊抽取出來作為獨立的系統，這些系統就是專門為那些調用它們的系統服務的。那么這些抽取出的功能就稱為微服務，微服務應用稱為服務提供者，而調用微服務的應用就稱為服務消費者。這樣的系統架構就是微服務架構。
微服務架構
流動計算架構
隨著功能的擴張，微服務就需要越來越多；隨著 PV 的增漲，消費者系統就需要越來越多；隨著消費者的擴張，為其提供服務的提供者服務器就需要越來越多，且每種提供者都要求創建為集群。這樣的話，消費者對于提供者的訪問就不能再采用直連方式進行了，此時就需要服務注冊中心了。提供者將服務注冊到注冊中心，而消費者通過注冊中心進行消費，消費者無需再與提供者綁定了。提供者的宕機，對消費者不會產生直接的影響。
隨著服務的增多，在一些特殊時段（例如雙 11）就會出現服務資源浪費的問題：有些服務的 QPS 很低，但其還占用著很多系統資源，而有些 QPS 很高，已經出現了資源緊張，用戶體驗驟降的情況。此時就需要服務治理中心了。讓一些不重要的服務暫時性降級，或為其分配較低的權重等，對整個系統資源進行統一調配。
于是便產生了流動計算架構，它是一種高可用、高性能、可伸縮的分布式微服務架構。
這里的資源調配分為兩種：預調配與實時調配。
預調配是根據系統架構師的“系統容量預估”所進行的調配，是一種經驗，是一種預處理，就像每年雙 11 期間的 PV 與 UV 都會很高，就需要提前對各服務性能進行調配。
實時調配指的是根據服務監控中心所提供的基于訪問壓力的實時系統容量評估數據，對各服務性能進行實時調配的方案。
流動計算架構
總結
架構并不是已成不變的，隨著業務和技術的發展，不同的需求會催生不同的架構，不同的架構使用不同的業務場景。架構沒有最好，重要的是合適業務需求，符合使用的場景就好。
