海量使用者同時進行高頻訪問對任何平臺都是難題，也是行業樂此不疲的研究方向。但值得慶幸的是，雖然業務場景不同，設計和優化的思想卻是萬變不離宗。本文將結合業務與高併發系統設計的核心技術點，對系統架構調優方案進行深度剖析。
文章根據 Authing 身份雲高階工程師羅傑林，在又拍雲 Open Talk 技術沙龍北京站所作主題演講《億級流量系統架構演進之路》整理而成，現場視訊及 PPT 可點選閱讀原文檢視。
相信大家都同意，網際網路發展勢頭的逐漸凶猛改變了我們很多的生活方式。比如網購、銀行轉賬等業務，不再需要我們必須線下辦理，這極大方便了我們的生活。這背後當然也對身為網際網路從業人員的我們來說，面臨的考驗也越來越大，在系統架構升級上也會傾注更大的心血。
認識高併發系統
高併發系統擁有高併發、高效能、高可用，分散式、叢集化，安全性等特性。
我們首先來看一下高併發、高效能、高可用，也就是我們經常提到的三高系統。當我們流量非常大的情況下，我們一定要保證這三高。這其中高併發是指要支援很多併發使用者，高效能是在高併發的前提下保證優秀的效能，高可用則是保證系統在某一節點出現問題時不會整體當機且繼續持續提供服務。由此可見三高的主要特性則是分散式和叢集化，而我們主要要解決的問題則是安全性。
上圖是一些常見的與我們生活息息相關的高併發場景。左上電商秒殺是最常見的場景了，去年疫情期間口罩緊缺搶口罩就是這個場景，很多人在一個統一的時間去點選同一個頁面，這個的併發數是特別高的。右上則是搶票，這個大家也很熟悉了，特別是春節需要回家的在外地工作的朋友們，肯定都是開個搶票軟體一直刷給自己搶票的，這種的併發流量特別大。左下則是銀行交易系統，我們所有的線上、線下掃碼其實都需要通過銀行系統，這就讓它的日交易量極大。最後是 Authing 身份證，我們主要是給使用者做整套的身份認證和使用者管理體系，這個體系讓開發者避免了重複構建身份的操作，減少了開發者編寫的程式碼，提高他們的效率。以下圖作為例子：
圖中展示的是我們的核心元件，表面上看是一個簡單的登入框，也就是使用者認證介面，但是其背後有一個龐大的由使用者體系、管理體系、認證體系等一系列服務組成的後臺支撐。儘管使用者只是進行了使用者名稱和密碼的輸入，但是我們要考慮到的不僅僅是使用者的安全認證、多種登入方式，還有很多使用者同時認證時要如何處理等等多種事項。除此之外，我們還需要考慮到如何讓包括私有化使用者在內的多種型別的客戶實現高可用和快速部署，完成快速整合。
如果有做高併發的朋友，對於 CAP 理論一定不陌生。它的主要觀點是分散式系統無法同時滿足三個，只能夠滿足其中兩個。即分散式系統要麼滿足 CA，要麼滿足 CP，但無法同時滿足CAP。其中的意思是說如果滿足了可用性和分割槽的容錯性，那可能意味著要犧牲一致性，進而達到最終的資料一致性。它是告訴我們要作出取捨。
從單體應用架構說起
上圖中示意的單體應用構架是早期常用的模式。早期因為人手緊缺通常會將 Web 和 Server 一起開發再一起部署，之後和資料庫連在一起就可以正常提供服務。這麼做的優點是維護簡單，但是迭代比較麻煩。
現在前後端分離後，我們通常把 Web 和 Server 分開為兩個服務部署，為快速迭代提供了便利。如果我們有一個 Server 需要修復，我們可以單獨對這個服務進行程式碼修改和部署，然後快速上線服務。但是它的缺點是隨著業務的增多，Server 包含的內容也越來越多，這會讓它耦合很深進而導致服務變慢。這一點我深有體會，多年前我有個朋友架構出了問題，有段時間每到週末他會買一袋瓜子來我家一起琢磨。為什麼要買一袋瓜子呢？因為耦合的太深了，服務啟動要 5 分鐘，改一個東西又要等 5 分鐘重啟，所以我們嗑著瓜子聊天等待。
類似上面提到的依賴複雜、臃腫繁雜是單體應用會遇到的一個問題，除此之外單體應用還有以下問題：
- 單點瓶頸
- 穩定差
- 擴充套件性差
- 業務模型缺失
- 新業務擴充套件差
- 業務流程基礎能力缺乏
- 前後端耦合嚴重
- API 雜亂難維護
既然痛點如此明顯，那麼如何去優化就很重要。不過在談這個問題之前需要思考一個新問題——CPU 越多效能就會越好嗎？
大多數情況是這樣的，因為 CPU 可以提高運算速度。但這不是絕對的，假如我們的程式裡有很多鎖的概念，那就無法體現出多執行緒的多核性。那可能 CPU 的多少就不會有顯著效果。一般遇到這種情況，許多公司會考慮把服務拆開。這就涉及到成本問題，也就是說增加 CPU 並不是最優解，我們還是需要考慮如何去優化鎖。不過思考具體優化前我們可以先了解下池化技術。
上圖是池化技術的抽象概念，一般獲取連線以及執行緒用完後都會放入資源池資源池。同時我們還需要有以下四個概念：連線池、執行緒池、常量池、記憶體池。
一般用連線池較多，因為系統之間的呼叫、請求外部服務時都會通過請求連線來進行。曾經我們使用的是短連線，但是由於 HTTP 的每次連線都需要重複建立和關閉連線的過程，非常耗時，所以現在開始使用連線池。它每次請求完後建立的連線都是重複可用的，非常有助於節省開銷。同時我們的任務最後都是需要拆出來的，而那些拆出來的非同步任務則都放置線上程池內進行。常量池和記憶體池的概念是想通的，我們會申請一塊大的記憶體複用。
瞭解池化技術後，我們回到具體優化。
應用架構優化
Web Server 優化
首先來看一下 Web Server 的優化，它主要通過程式碼優化、熱點快取、演算法優化等等步驟實現。
第一步是程式碼優化，將不合理的程式碼進行優化。比如查詢介面通常都會查詢很多內容，使得運算緩慢，這就需要優先進行優化。
第二步是熱點快取，將全部的熱點資料進行快取從而儘可能減少資料庫的操作。比如 Authing 身份認證在拿到 token 後不可能每次進行資料庫運算，這樣 QPS 會非常慢，我們可以通過將熱點資料全部快取來提高 QPS。
第三步是演算法優化，因為我們的業務通常都非常複雜，所以這個概念非常廣泛。比如查詢一個列表，是需要一次性列出全部列表還是在記憶體中計算完畢後將結果返回給前端呢？這就需要針對不同的業務場景進行優化，從而提高效能。
單獨部署
完成單體應用優化後，如果這些服務都部署在同一臺伺服器上，那可能會出現 CPU 和記憶體被佔用的情況。這時候我們可以把 Web、以及載入完快取的應用程式拎出來分別部署到一個單獨伺服器上。同時將靜態資源全部儲存在 CDN 上，通過就近訪問加快頁面載入速度。通過這些方式，讓我們的 Auting 達到了 50 毫秒內響應的需求。單獨部署的方式也非常適合系統之間的需求，無論你是什麼業務場景，如果需要提升響應速度，那大家可以考慮這個方式。
垂直拆分
之後我們需要對業務進行拆分。業務拆分有以下三種方式：
- 按照業務場景拆分，比如將使用者、訂單、賬務進拆分。
- 按照業務是同步還是非同步進拆分，這樣做的好處是可以很好控制非同步流量，不讓它影響我們的核心服務執行。
- 按照模型拆分，因為業務拆分主要是為了解決系統之間耦合嚴重依懶性問題，為了後期儘量減少系統間的以來，所以前期的模型一定要儘可能的建設好。
在完成系統拆分後，我們需要評判優化後的系統能承載多少業務量，優化了多少。那麼我就需要對它進行一次壓測。壓測會涉及到大家都有所瞭解的木桶理論，我們將系統比作一個木桶，那麼木桶能夠承載多少水量取決於最低的那塊木板。所以壓測時我們不需要關注那些佔用資源少的部分，我們要關心那些高的已經達到了系統瓶頸的部分。通過這部分來查詢我們系統的潛在問題點。
橫向拆分
在我們將服務進行垂直拆分後，隨著請求量逐漸增多可能還是無法滿足需求。這時候我們可以將系統進行水平拆分，然後進行水平擴容，一個不夠就增加兩個甚至更多。同時通過負載均衡的伺服器將請求量均勻分給這些水平節點。通常我們會選擇使用 NG 來作負載均衡伺服器。
上圖是我們的負載均衡伺服器。負載均衡下面會有很多閘道器係統，我們看到中間有一個 Nginx 叢集。我們都知道 Nginx 能夠承受的併發量非常大，所以流量小的時候不需要這個叢集，需要它的時候一定是併發量非常大的情況。當你的併發量極大，到 Nginx 叢集都無法承受的時候，我們最好不要在它的叢集前面再放一層 Nginx，因為效果並不明顯。同時我個人也不太建議大家選擇 F5，因為 F5 是一個硬體，它的成本比較大。我個人建議大家選擇 LVS，它是 Linux 下面的一個虛擬服務，如果配置的好，它的效能完全比得上 F5。
說完了負載均衡，我們回到水平拆分。
在進行水平拆分時我們不能忽略快取問題。在單機模式下快取都是本地快取，而當我們成為分散式後，如果有一個伺服器拿到 token 並存到本地，另一個伺服器就會因為沒有拿到而無法通訊。因此我們引入分散式快取，比如將快取放到 Redis 這種分散式快取裡，讓所有應用都請求 Redis 拿快取。
當我們水平拆分後，還需要關注分散式 ID。因為單體時候生成 ID 的方法可能不適用於分散式服務。以時間戳舉例，以前在單體時有，請求我們就生成一個 ID，這是有唯一性的。在分散式情況下多個伺服器收到請求可能會生成重複 ID，做不到唯一性。所以我們需要單獨做一個 ID 服務來生成 ID。
配置中心
在我們把服務進行了水平和垂直的拆分後，如何讓配置統一同步的配置到每一個服務就成了問題。最好的辦法就是當我們修改配置後，讓所有服務都同時感知到這個更改，然後自己應用並配置。因此我們引入了配置中心。
上圖是配置中心的大體流程，目前比較流行的配置中心方案有兩個是，一個是阿里開源的 Nacos，另一個是 Spring Cloud 組建的 Spring Cloud config，感興趣的朋友們可以瞭解一下。
接下來我們具體看一下上圖。這其中 Server 是存放我們配置的控制檯。一般開發者會在控制檯通過 API 修改配置，修改後的配置可以持久放置在 Mysql 或其他資料庫內。Client 包含了我們所有的應用，在它裡面會有一個監聽 Server 內是否有配置更改的監聽，當有配置更改時則去獲取這個配置，這樣所有的應用就可以在前端更新後及時更新了。同時為了防止 App 在獲取更新時因為網路問題而獲取失敗的情況，我們會在本地做一個快照，當網路出現問題時，App 可以降級到本地獲取檔案。
資料庫拆分
我們完成了系統的拆分，做好了負載均衡，並完成了配置中心。在請求量不太大的情況下，我們其實已經完成了系統的優化。等到後期業務繼續擴張時，我們遇到的瓶頸就不再是系統，而是資料庫了。那麼要如何解決這個問題呢？
第一種方式是主從複製與讀寫分離。讀寫分離可以解決資料讀寫全都在一個庫上的問題，通過將主從庫拆分為 master 和 slave，讓寫這一環節全部由 master 來處理，將寫的壓力分攤從而提高資料庫效能。之後隨著業務量的繼續增大，單獨的主從複製已經無法滿足我們的需求時，我們通過第二種方式來處理。
第二種方式是進行垂直拆分。垂直拆分的概念和業務的拆分相似，我們根據服務將資料庫拆分為 Users、Orders、Apps 等等，讓每一個服務都擁有自己的資料庫，避免統一請求從而提升併發性。伴隨業務量的繼續增長，即便是單獨的庫也會到達瓶頸，這時我們就需要用到第三種方式。
第三種方式是水平拆分。比如我們將 Users 這個資料庫內的表進一步拆分為 Users1，Users2，Users3 等等多個表。要完成這個拆分我們需要考慮，面對多個表我們在查詢時要如何去做的問題。這時我們需要按照我們的具體業務來判斷。比如查詢使用者，我們可以根據使用者 ID，將 ID 拆分分片，然後使用雜湊演算法讓他們統一在一定範圍內。之後我們每次拿到 Users 就通過雜湊來計算具體在哪一片並快速抵達相應位置。Auting 多租戶的設計就用到了拆分的概念，如下圖所示。
服務限流
等到業務量多到一定程度後我們肯定會涉及到服務限流，這是一個變相的降級策略。雖然我們的理想都是系統能夠承受越來越多的使用者越來越多的量，但是因為資源總是有限的，所以你必須要進行限制。
請求拒絕
服務限流有兩種主要演算法，漏桶演算法與令牌桶演算法。我們可以看一下上圖，它畫的比較形象。漏桶演算法中我們可以將流量想象成一杯水，在水流流出的地方進行限制，無論水流流入的速度有多快，但是流出速度是一樣的。令牌桶則是建立一個發放令牌的任務，讓每一個請求進入前都需要先拿到令牌，如果請求速度過快令牌不夠用時就採取對應的限流策略。除去這兩種演算法，一般還會用到大家都很熟悉的計數器演算法，感興趣的朋友也可以去自行了解一下，這裡我們就不細談了。
這幾種演算法其實本質上都是在流量過量的時候，拒絕過量的部分的請求。而除去這種拒絕式的策略，我們還有一種排隊的策略。
訊息佇列
當我們的業務有無法限流、拒絕的情況存在時，我們就需要用到佇列訊息。
如圖所示，訊息佇列的主要概念是生產者會將訊息放入佇列中，由消費者從佇列中獲取訊息並解決。我們通常使用 MQ、Redis、Kafka 來做訊息佇列。佇列負責解決釋出/訂閱和客戶端推拉兩個問題，生產者負責解決以下問題：
- 緩衝：為入口處過大的流量設定緩衝
- 削峰：與緩衝的效果類似
- 系統解耦：如果兩個服務沒有依賴呼叫關係，可以通過訊息佇列進行解耦
- 非同步通訊
- 擴充套件：基於訊息佇列可以做很多監聽者進行監聽
服務熔斷
在業務正常提供服務時，我們可能會遇到下圖這種情況：
服務 A、B 分別呼叫服務 C、D，而這兩者則都會呼叫服務 E，一旦服務 E 掛掉就會因為請求堆積而拖垮前面的全部服務。這個現象我們一般稱之為服務雪崩。
而為了避免這個情況的發生，我們引入了服務熔斷的概念，讓它起到一個保險絲的作用。當服務 E 的失敗量到達一定程度後，下一個請求就不會讓服務 E 繼續處理，而是直接返回失敗資訊，避免繼續呼叫服務 E 的請求堆積。
簡單來講這是一種服務降級，通常的服務降級還有以下幾種：
- 頁面降級：視覺化介面禁用點選按鈕、調整靜態頁面
- 延遲服務：如定時任務延遲處理、訊息入 MQ 後延遲處理
- 寫降級：直接禁止相關寫操作的服務請求
- 讀降級：直接禁止相關讀的服務請求
- 快取降級：使用快取方式來降級部分讀頻繁的服務介面
- 停服務：關閉不重要的功能，為核心服務讓出資源
壓測
上圖就是我們具體壓測要關注的東西。首先我們要知道壓測其實是一個閉環，因為我們可能會需要重複這個流程很多次，不斷地重複發現問題、解決問題、驗證是否生效、發現新問題這個過程，直到最終達到我們的壓測目標。
在壓測開始前我們會制定壓測目標，然後依據目標來準備環境。壓測模型可以是線上的，也可以是線下。一般線下考慮到成本問題，因此會選擇單機或小叢集來進行，這可能讓結果不太精準，所以通常大家都選擇線上上或者機房來進行壓測，資料更精準。在壓測過程中我們會發現新的問題，然後解決它，並驗證結果直到達到壓測目標。
在壓測的過程中我們需要關注以下幾點。首先是 QPS，即每秒查詢量。它和 TPS 的區別在於，TPS 有事務的概念，需要完成事務才算一次請求。而 QPS 沒有這個概念，它只要查詢到結果就算做一次請求。其次是 RT（響應時間），這個需要我們重點關注，而且越是高併發的系統，RT 越重要。之後在壓測中我們需要關注系統到底能承載多大的併發數和吞吐量。成功率則是指在壓測過程中，當壓力越來越大的時候我們的業務是否能按照原計劃執行並得到既定結果。GC 則是指垃圾回收，這也是個很大的問題，因為如果我們程式碼寫的不好，那麼隨著壓力的增大 GC 逐漸頻繁最終會導致系統停頓。
之後則是硬體方面，需要我們關注 CPU、記憶體、網路、I/O 的佔有率，有一種任意一項卡主就有可能導致一個系統瓶頸。最後是資料庫，這裡暫不展開細講。
日誌
在壓測過程中發生的問題我們要如何才能知道呢？那就要依靠日誌了，它讓系統變得視覺化，方便我們發現問題的根源。
那日誌要如何做呢？這裡主要是依靠埋點來完成，比如通過埋點請求進入每一個系統、每一層的時間和響應時間，然後通過這兩個時間差看出系統的耗時。由此可以看出只有埋點清晰，才能精準發現問題的所在。
上圖是一個比較通用的日誌處理方案，每一個服務產生的日誌都是通過 Filbeat 收集到 Kafka，然後到 Logstach，最後到 ElasticSearch。其中 Kibana 是一個視覺化介面，方便我們分析日誌。
上圖是 Auting 的日誌和監控系統。中間是 K8S 叢集，左邊是業務上的訊息佇列，右邊則是我們的監控系統。監控系統我們只要是使用 Grafana 根據業務報警，比如我們會配置當成功率低於多少時就報警的情況。主要的日誌系統則是使用 logstash 抽取 log 檔案到 ES 內使用 Kibana 檢視。
最後，我想說的是所有的高可用系統一定不能忘記一個核心概念，那就是異地多活。舉例來講就是我們需要在多地備署多個機房，擁有多地備份和多地容災。上圖是我對上述全部的應用架構優化進行的總結，希望能夠為大家提供參考，謝謝。