網際網路三高

摘  要:本文通過閱讀相關資料，圍繞網際網路三高架構：高併發、高效能、高可用概念、要求，設計方案等方面詳細展開。

關鍵詞:高併發；高效能；高可用；架構設計；架構應用

Abstract: Through reading relevant materials, this paper focuses on the three high architectures of the Internet: high concurrency, high performance, high availability concept, requirements, design scheme and other aspects in detail.

Keywords: High concurrency. High performance; High availability; Architecture design; Architecture application

1    什麼是網際網路三高架構？

　　網際網路的三高架構就是指設計網際網路系統架構時需要滿足高可用，高效能，高併發，它們是網際網路系統架構設計永恆的主題。

2    高併發

　　高併發指運用設計手段讓系統能夠處理更多的使用者併發請求，也就是承擔更大的流量。它是一切架構設計的背景和前提，脫離了它去談效能和可用性是沒有意義的。

　　高併發是一個結果導向的東西，例如，常見的高併發場景有：淘寶的雙11、春運時的搶票、微博大V的熱點新聞等，這些典型場景並不是陡然出世，而是隨著業務發展的發展而逐漸出現。像2020年淘寶雙11全球狂歡季，訂單建立峰值達到了驚人的58.3萬筆/秒。

　　高併發相關常用的一些指標有響應時間（Response Time），吞吐量（Throughput），每秒查詢率QPS（Query Per Second），併發使用者數等。

　　1.響應時間：系統對請求做出響應的時間。例如系統處理一個HTTP請求需要200ms，這個200ms就是系統的響應時間。

　　2.吞吐量：單位時間內處理的請求數量。

　　3.QPS：每秒響應請求數。在網際網路領域，這個指標和吞吐量區分的沒有這麼明顯。

　　4.併發使用者數：同時承載正常使用系統功能的使用者數量。例如一個即時通訊系統，同時線上量一定程度上代表了系統的併發使用者數。

　　一般的網際網路應用，訪問量非常大，最常見的是高併發問題。那麼如何提升系統的併發能力？

　　提高併發能力的兩種主要方法：垂直擴充套件，水平擴充套件。

　　垂直擴充套件：

　　（1）硬體升級：CPU不夠加CPU，記憶體不夠加記憶體，磁碟空間不足加磁碟，機械磁碟換固態等。

　　（2）網路升級：網路頻寬拉滿，域名、靜態資源使用CDN加速。

　　（3）軟體升級：優化程式碼演算法，減少邏輯處理迴圈，使用Cache代替實時查詢，使用非同步增加吞吐量，少用鎖減少響應時間等。

　　（4）資料庫升級：本地資料庫換雲資料庫，增加資料庫連線數，優化索引，優化sql，提升配置等。

       水平擴充套件：

　　（1）增加伺服器數量

　　（2）資料層的水平擴充套件

　　（3）服務層的水平擴充套件

　　在網際網路領域由於時間重要性，在預算夠的話，優先採用垂直擴充套件。業務快速發展重要性遠超伺服器升級費用。

　　比如阿里雲擴容以應對釘釘業務暴增。受疫情影響，釘釘後臺系統峰值流量不斷創下新高，通過連續在阿里雲上擴容十幾萬臺雲伺服器，釘釘平穩度過了流量高峰。基於阿里雲彈性計算資源編排排程服務，釘釘在短短2小時內新增部署了超過1萬臺雲伺服器，創下了阿里雲上快速擴容的新紀錄。此外，阿里雲遍佈全球的2500個CDN節點和120T頻寬，也為群直播、視訊會議等提供了支援。

3    高效能

　　高效能是指程式處理速度非常快，所佔記憶體少、CPU佔用率低。高效能的指標經常和高併發的指標緊密相關，想要提高效能，那麼就要提高系統高併發能力，兩者互相捆綁在一起。應用效能優化的時候，對於計算密集型和IO密集型還是有很大差別，需要分開來考慮。還有可以增加伺服器的數量、記憶體、IO 等引數提升系統的併發能力和效能，但不要浪費資源，要考慮硬體的使用率最高才能發揮到極致。

　　那麼怎麼提高效能呢？

　　1.避免因為 IO 阻塞讓 CPU 閒置，導致 CPU 的浪費。

　　2.避免多執行緒間增加鎖來保證同步，導致並行系統序列化。

　　3.免建立、銷燬、維護太多程序、執行緒，導致作業系統浪費資源在排程上。

                            圖1 高效能架構

4    效能優化

　　“天下武功，唯快不破”。效能是系統設計成功與否的關鍵，實現高效能也是對程式設計師個人能力的挑戰。不過在瞭解實現高效能的方法之前，我們先明確一下效能優化的原則。

