海量用戶同時進行高頻訪問對任何平臺都是難題，也是行業(yè)樂此不疲的研究方向。但值得慶幸的是，雖然業(yè)務場景不同，設計和優(yōu)化的思想?yún)s是萬變不離宗。本文將結合業(yè)務與高并發(fā)系統(tǒng)設計的核心技術點，對系統(tǒng)架構調(diào)優(yōu)方案進行深度剖析。

文章根據(jù) Authing 身份云高級工程師羅杰林，在又拍云 Open Talk 技術沙龍北京站所作主題演講《億級流量系統(tǒng)架構演進之路》整理而成，現(xiàn)場視頻及 PPT 可點擊閱讀原文查看。

相信大家都同意，互聯(lián)網(wǎng)發(fā)展勢頭的逐漸兇猛改變了我們很多的生活方式。比如網(wǎng)購、銀行轉(zhuǎn)賬等業(yè)務，不再需要我們必須線下辦理，這極大方便了我們的生活。這背后當然也對身為互聯(lián)網(wǎng)從業(yè)人員的我們來說，面臨的考驗也越來越大，在系統(tǒng)架構升級上也會傾注更大的心血。

認識高并發(fā)系統(tǒng)

高并發(fā)系統(tǒng)擁有高并發(fā)、高性能、高可用，分布式、集群化，安全性等特性。

我們首先來看一下高并發(fā)、高性能、高可用，也就是我們經(jīng)常提到的三高系統(tǒng)。當我們流量非常大的情況下，我們一定要保證這三高。這其中高并發(fā)是指要支持很多并發(fā)用戶，高性能是在高并發(fā)的前提下保證優(yōu)秀的性能，高可用則是保證系統(tǒng)在某一節(jié)點出現(xiàn)問題時不會整體宕機且繼續(xù)持續(xù)提供服務。由此可見三高的主要特性則是分布式和集群化，而我們主要要解決的問題則是安全性。

上圖是一些常見的與我們生活息息相關的高并發(fā)場景。左上電商秒殺是最常見的場景了，去年疫情期間口罩緊缺搶口罩就是這個場景，很多人在一個統(tǒng)一的時間去點擊同一個頁面，這個的并發(fā)數(shù)是特別高的。右上則是搶票，這個大家也很熟悉了，特別是春節(jié)需要回家的在外地工作的朋友們，肯定都是開個搶票軟件一直刷給自己搶票的，這種的并發(fā)流量特別大。左下則是銀行交易系統(tǒng)，我們所有的線上、線下掃碼其實都需要通過銀行系統(tǒng)，這就讓它的日交易量極大。最后是 Authing 身份證，我們主要是給用戶做整套的身份認證和用戶管理體系，這個體系讓開發(fā)者避免了重復構建身份的操作，減少了開發(fā)者編寫的代碼，提高他們的效率。以下圖作為例子：

圖中展示的是我們的核心組件，表面上看是一個簡單的登錄框，也就是用戶認證界面，但是其背后有一個龐大的由用戶體系、管理體系、認證體系等一系列服務組成的后臺支撐。盡管用戶只是進行了用戶名和密碼的輸入，但是我們要考慮到的不僅僅是用戶的安全認證、多種登錄方式，還有很多用戶同時認證時要如何處理等等多種事項。除此之外，我們還需要考慮到如何讓包括私有化用戶在內(nèi)的多種類型的客戶實現(xiàn)高可用和快速部署，完成快速集成。

如果有做高并發(fā)的朋友，對于 CAP 理論一定不陌生。它的主要觀點是分布式系統(tǒng)無法同時滿足三個，只能夠滿足其中兩個。即分布式系統(tǒng)要么滿足 CA，要么滿足 CP，但無法同時滿足CAP。其中的意思是說如果滿足了可用性和分區(qū)的容錯性，那可能意味著要犧牲一致性，進而達到最終的數(shù)據(jù)一致性。它是告訴我們要作出取舍。

從單體應用架構說起

上圖中示意的單體應用構架是早期常用的模式。早期因為人手緊缺通常會將 Web 和 Server 一起開發(fā)再一起部署，之后和數(shù)據(jù)庫連在一起就可以正常提供服務。這么做的優(yōu)點是維護簡單，但是迭代比較麻煩。

