海量用戶同時進行高頻訪問對任何平臺都是難題，也是行業樂此不疲的研究方向。但值得慶幸的是，雖然業務場景不同，設計和優化的思想卻是萬變不離宗。本文將結合業務與高併發系統設計的核心技術點，對系統架構調優方案進行深度剖析。
文章根據 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 查看。
最後，我想說的是所有的高可用系統一定不能忘記一個核心概念，那就是異地多活。舉例來講就是我們需要在多地備署多個機房，擁有多地備份和多地容災。上圖是我對上述全部的應用架構優化進行的總結，希望能夠爲大家提供參考，謝謝。