多終端接入、開放平臺給網際網路帶來了前所未有的用戶量級和訪問規模，SNS網站產生了海量的UGC（用戶產生內容），而且這些內容依託關係鏈擴散速度之快、傳播範圍之廣是傳統網站難以想像的，海量數據的計算存儲也一直是近年網際網路領域的熱點。本文將從發展演進的層面探討網際網路的系統架構。
天下武功唯快不破
網站初期的架構一般採用「短平快」的架構思路，架構以簡單清晰、容易開發為第一衡量指標。
網際網路架構選型首先包括開發語言的選擇，目前PHP、Java是主力語言。開發語言的選擇一般從團隊人員的知識儲備、社區活躍度、商業應用的成熟度、招聘人才的人力成本等方面考量。
選擇語言之後，一般會選擇該語言的流行框架輔助研發，例如Java的SSH、Python的Django等。但這些框架並不是通常意義上的架構，架構一般可分為物理架構、運行架構、邏輯架構、開發架構、數據架構等多個維度，框架往往只是代碼架構的一部分。代碼架構是指代碼的組織形式、規範、設計模式等，框架其實是常用設計模式的軟體化。例如Struts是MVC模式的實現，Hibernate、iBATIS是ORM模式的實現。
在架構視圖中，早期關注的主要是開發視圖和數據視圖，一般數據存儲採用DB，初期數據的關注點主要是安全和備份，MySQL的Master-Slave模式可以滿足該需求。
雞蛋不要放在一個籃子裡
採用「短平快」三板斧將網站開發出來之後，急需解決的是網站的可用性問題。可用性最基本的要求是不能有單點，對程序節點而言，前端可採用LVS、HAProxy、Nginx等負載均衡/反向代理設備。
DB的可用性就複雜了很多，資料庫天然是有狀態的，狀態就是其中的數據，新增一個數據節點一般伴隨著大量的數據複製和遷移。對金融行業而言，昂貴的商用存儲是解決之道，「IBM+Oracle+EMC」是該類系統的標配。網際網路企業則一般採用較為廉價的方案，例如開源的DRDB+Heartbeat技術組合可以在MySQL主庫宕機時實現備機接管，接管時間可以控制在30秒內。
程序節點其實也可能存在狀態，例如Web服務中常用的Session就是保存在容器中的狀態，這種狀態保持要求所有相同用戶的請求都在同一臺機器上處理，無狀態的程序節點才能水平擴展。無狀態一般有兩種設計思路，還以Session為例，一種思路是把用戶的狀態保存在客戶端Cookie，每次請求都把客戶端的用戶信息帶到伺服器端，淘寶的分布式Session就是該思路的一種實現；另一種思路是狀態保留在另外一個服務中，例如有些公司將Session放在分布式緩存中。
性能是生命線
去除單點之後的系統就可以水平擴展，架構如圖1所示。但隨著網站的推廣運營，系統的規模開始擴大，此時可能會出現服務訪問緩慢，甚至不可用的狀況，如何提升系統性能就成了架構師的當務之急。
圖1 去除單點之後進行水平擴展
存儲架構和性能
網際網路系統所有的性能瓶頸中，數據存儲和訪問速度往往是最重要也是最難解決的，選擇合適的存儲是系統的關鍵。存儲的選擇一般需要從多個方面考量，如成本、內容、用途和模型。目前主流的存儲介質包括硬碟和內存兩種。
對機械硬碟來說，1秒可以完成150次左右的隨機I/O。而結合設計優良的Hash算法，內存查找可以每秒執行40萬次左右。硬碟的隨機讀寫能力決定了其讀寫的最差性能，但作業系統在實現文件系統時會把最近讀寫過的數據緩存在內存中。由於磁碟訪問和內存訪問性能量級的差距，從作業系統的Cache命中率就可以簡單計算文件存儲的性能，如果內存命中率可以達到80%，系統的I/O能力相較完全隨機I/O將有5倍提升。
對於數據層伺服器，大內存已成為標配（一般為100GB左右），如果DB中存儲200GB的數據，根據8/2原則，Cache命中率應為87.5%，因此對MySQL而言，一般讀寫可以達到每秒1千次以上。
對於讀寫頻率都很高、且可容忍數據丟失的場景，可以採用內存作為數據存儲的介質。可靠的內存存儲需要每次操作都記錄Biglog，即使數據丟失也可以恢復，同時內存中的數據一般定期持久化到硬碟。
從功能角度考量，還可以分為持久化存儲和Cache。持久化存儲也可稱為可靠存儲，Cache是為了提升系統性能，在可靠存儲的基礎上建立的訪問性能更加高效的數據讀取節點，通常是內存存儲，其架構一般如圖2所示。
圖2 持久化存儲和Cache
存儲的數據模型一般分為結構化存儲和NoSQL存儲。結構化存儲以各種傳統DB為代表，NoSQL技術的代表系統則有HBase、Memcached、Redis等。各種NoSQL系統雖然特性各異，但相對傳統DB而言，由於結構化信息的缺失，往往不能做各種關聯查詢，適用場景更多是主鍵查詢，而且一般是寫少讀多的系統。
對於大型網際網路公司，為了某些場景下的性能優化，也會定製個性化的文件系統，例如為了適應大文件存儲的場景，Google開發了GFS；為了更快讀取海量商品的描述圖片，TFS在阿里誕生。
雖然各類存儲快速湧現，但DB作為結構化數據的傳統存儲設備，依然在架構中處於非常重要的地位。由於隨機I/O的瓶頸，DB的性能天花板十分明顯。在大型系統中通常需要分庫操作，分庫一般有兩個維度——水平切分和垂直切分。水平切分一般根據主鍵規則或某種規則將同類數據切分到不同的單元表中，原則是數據切分均勻，尤其是熱點數據分布均勻。
垂直切分是把大表中的欄位拆分到多張表。垂直切分一般按照數據訪問頻率的不同。邏輯關係的差別進行切分，例如將大欄位、kv欄位、計數等高頻訪問欄位單獨剝離存儲都是常見的垂直切分方案。
除了切庫之外， MySQL的分表也會有效減少單表大小，使數據變得更簡單，甚至可以做到不下線變更，單表索引規模的下降也會帶來性能的提升。
分庫分表作為DB架構中重要的一環，使DB更加穩健，但它給業務代碼帶來了額外的複雜性，最好通過中間件來屏蔽DB的底層分布，對業務透明。
作為高性能網站必不可少的組件，Cache在各種主流架構中也起著重要的作用。
從部署模式上看，它可分為本地Cache和分布式Cache。本地Cache是指在應用進程中的Cache，通常的數據結構是一個MAP，其優點是結構簡單，效率較分布式Cache更高，缺點是一般應用程式伺服器的內存有限，導致本地Cache容量受到局限，而且數據冗餘度較高，每個應用伺服器都需要一份數據，更新比較煩瑣，一般採用超時刪除機制。
分布式Cache的容量較大，方便擴容和更新，其數據分布可採用一致性Hash算法，減少節點變化帶來的數據遷移。
引入Cache不可避免的問題是伺服器的宕機處理。Cache通常是一個集群，數據分布在多個節點，如果掛掉一個節點，只會影響部分數據，而且對於可靠性要求較高的系統，每個節點都可以有備份。
作為可靠存儲的數據備份，Cache在架構設計上往往承擔大部分讀訪問需求，其命中率尤為重要。Cache不命中有兩種情況，一是數據在Cache中不存在，二是在持久化存儲中也不存在。對於後者的頻繁訪問會導致請求直接壓在DB上，在設計時應儘量避免，可以通過維護Bitmap對持久化存儲中沒有的數據進行攔截，直接返回，也可以簡單地將這些數據對應空對象放進Cache。
Cache的存儲一般是將索引和數據分離，對於索引數據可以全量緩存，對於體量較大的數據一般採用部分緩存的方式。
Cache的使用場景有一定的局限，對於較為靜態的數據才有意義，這個臨界值一般是5分鐘。由於當前存儲技術的進步，Cache也可以用其他高性能的存儲介質代替，例如SSD的引入使得硬碟的隨機讀寫能力提升數十倍，也會使得Cache的重要性有所下降。
程序架構和性能
對一般的系統而言，程序邏輯的主要作用是調用各種數據訪問接口，該操作通常需要等待，所以除搜索等少數系統外，程序邏輯一般是非CPU密集型。該類系統中「線程」是稀缺資源，線程數和接口耗時構成了系統的QPS能力。
大型網際網路系統的QPS可能為幾萬甚至峰值達到幾十萬，此時增加機器可以解決問題，但這些機器的利用率其實很低，因為大部分時間是在等待，此時引入異步變得非常重要，異步在同樣的時間可以處理更多工作，擁有更好的性能。
圖3 同步調用和異步調用
利用Nio的多路復用方式可方便地實現異步系統，當然也可用協程令代碼更加清晰。業界流行的SEDA技術可將一次請求拆分為粒度更細的Actor，每個Actor使用獨立隊列，前一個的輸出是後一個的輸入。SEDA通過該方式將請求中等待和非等待的環節分離，提升了系統的吞吐量，這種方式在小米等網際網路公司有較多應用。
除了異步之外，並行對系統也很重要，它可以有效縮短請求的響應時間。批量接口也可以有效減少系統調用次數，使得系統線程消耗更少，從而提升系統吞吐量。
對線程而言，還有一個重要的參數是超時時間。響應快的服務，超時時間可以長一些，對於響應慢的服務，超時時間可以短一些，儘快失敗是保護自己的有效手段。
網絡架構和性能
大型網站的網絡接入一般是「DNS+負載均衡層+CDN」這種模式。對於大型網際網路公司，往往有多個IDC提供對外服務，中國網際網路的南北不互通使得解決不同地域不同運營商的接入速度問題成了難題，該問題的解決一般需要公司自己開發DNS伺服器，結合IP測速平臺，引流用戶請求到訪問速度最快的節點。
大系統小做
業務邏輯複雜多變，如何保證程序邏輯的代碼穩定是架構師需要解決的問題，良好的模塊劃分和擴展性強的接口設計都是解決這個問題的利器。
模塊是和領域模型相關的一個概念，其往往指系統中高內聚的一個數據訪問單元。例如對電商系統而言，最大的兩個領域模型分別是商品信息和交易信息，每個領域模型對應一系列數據，商品會有商品的基本信息、類目信息等，交易會包括交易的訂單，這些「領域模型+數據+業務方法」就構成了一個個的模塊，高度內聚的模塊是數據的訪問的入口。例如交易時也需要去獲取商品信息，但一般不會被允許直接調用商品模塊的數據表，而是通過商品模塊提供的接口進行訪問，這樣做有下面一些優點。
對較小規模的應用，模塊可部署在一起，但對大型系統而言，模塊一般是單獨部署，通過RPC交互，這樣可以減少彼此之間的系統層面影響。例如Amazon就傾向將所有伺服器程序暴露為接口。
分布式系統增加了系統交互的複雜性，也為系統引入了更多潛在的失敗環節，但分布式系統可以帶來的好處更明顯。
邏輯層的接口設計如何做到穩定呢？首先接口的設計不應該是產品驅動的，而應該由數據驅動，儘量考慮接口以後的發展，接口的參數儘量是對象，參數不要採用boolean這種難以擴展的數據類型。
邏輯層的接口設計，一般有粗粒度和細粒度兩種模式。粗粒度接口的優點是交互少，一次調用基本可以滿足需求，缺點是業務邏輯較多，所以不穩定性增加，這裡的不穩定性不僅是系統穩定性，還包括業務邏輯的穩定性。細粒度接口交互較多，但更加有利於重用性。
細粒度接口多次交互是否會帶來明顯的性能損耗呢？目前伺服器1秒可以執行近萬次TCP連接，網絡傳輸對於千兆網卡而言，一般也不會造成瓶頸，尤其RPC框架般都會保持長連接。因此，通常情況下我們可以忽略RPC調用帶來的性能損耗。
邏輯層接口儘量採用大系統小做的原則，該原則是騰訊架構中重要的價值觀。一個接口不做太多事情，只做關鍵路徑，非關鍵邏輯可以用消息隊列或事件通知等方式剝離出來，使得關鍵路徑更加穩定。這也體現了服務分級的思想，把最大的精力花在最重要的接口上。
除了按重要性劃分服務之外，也可以按接入方劃分，避免不同終端的Bug影響。還可以按快慢劃分，例如為上傳文件等功能提供單獨的服務，避免長時間佔用線程，影響系統穩定性。
模塊化是程序的水平切分，有時也會採用垂直切分，這種架構有以下好處。
開放勢不可擋
系統發展往往會帶來平臺化需求，例如微博的大多數服務除了滿足PC訪問，還要滿足移動端及內外部平臺，此時系統通常會抽象出一個接入層。
接入層設計
接入層一般分為：通信、協議和路由模塊。
常用的通信方式有TCP、UDP和HTTP等，對開放平臺等以外圍接入為主的系統而言，HTTP因其簡單方便是最合適的通信方式，而內部系統接入出於性能考量，可以直接用TCP或者UDP。
目前的主流協議有JSON、XML、Hessian等，對外部調用一般採用XML或者JSON，內部系統可以採用Hessian或其他自定義的二進位協議。
路由層是根據用戶的信息將請求轉發到後端服務層。LVS可看作是路由層，根據IP協議將不同來源的請求轉發到不同IP Server，Nginx等具備反向代理的伺服器也可以看作路由，根據不同URL轉發到不同後端。我們經常會自定義路由層，通過用戶調用的不同方法轉發到不同Server，或者根據用戶的特徵，將用戶路由到我們的灰度測試機。
雲平臺概念
具有了平臺化的接入功能，系統可以方便地接入內部或者外部系統，此時就具有了「雲」的特徵，對各種公有雲或私有雲來說，系統的隔離和自動擴容都十分重要，虛擬化等技術在該類系統中有了充分應用，例如阿里雲等雲平臺都大量使用了虛擬化。
穩定壓倒一切
代碼穩定性
穩定性是系統架構中一以貫之的內容，可以從圖4中理解它的含義。
正常情況下，圖4左邊系統的性能明顯優於右邊，但從架構角度考慮，右圖要好於左圖，因為突起的毛刺使得系統的容量驟降，很容易引發雪崩。性能考量不僅是系統的最優性能或者平均性能，最差性能往往也是系統出現問題的原因。
圖4 兩種穩定性對比
容災
除了特別小型的系統，沒有100%可用的系統。一般需要根據系統的情況制定合適的目標，該目標最通用的衡量維度是系統可用率。
系統可用率是可以提供服務的時間與總時間的比率，常用的系統可用率如表1所示。
而對於災難，我們有下面幾個環節可以介入。
系統容量的冗餘和可水平擴展也是容災的必備要求，無狀態的系統對於系統擴容更友好。
作者楊光輝，淘寶北京研發中心技術專家，花名三玄。曾在互動百科、騰訊科技等公司任職，對伺服器端架構和開發等有一定研究。
本文為《程式設計師》原創文章，未經允許不得轉載，如需轉載請聯繫market#csdn.net(#換成@)