現(xiàn)在前后端分離后，我們通常把 Web 和 Server 分開為兩個服務部署，為快速迭代提供了便利。如果我們有一個 Server 需要修復，我們可以單獨對這個服務進行代碼修改和部署，然后快速上線服務。但是它的缺點是隨著業(yè)務的增多，Server 包含的內(nèi)容也越來越多，這會讓它耦合很深進而導致服務變慢。這一點我深有體會，多年前我有個朋友架構出了問題，有段時間每到周末他會買一袋瓜子來我家一起琢磨。為什么要買一袋瓜子呢？因為耦合的太深了，服務啟動要 5 分鐘，改一個東西又要等 5 分鐘重啟，所以我們嗑著瓜子聊天等待。

類似上面提到的依賴復雜、臃腫繁雜是單體應用會遇到的一個問題，除此之外單體應用還有以下問題：

• 單點瓶頸

• 穩(wěn)定差

• 擴展性差

• 業(yè)務模型缺失

• 新業(yè)務擴展差

• 業(yè)務流程基礎能力缺乏

• 前后端耦合嚴重

• API 雜亂難維護

既然痛點如此明顯，那么如何去優(yōu)化就很重要。不過在談這個問題之前需要思考一個新問題——CPU 越多性能就會越好嗎？

大多數(shù)情況是這樣的，因為 CPU 可以提高運算速度。但這不是絕對的，假如我們的程序里有很多鎖的概念，那就無法體現(xiàn)出多線程的多核性。那可能 CPU 的多少就不會有顯著效果。一般遇到這種情況，許多公司會考慮把服務拆開。這就涉及到成本問題，也就是說增加 CPU 并不是最優(yōu)解，我們還是需要考慮如何去優(yōu)化鎖。不過思考具體優(yōu)化前我們可以先了解下池化技術。

上圖是池化技術的抽象概念，一般獲取連接以及線程用完后都會放入資源池資源池。同時我們還需要有以下四個概念：連接池、線程池、常量池、內(nèi)存池。

一般用連接池較多，因為系統(tǒng)之間的調(diào)用、請求外部服務時都會通過請求連接來進行。曾經(jīng)我們使用的是短連接，但是由于 HTTP 的每次連接都需要重復建立和關閉連接的過程，非常耗時，所以現(xiàn)在開始使用連接池。它每次請求完后創(chuàng)建的連接都是重復可用的，非常有助于節(jié)省開銷。同時我們的任務最后都是需要拆出來的，而那些拆出來的異步任務則都放置在線程池內(nèi)進行。常量池和內(nèi)存池的概念是想通的，我們會申請一塊大的內(nèi)存復用。

了解池化技術后，我們回到具體優(yōu)化。

應用架構優(yōu)化

Web Server 優(yōu)化

首先來看一下 Web Server 的優(yōu)化，它主要通過代碼優(yōu)化、熱點緩存、算法優(yōu)化等等步驟實現(xiàn)。

第一步是代碼優(yōu)化，將不合理的代碼進行優(yōu)化。比如查詢接口通常都會查詢很多內(nèi)容，使得運算緩慢，這就需要優(yōu)先進行優(yōu)化。

第二步是熱點緩存，將全部的熱點數(shù)據(jù)進行緩存從而盡可能減少數(shù)據(jù)庫的操作。比如 Authing 身份認證在拿到 token 后不可能每次進行數(shù)據(jù)庫運算，這樣 QPS 會非常慢，我們可以通過將熱點數(shù)據(jù)全部緩存來提高 QPS。

第三步是算法優(yōu)化，因為我們的業(yè)務通常都非常復雜，所以這個概念非常廣泛。比如查詢一個列表，是需要一次性列出全部列表還是在內(nèi)存中計算完畢后將結果返回給前端呢？這就需要針對不同的業(yè)務場景進行優(yōu)化，從而提高性能。

單獨部署

完成單體應用優(yōu)化后，如果這些服務都部署在同一臺服務器上，那可能會出現(xiàn) CPU 和內(nèi)存被占用的情況。這時候我們可以把 Web、以及加載完緩存的應用程序拎出來分別部署到一個單獨服務器上。同時將靜態(tài)資源全部存儲在 CDN 上，通過就近訪問加快頁面加載速度。通過這些方式，讓我們的 Auting 達到了 50 毫秒內(nèi)響應的需求。單獨部署的方式也非常適合系統(tǒng)之間的需求，無論你是什么業(yè)務場景，如果需要提升響應速度，那大家可以考慮這個方式。