　　首先，效能優化一定不能盲目，一定是問題導向的。脫離了問題，盲目地提早優化會增加系統的複雜度，浪費開發人員的時間，也因為某些優化可能會對業務上有些折中的考慮，所以也會損傷業務。

　　其次，效能優化也遵循“八二原則：即你可以用 20% 的精力解決 80% 的效能問題。所以我們在優化過程中一定要抓住主要矛盾，優先優化主要的效能瓶頸點。

　　再次，效能優化也要有資料支撐：在優化過程中，你要時刻了解你的優化讓響應時間減少了多少，提升了多少的吞吐量。

　　最後，效能優化的過程是持續的：高併發的系統通常是業務邏輯相對複雜的系統，那麼在這類系統中出現的效能問題通常也會有多方面的原因。因此，我們在做效能優化的時候要明確目標，比方說，支撐每秒 1 萬次請求的吞吐量下響應時間在 10ms，那麼我們就需要持續不斷地尋找效能瓶頸，制定優化方案，直到達到目標為止。

5    高可用性

　　高可用性是指系統具有較高的無故障執行能力。

　　高可用的主要目的是為了保障業務的連續性，即在使用者眼裡，業務永遠是正常對外提供服務的。高可用主要是針對架構而言，那麼要做好高可用，就要首先設計好架構，一般會採用分層的思想將一個龐大的 IT 　　系統拆分成為應用層，中介軟體，資料儲存層等獨立的層，每一層再拆分成為更細粒度的元件，第二步就是讓每個元件對外提供服務，畢竟每個元件都不是孤立存在的，都需要互相協作，對外提供服務才有意義。

　　目前多數網際網路都會採用微服務架構，常見架構如下:

　　　　　　圖2 架構分層

　　可以看到架構主要分以下幾層：

　　1.接入層：主要由 F5 硬體或 LVS 軟體來承載所有的流量入口

　　2.反向代理層：Nginx，主要負責根據 url 來分發流量，限流等

　　3.閘道器：主要負責流控，風控，協議轉換等

　　4.站點層：主要負責呼叫會員，促銷等基本服務來裝配 json 等資料並返回給客戶端

　　5.基礎 service：其實與站點層都屬於微服務，是平級關係，只不過基礎 service 屬於基礎設施，能被上層的各個業務層 server 呼叫而已

　　6.儲存層：也就是 DB，如 MySQL，Oracle 等，一般由基礎 service 呼叫返回給站點層

　　7.中介軟體：ZK，ES，Redis，MQ等，主要起到加速訪問資料等功能，要實現整體架構的高可用，必須要實現每一層元件的高可用。

　　除了做好架構的高可用之外，我們還需要在做好系統隔離，限流，熔斷，風控，降級，對關鍵操作限制操作人許可權等措施以保證系統的可用。

　　這裡特別提一下降級，這是為了保證系統可用性採取的常用的措施，簡單舉幾個例子。

　　1.例如對接一個第三方資金方由於自身原因借款功能出了問題導致無法借款，這種情況為了避免引起使用者恐慌，於是在使用者申請第三方借款的時候返回了一個類似為了提升你的額度，資金方正在系統升級這樣的文案，避免了客訴。

　　2.在流媒體領域，當用戶觀看直播出現嚴重卡頓時，很多企業的第一選擇不是查 log 排查問題，而是為使用者自動降位元速率。因為比起畫質降低，卡得看不了顯然會讓使用者更痛苦。

　　3.雙十一零點高峰期，我們把使用者的註冊登入等非核心功能給停掉了，以保證下單等核心流程的順利。

　　另外最好能做到事前防禦，在系統出問題前把它扼殺在搖籃裡，所以需要做單元測試，做全鏈路壓測等來發現問題，還需要針對 CPU，執行緒數等做好監控，當其達到我們設定的域值時就觸發告警以讓我們及時發現修復問題，此外在做好單元測試的前提下，依然有可能因為程式碼的潛在 bug 引起線上問題，所以我們需要在關鍵時間（比如雙十一期間）封網。

 　　　　　　圖3 設計常見手段

6    總結

　　1.業務需要推動了架構技術的演化，一個日活10來個人的網站，有必要上一個高大全的分散式的系統嘛？非要上一個，完全自尋死路，沒那需求，也沒那必要。

　　2.大型網站的架構是根據業務需求不斷完善的，根據不同的業務特徵會做特定的設計和考慮。

　　3.一個大的解決方案通常是由很多個一起協調工作的小的解決辦法組成的。這需對每一個解決方案進行精心正確的設計和開發。