垂直拆分

之后我們需要對業(yè)務進行拆分。業(yè)務拆分有以下三種方式：

• 按照業(yè)務場景拆分，比如將用戶、訂單、賬務進拆分。

• 按照業(yè)務是同步還是異步進拆分，這樣做的好處是可以很好控制異步流量，不讓它影響我們的核心服務運行。

• 按照模型拆分，因為業(yè)務拆分主要是為了解決系統(tǒng)之間耦合嚴重依懶性問題，為了后期盡量減少系統(tǒng)間的以來，所以前期的模型一定要盡可能的建設好。

在完成系統(tǒng)拆分后，我們需要評判優(yōu)化后的系統(tǒng)能承載多少業(yè)務量，優(yōu)化了多少。那么我就需要對它進行一次壓測。壓測會涉及到大家都有所了解的木桶理論，我們將系統(tǒng)比作一個木桶，那么木桶能夠承載多少水量取決于最低的那塊木板。所以壓測時我們不需要關注那些占用資源少的部分，我們要關心那些高的已經(jīng)達到了系統(tǒng)瓶頸的部分。通過這部分來查找我們系統(tǒng)的潛在問題點。

橫向拆分

在我們將服務進行垂直拆分后，隨著請求量逐漸增多可能還是無法滿足需求。這時候我們可以將系統(tǒng)進行水平拆分，然后進行水平擴容，一個不夠就增加兩個甚至更多。同時通過負載均衡的服務器將請求量均勻分給這些水平節(jié)點。通常我們會選擇使用 NG 來作負載均衡服務器。

上圖是我們的負載均衡服務器。負載均衡下面會有很多網(wǎng)關系統(tǒng)，我們看到中間有一個 Nginx 集群。我們都知道 Nginx 能夠承受的并發(fā)量非常大，所以流量小的時候不需要這個集群，需要它的時候一定是并發(fā)量非常大的情況。當你的并發(fā)量極大，到 Nginx 集群都無法承受的時候，我們最好不要在它的集群前面再放一層 Nginx，因為效果并不明顯。同時我個人也不太建議大家選擇 F5，因為 F5 是一個硬件，它的成本比較大。我個人建議大家選擇 LVS，它是 Linux 下面的一個虛擬服務，如果配置的好，它的性能完全比得上 F5。

說完了負載均衡，我們回到水平拆分。

在進行水平拆分時我們不能忽略緩存問題。在單機模式下緩存都是本地緩存，而當我們成為分布式后，如果有一個服務器拿到 token 并存到本地，另一個服務器就會因為沒有拿到而無法通信。因此我們引入分布式緩存，比如將緩存放到 Redis 這種分布式緩存里，讓所有應用都請求 Redis 拿緩存。

當我們水平拆分后，還需要關注分布式 ID。因為單體時候生成 ID 的方法可能不適用于分布式服務。以時間戳舉例，以前在單體時有，請求我們就生成一個 ID，這是有唯一性的。在分布式情況下多個服務器收到請求可能會生成重復 ID，做不到唯一性。所以我們需要單獨做一個 ID 服務來生成 ID。

配置中心

在我們把服務進行了水平和垂直的拆分后，如何讓配置統(tǒng)一同步的配置到每一個服務就成了問題。最好的辦法就是當我們修改配置后，讓所有服務都同時感知到這個更改，然后自己應用并配置。因此我們引入了配置中心。

上圖是配置中心的大體流程，目前比較流行的配置中心方案有兩個是，一個是阿里開源的 Nacos，另一個是 Spring Cloud 組建的 Spring Cloud config，感興趣的朋友們可以了解一下。

接下來我們具體看一下上圖。這其中 Server 是存放我們配置的控制臺。一般開發(fā)者會在控制臺通過 API 修改配置，修改后的配置可以持久放置在 Mysql 或其他數(shù)據(jù)庫內(nèi)。Client 包含了我們所有的應用，在它里面會有一個監(jiān)聽 Server 內(nèi)是否有配置更改的監(jiān)聽，當有配置更改時則去獲取這個配置，這樣所有的應用就可以在前端更新后及時更新了。同時為了防止 App 在獲取更新時因為網(wǎng)絡問題而獲取失敗的情況，我們會在本地做一個快照，當網(wǎng)絡出現(xiàn)問題時，App 可以降級到本地獲取文件。

數(shù)據(jù)庫拆分

我們完成了系統(tǒng)的拆分，做好了負載均衡，并完成了配置中心。在請求量不太大的情況下，我們其實已經(jīng)完成了系統(tǒng)的優(yōu)化。等到后期業(yè)務繼續(xù)擴張時，我們遇到的瓶頸就不再是系統(tǒng)，而是數(shù)據(jù)庫了。那么要如何解決這個問題呢？

第一種方式是主從復制與讀寫分離。讀寫分離可以解決數(shù)據(jù)讀寫全都在一個庫上的問題，通過將主從庫拆分為 master 和 slave，讓寫這一環(huán)節(jié)全部由 master 來處理，將寫的壓力分攤從而提高數(shù)據(jù)庫性能。之后隨著業(yè)務量的繼續(xù)增大，單獨的主從復制已經(jīng)無法滿足我們的需求時，我們通過第二種方式來處理。

第二種方式是進行垂直拆分。垂直拆分的概念和業(yè)務的拆分相似，我們根據(jù)服務將數(shù)據(jù)庫拆分為 Users、Orders、Apps 等等，讓每一個服務都擁有自己的數(shù)據(jù)庫，避免統(tǒng)一請求從而提升并發(fā)性。伴隨業(yè)務量的繼續(xù)增長，即便是單獨的庫也會到達瓶頸，這時我們就需要用到第三種方式。

第三種方式是水平拆分。比如我們將 Users 這個數(shù)據(jù)庫內(nèi)的表進一步拆分為 Users1，Users2，Users3 等等多個表。要完成這個拆分我們需要考慮，面對多個表我們在查詢時要如何去做的問題。這時我們需要按照我們的具體業(yè)務來判斷。比如查詢用戶，我們可以根據(jù)用戶 ID，將 ID 拆分分片，然后使用哈希算法讓他們統(tǒng)一在一定范圍內(nèi)。之后我們每次拿到 Users 就通過哈希來計算具體在哪一片并快速抵達相應位置。Auting 多租戶的設計就用到了拆分的概念，如下圖所示。

服務限流

等到業(yè)務量多到一定程度后我們肯定會涉及到服務限流，這是一個變相的降級策略。雖然我們的理想都是系統(tǒng)能夠承受越來越多的用戶越來越多的量，但是因為資源總是有限的，所以你必須要進行限制。

請求拒絕

服務限流有兩種主要算法，漏桶算法與令牌桶算法。我們可以看一下上圖，它畫的比較形象。漏桶算法中我們可以將流量想象成一杯水，在水流流出的地方進行限制，無論水流流入的速度有多快，但是流出速度是一樣的。令牌桶則是建立一個發(fā)放令牌的任務，讓每一個請求進入前都需要先拿到令牌，如果請求速度過快令牌不夠用時就采取對應的限流策略。除去這兩種算法，一般還會用到大家都很熟悉的計數(shù)器算法，感興趣的朋友也可以去自行了解一下，這里我們就不細談了。

這幾種算法其實本質(zhì)上都是在流量過量的時候，拒絕過量的部分的請求。而除去這種拒絕式的策略，我們還有一種排隊的策略。

消息隊列

當我們的業(yè)務有無法限流、拒絕的情況存在時，我們就需要用到隊列消息。

如圖所示，消息隊列的主要概念是生產(chǎn)者會將消息放入隊列中，由消費者從隊列中獲取消息并解決。我們通常使用 MQ、Redis、Kafka 來做消息隊列。隊列負責解決發(fā)布/訂閱和客戶端推拉兩個問題，生產(chǎn)者負責解決以下問題：

• 緩沖：為入口處過大的流量設置緩沖

• 削峰：與緩沖的效果類似

• 系統(tǒng)解耦：如果兩個服務沒有依賴調(diào)用關系，可以通過消息隊列進行解耦

• 異步通信

• 擴展：基于消息隊列可以做很多監(jiān)聽者進行監(jiān)聽

服務熔斷

在業(yè)務正常提供服務時，我們可能會遇到下圖這種情況：

服務 A、B 分別調(diào)用服務 C、D，而這兩者則都會調(diào)用服務 E，一旦服務 E 掛掉就會因為請求堆積而拖垮前面的全部服務。這個現(xiàn)象我們一般稱之為服務雪崩。

而為了避免這個情況的發(fā)生，我們引入了服務熔斷的概念，讓它起到一個保險絲的作用。當服務 E 的失敗量到達一定程度后，下一個請求就不會讓服務 E 繼續(xù)處理，而是直接返回失敗信息，避免繼續(xù)調(diào)用服務 E 的請求堆積。

簡單來講這是一種服務降級，通常的服務降級還有以下幾種：

• 頁面降級：可視化界面禁用點擊按鈕、調(diào)整靜態(tài)頁面

• 延遲服務：如定時任務延遲處理、消息入 MQ 后延遲處理

• 寫降級：直接禁止相關寫操作的服務請求

• 讀降級：直接禁止相關讀的服務請求

• 緩存降級：使用緩存方式來降級部分讀頻繁的服務接口

• 停服務：關閉不重要的功能，為核心服務讓出資源

壓測

上圖就是我們具體壓測要關注的東西。首先我們要知道壓測其實是一個閉環(huán)，因為我們可能會需要重復這個流程很多次，不斷地重復發(fā)現(xiàn)問題、解決問題、驗證是否生效、發(fā)現(xiàn)新問題這個過程，直到最終達到我們的壓測目標。

在壓測開始前我們會制定壓測目標，然后依據(jù)目標來準備環(huán)境。壓測模型可以是線上的，也可以是線下。一般線下考慮到成本問題，因此會選擇單機或小集群來進行，這可能讓結果不太精準，所以通常大家都選擇在線上或者機房來進行壓測，數(shù)據(jù)更精準。在壓測過程中我們會發(fā)現(xiàn)新的問題，然后解決它，并驗證結果直到達到壓測目標。

在壓測的過程中我們需要關注以下幾點。首先是 QPS，即每秒查詢量。它和 TPS 的區(qū)別在于，TPS 有事務的概念，需要完成事務才算一次請求。而 QPS 沒有這個概念，它只要查詢到結果就算做一次請求。其次是 RT（響應時間），這個需要我們重點關注，而且越是高并發(fā)的系統(tǒng)，RT 越重要。之后在壓測中我們需要關注系統(tǒng)到底能承載多大的并發(fā)數(shù)和吞吐量。成功率則是指在壓測過程中，當壓力越來越大的時候我們的業(yè)務是否能按照原計劃執(zhí)行并得到既定結果。GC 則是指垃圾回收，這也是個很大的問題，因為如果我們代碼寫的不好，那么隨著壓力的增大 GC 逐漸頻繁最終會導致系統(tǒng)停頓。

之后則是硬件方面，需要我們關注 CPU、內(nèi)存、網(wǎng)絡、I/O 的占有率，有一種任意一項卡主就有可能導致一個系統(tǒng)瓶頸。最后是數(shù)據(jù)庫，這里暫不展開細講。

日志

在壓測過程中發(fā)生的問題我們要如何才能知道呢？那就要依靠日志了，它讓系統(tǒng)變得可視化，方便我們發(fā)現(xiàn)問題的根源。

那日志要如何做呢？這里主要是依靠埋點來完成，比如通過埋點請求進入每一個系統(tǒng)、每一層的時間和響應時間，然后通過這兩個時間差看出系統(tǒng)的耗時。由此可以看出只有埋點清晰，才能精準發(fā)現(xiàn)問題的所在。

上圖是一個比較通用的日志處理方案，每一個服務產(chǎn)生的日志都是通過 Filbeat 收集到 Kafka，然后到 Logstach，最后到 ElasticSearch。其中 Kibana 是一個可視化界面，方便我們分析日志。

上圖是 Auting 的日志和監(jiān)控系統(tǒng)。中間是 K8S 集群，左邊是業(yè)務上的消息隊列，右邊則是我們的監(jiān)控系統(tǒng)。監(jiān)控系統(tǒng)我們只要是使用 Grafana 根據(jù)業(yè)務報警，比如我們會配置當成功率低于多少時就報警的情況。主要的日志系統(tǒng)則是使用 logstash 抽取 log 文件到 ES 內(nèi)使用 Kibana 查看。

最后，我想說的是所有的高可用系統(tǒng)一定不能忘記一個核心概念，那就是異地多活。舉例來講就是我們需要在多地備署多個機房，擁有多地備份和多地容災。上圖是我對上述全部的應用架構優(yōu)化進行的總結，希望能夠為大家提供參考，謝謝。

總結

以上是生活随笔為你收集整理的亿级流量系统架构演进之路的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。