“一天宕機三次”，為什麼高併發這麼難？-今日必看

“一天宕機三次”，為什麼高併發這麼難？

來源：小飛人釋出時間：2022-09-22 18:01

受訪者 | 陳皓作者 | 屠敏出品 | 《新程式設計師》編輯部

高併發，並不是一個新鮮的話題，全網際網路公司為之“費盡心思”多年，仍然無法完全逃脫卡頓、崩潰乃至宕機的宿命。

這不近日，一款名為“羊了個羊”的小程式遊戲溘然爆火，玩法雖簡單，但仍是沒有扛住無數挑戰了 2000 次硬是沒有一次把第二關玩過去、還要持以“扶我起來，還能再戰 500 回合”鬥志的網友帶來巨大流量的壓力，一日三次宕機時有發生，導致熱搜榜接連出現#又雙叒叕崩了#的話題。

行業中諸如此類的事件屢見不鮮，譬如，還有不久之前鬧得沸沸揚揚的東軟集團的核酸系統崩潰事件等等。那麼，放眼當下，是否會出現一種方式、一種系統、一種架構可以實現“永不宕機”且建築屬於高併發、高可用、高拓展的烏托邦？

現實來得很快，“絕對不會有！”，陳皓堅定地說道。

陳皓，或許大家更熟悉他在技術圈的暱稱——左耳朵耗子。深耕於網際網路和金融架構二十多年的陳皓，先後擔任阿里雲資深架構師、天貓開發總監、亞馬遜高階研發經理、湯森路透基礎架構師和高階研發經理，經歷過“雙 11”、阿里雲、AWS、Amazon 倉庫預測、實時金融資料釋出平臺、大規模平行計算等專案和產品研發，他於 2017 年創立了 MegaEase 公司，帶著「不改一行程式碼提升系統的效能和穩定性並支援秒殺」的目標，致力於將雲計算（PaaS/SaaS ）的那些高可用高併發的分散式技術普及到那些需要對技術自主可控的公司。

陳皓（左耳朵耗子）

近日，CSDN 與陳皓就屬於程式設計師的“三高”（高併發、高可用、高效能）問題進行了深入的探討，邀請他從自身經歷出發，分享“避免不了的宕機事件，那又該如何提升架構的穩定性以及做好防禦措施降低損失”的寶貴經驗，也希望藉此能夠為正在加急修復系統的程式設計師們帶來一些啟發。

20 年前 vs 20 年後做架構

CSDN：在 90 年代，你為什麼選擇計算機這條路？

陳皓：算是“誤入歧途”。本來是想做箇中學的物理或是數學老師的，也許會成為今天的李永樂。但是那時高考結束之後，同學和老師都說我的分數當老師有點浪費了，讓我學醫或是搞建築，我一看這兩個學科都是要學 5 年，覺得學不動，於是就學了個 4 年的計算機，因為感覺可以在上學的時候玩遊戲。

CSDN：隨著雲計算、大資料、AI 等技術的蓬勃發展，20 年前做架構設計和 20 年後的今天做架構設計，有什麼不一樣的感慨感染？

陳皓：以前做架構更像是做系統整合，主要是把各種系統拼裝在一起，那時只要是把它做出來就好了。

現在做架構除了要做出來，還需要考慮包括運維、工程管理等多方面的事情。當前很多架構都是使用分散式系統，然而這種方式帶來的問題就是亂，運維太過複雜，因此需要有一些頂層設計加以支援，如協議規範、中介軟體使用規範、服務治理規範、日誌規範、上線規範、故障處理規範等，而以前雖然需要這些，但並沒有這麼精細化。除此之外，還要在系統中放入很多關鍵的排程和觀測系統，如流量排程、服務排程、資源排程、資料排程、呼叫鏈、指標、健康度等等。

簡單地打個比喻：做架構好比是在建設新城市，以前進行架構開發就是在建設城市，建完就結束了；現在不僅僅是要建設城市，還要進行管理和排程城市，讓城市運作得更穩定、更經濟、更高效。

技術越來越成熟，但為什麼阻止不了宕機？

CSDN：僅在本月，成都核酸檢測系統異常、《羊了個羊》遊戲宕機等事件頻上熱搜......從技術維度來看，造成線上系統崩潰可能的原因有哪些？

陳皓：系統其實包括軟體和硬體兩個方面。拋開一些人為的故意因素不談，按照正常故障而言，宕機通常源於：

軟體到達執行的瓶頸。常見的情況有：頻寬佔滿或不足，對於不少公司而言，買夠足夠的頻寬，需要花費高昂的費用，因此不少系統採用 CDN 技術，這樣即使系統出現崩潰，但是網頁都能打得開（比如 12306）；還有應用的 CPU /記憶體過高，以及資料庫或關鍵中介軟體處理不過來，有單點故障導致系統打不開等等。

工程能力的問題。造成這一問題的原因是上線前沒有進行過相關的效能測試，亦或是企業內部沒有擴容和應急計劃，沒有足夠的運維工具和手段（如監控資料不足，沒有足夠的自動化的控制系統），不能快速解決問題。這就好像很多天災一樣，本質就是沒有科學的管理，不重視技術，災難來了後，才發現很多設計沒有到位，甚至都是錯的。

CSDN：多大併發才算高併發？對此，是否有一個通用的判定或界定標準？

陳皓：高併發沒有一個具體的數字來衡量，但是跟業務邏輯和應用場景很有關係。

第一種是像 12306 系統、銀行、電商等類似的業務場景，這些具備交易邏輯和複雜計算，有強一致性事務，這類的系統是最有挑戰的系統，因此調優使用到的技術手段也是非常多的。從我個人經歷來談，2013 年，我在阿里巴巴做“雙 11”時，交易業務使用到的伺服器大約有 1500 臺，當時是阿里第一次做全鏈路壓力測試，效能設定在了每秒 5-8 萬筆訂單左右。經過幾年下來，阿里最近的資料可以做到峰值每秒 60 萬單，平時每秒 10 萬單。除此之外，我經歷過的餓了麼系統在 2018 年時，一天有 3000 萬筆訂單，都集中在中午和晚上兩個飯點，而且這是需要實時處理的訂單，不過好在這個業務是地域性很強的業務，所以，很容易分庫分表，做多活也相對比較容易。

第二種是像微博這樣的社交類應用。相較前一種，這種應用透過沒有太過複雜的交易邏輯，屬於輕應用類，微博可以透過彈性擴容做到百萬併發，普通社交類應用實現幾萬至幾十萬的 QPS（每秒查詢率）也不算太難。這類的系統主要仍是透過下面幾種手段，一種是在各種環節加快取，一種是透過非同步和最終一致（這類系統基本不需要強一性，丟資料都無所謂），最後是透過 sharding 的方式把使用者請求分散式。

第三種是像影片類的應用。像影片類就更簡單了，不久前，劉德華的線上演唱會吸引了 3 億人線上，雖然聽起來數字非常龐大，但是從技術上來看，影片主要是廣播和內容分發，基本沒有互動邏輯。因此，用 CDN 這樣的分發網路很容易實現幾億人同時線上。以世界盃比賽為例，全世界幾十億的人觀看電視直播，這樣的高併發早就實現了，因為主要是廣播。

第四種是需要保證實時性的線上網遊等應用，不外，線上網遊通常是需要給玩家分割槽、分伺服器的，這樣一臺服務只能處理有限的玩家，一般來說也就是幾百個玩家，甚至更低。

整體而言，高併發與業務場景息息相關，在實現難易度上，偏交易型的第一種難度最高，其次是社交類，然後是遊戲，最後是影片。所以，我們可以看到很多論文或是術語都會提到 transaction，transaction 通常意味著比較大的複雜度。

CSDN：網際網路發展至今，虛擬化、分散式已經迭代多輪，為什麼還有那麼多大規模以及時間長的宕機事件發生？

陳皓：“這個世界上不可能存在一種 100% 穩定的系統”。

可以從兩個方面進行解析，一方面故障是不可避免的，有人為的故障（人是容易出錯的——Human Error）和非人為的故障（機器 Failure）。這些是無計劃的停機，還有有計劃的停機，如釋出新系統、進級維護、更新硬體等。這也是為什麼行業中即使部分公司做得再好也只能說自己能做到多少個 9，而非 100% 的主要原因。

當前，我們所能努力的就是儘可能地做到多少個 9，這其中需要很強的技術實力支撐。

級別	可用性級別	通俗說法	年度停機時間	配套措施
基本可用性	99%	2 個 9	3d-15h-39m-29s	服務在一個數據中心裡有冗餘，簡單基礎的自動化運維
高可用性	99.9%	3 個 9	8h-45m-56s	大量的自動化故障工具，以及各種控制排程系統等基礎設施要做好
具有故障自動恢復	99.99%	4 個 9	52m-35s	本地多機房（像 AWS 一樣每個地方都有三個可用區）
極高可用性	99.999%	5 個 9	5m-15s	遠端多機房，異地多活

另一方面，從分散式架構設計來說，我們認為這個世界上的軟體都是有故障的，當故障發生時，大家無非都是希望兩個事情：

故障不要蔓延開，能夠控制得住；

故障的時間越短越好，不要太長。

然而，架構系統也有很多的依賴，如基礎設施 DNS、CDN、運營商、機房等等，想要實現不亂，還需要大家一起來實現。

CSDN：當前多數公司普遍能做到幾個九？

陳皓：我相信一般公司在 90%-99% 之間，頭部公司都是在兩個九到三九之間，有技術的努努力可以實現三個九，不外四個九及以上需要耗費大量的人力、財力，對普通公司而言，具有極高的挑戰，基本不可能。

五個九的系統，我曾在路透的時候看過，所有的基礎硬體（包括電源、光纖、空調、機架、伺服器、交換機……）都需要在一個機房裡有雙份，而且要能防得住不可抗力（火災，地震，甚至核彈），然後還要租衛星，租專用的光纖甚至專用的海底光纜，不到要到中立的國家如日內瓦建資料中心，還要把歐洲，亞洲，美洲做成多活系統。這應該算是六個九的系統了，著實很花錢。

如何降低宕機事件帶來的損失？

CSDN：在過往的職業生涯中，你是否經歷過比較嚴重的宕機事件？亦或是在架構研發過程中，最具挑戰的一次經歷是什麼樣的？

陳皓：有挑戰的東西太多了，無論是做效能調優，仍是創新型專案，處處都是挑戰。圍繞高併發，早期在開發阿里巴巴聚石塔（由天貓攜手阿里雲、萬網宣佈聯合推出的一個“開放的電商雲工作平臺”），因為一次進級所有的服務都掛了，所有工程師加班加點，搶修 10 多個小時才恢復回來。

此外，早期阿里雲存在各種故障以及銀行系統宕機，都是非常嚴峻的挑戰。

CSDN：有時候像秒殺、雙十一等活動，可以是有足夠的預期準備時間，但是針對一些突發事件帶來的高流量，往往並不可控，系統架構應該在日常做好哪些應急措施，提高系統性能和穩定性，儘量減少損失？

陳皓：這種可以分為兩種情況，一種是預期流量（像做活動），可以透過評估、壓力測試，做好充足的事前準備。如阿里雙 11，提前做好預案。

第二種是非預期的流量。以我曾在路透做金融資料為例，對於一些突發事件，會造成股票交易的高峰，倘若系統出現崩潰，是一件很可怕的事情。因此，平時做效能測試時，除了要高過平時流量來應對高峰，還需要考慮時常。比如平時的流量是 100K/s，那麼效能測試時要做到 300K/s 以上。不外，這是有錢的做法。

如果沒有錢的話，就要透過雲計算的方式，實時擴容，微博就是這樣做的，他們可以在 5 分鐘內擴 1000 臺伺服器。最後，如果沒有資源了，只能走最極端的手段，即拒絕使用者訪問，比如在阿里的雙 11 就有這樣的預案，如果量太大，就先停西部，再停中部，保中心城市和東部，不行就保北上廣深等大城市。

這種預案在大公司非常常見，無論是國外的 Facebook、GitHub，仍是國內的阿里、騰訊等，這樣即使出現故障，造成的後續影響也會比一般公司好很多。

基於開源和技術手段，提高系統的高併發性

CSDN：2017 年，你創立了 MegaEase 公司，主要是想把雲計算（PaaS/SaaS層）的那些高可用高併發的分散式技術普及到那需要對技術自主可控的公司，經過 5 年的發展，MegaEase 發展是否達到您的預期？

陳皓：如果說，我們幫助了想要進步的公司，這個是達到預期的，因為幫助了他們更新了整個系統架構，降低了很多成本，提升了技術實力。

不外，也還有很多公司是沒有幫到，這個還沒有達到預期。因為分散式架構、雲原生的技術門檻依然很高，為此，我們也想要把這個門檻降得再低一些，包括實施的成本。因此，從去年開始，MegaEase 著重開源建設，並且著手研發一個雲原生平臺，以及一個知識平臺，讓使用者可以容易地獲得雲原生的知識以及使用雲原生的技術。

一定程度上，可以說雲原生本身就是一個比較高的門檻，很多東西需要封裝起來，讓它變得更簡單應用。

CSDN：早期，你曾分享過一句話，“不改一行程式碼提升系統的效能和穩定性並支援秒殺”，這樣的願景也是不少開發者夢寐以求的事情，那麼，是如何實現這一點的？

陳皓：是的，就是不改一行程式碼做秒殺！請注意，這裡指的是秒殺場景。所謂秒殺場景，其本身具有特殊性，比如某個參與秒殺活動的產品，在參與人數達到百萬人時，實際的產品數量只有 1000 件。在設計系統架構時，首先得保證系統能夠扛住一百萬的流量，然後透過一箇中間件，如 MegaEase 開發的 Easegress 閘道器，先是扛住前面整體的流量，然後再將最先參與秒殺的 1000 名使用者放進來中獎，隨後活動結束。

遵循這樣的邏輯，基於開源軟體 Easegress 就可以做到這一點。使用方法可以參考Easegress在 GitHub 上的技術文件：https://github.com/megaease/easegress/blob/main/doc/cookbook/flash-sale.md

CSDN：這也是雲原生流量排程服務 Easegress 誕生的初衷？相比競品，Easegress 具有哪些優勢？

陳皓：其實行業中有 IaaS 層做資源排程、有 Kubernetes 做服務排程編排、有分散式資料庫或 NoSQL 做資料分散式排程，但是缺乏流量排程，而流量又是所有分散式技術根因，是一件非常重要的事。我們覺得這個問題非常重要，於是便開發了 Easegress。

相比業界已有的一些解決方案，Easegress 採用的不是反向代理，而是全功能性的流量閘道器，它具有流量著色排程和編排、業務擴充套件等優勢，支援多種程式語言，可以應用在秒殺、灰度、服務治理、全連結壓力測試、工作流、API 編排、FaaS/Serverless 等場景與工作中。

圖源：MegaEase 官網，Easegress 架構圖

CSDN：Easegress 採用的是開源的方式，根據當前技術發展的趨勢，開源是一種避不開的創新策略，開源為軟體架構開發帶來了怎樣的影響？

陳皓：開源肯定是避不開的。現在所有的公司，或多或少都在用開源軟體。這其中包含了幾層因素：

一，開源免費，基於開源，可以有更低的成本。

二，開源更容易與企業內部的軟體解決相容問題。

圍繞開源，可以獲得更多的客戶和開發者。另外，開源也可以建立技術社群和開發者網路，它是一種能夠以最低成本、最容易建立社群的方式，樹立品牌宣傳。

此外，我也認為開源是唯一一個可以與大公司閉源產品競爭的方式，好比 MySQL 和 Oracle 競爭、Linux 和 UNIX 競爭。尤其對於小型創業公司而言，初創業時的產品很難獲得業界信任，但是開源可以讓大家清晰地看到產品和技術實力，而且可以省去那些商務流程，技術人員和技術人員直接對話，拓展使用者的成本就更低了，這基本是一種網際網路的思維方式——產品老是從免費開始的。

CSDN：有些企業做開源可能會存在盲目跟風的趨勢，甚至導致開源之後選擇閉源，在你看來，企業做開源的正確態度是什麼？

陳皓：我覺得是這樣的，各個公司開源都有不一樣的目的，有的是不得不開源，這類正常是使用了開源軟體，在開源協議下也必需要去開源，屬於被動開源。還有的是主動開源。然而，開源不是把原始碼開放出來就結束，還需要有後續的執行等，開源軟體不是由某個公司私有化運作的，而是由社群來運作，像現在 TOC、開源辦公室，所做的每一個技術決定都是一群人來做的，而不是這家公司。

因此，想要正確地保持開源的活躍性，有以下幾點建議：

真心喜歡開源、不要想著透過開源掙錢，開源類似於一種公益事業；

開源軟體和其它軟體一樣，能夠解決使用者的需求和痛點；

開源要有一種開放的心態，開源其實是一種民主活動；

開源主要是要建立開發者社群，與更多的開源相容，不只是開放原始碼。

一款好的架構需要具備哪些前提？

CSDN：不少架構師似乎有這樣一個共識，“一款好的架構並不是設計出來的，而是進化出來的”，對此，您是否贊同這一觀點？

陳皓：一定程度上，這兩句話是不衝突的。事實上，好的架構一定是設計出來的，而且仍是精良設計的，不然就是系統集成了。

不外，軟體設計也是一種 Trade-off （權衡）的取捨過程。隨著公司不同時期的發展，不同的階段有不同的重點，導致 Trade-off 也不一樣，處於不斷進化過程。因此，我認為這句話應該這麼說，“一款好的軟體必須是經過精良設計的，精良的設計是不斷演化出來的”。

CSDN：構建高可用、高效能、高併發的系統架構多年間，有沒有一直在遵循的原則可以與我們分享？

陳皓：這其中涉及的東西太多了，這裡我只能籠統簡單地說說了，從一些通用的維度來分享：

首先要了解業務特性；

透過資料分析；

使用分散式的方式（業務使用者資料流量分片或冗餘、加快取、降低一致性要求、非同步系統等等）；

不要魔改，要堅持功能高於效能，先做對、再做快的理念。

CSDN：對於架構師而言，現在小公司不談高併發，大公司入門門檻便是高併發，在程式設計師向上升級的過程中，他們該如何獲取高併發方面的經驗，需要具備哪些不可或缺的技能？

陳皓：行業中的技術大佬總要帶徒弟，因為他一個人幹不了所有事情，正所謂一個籬笆三個樁一個好漢三個幫。因此，問題就是如何成為他們的徒弟？

要想成為技術專家的徒弟，首先自身需要具備一定的潛力，這前提就是需要開發者基礎能力過硬，對於高併發開發而言，基礎知識包括網路、作業系統、中介軟體、演算法、資料結構等等。在此基礎上，剩下的就是積攢經驗。

結合我的個人經歷來談，最初從大學畢業開始，我也並沒有如今這些經驗。記得我曾經入職一家企業，對方讓我做業務，但是我並不想做業務，而是想從事系統相關的開發。

在工作的第一天，對方告訴我，如果有什麼問題，可以去公司內部的論壇裡面提問，會有人來幫你解決問題。後來，我看到論壇的一些板塊中，有很多基礎性的技術性問題，只有提問，沒有人回答。於是，我就把那些問題全部回答了。最終迎來了意外之喜，在入職第一天臨近下班時候，我特別想去的那個核心開發團隊經理便來邀請我加入他們團隊。

因此，只要自身基礎知識過硬，就值得別人來帶領入門，然後自身再不斷學習，不斷夯實，就會有成長。

CSDN：你曾分享過「技術的發展要根植於歷史，而不是未來」，現在是否還這麼認為？當下的開發者該如何跟上技術時代的步伐？

陳皓：可以用“踢足球”來比喻，當踢足球時，我們總是會沿著足球運動的軌跡去跑，而要想跑在球的前面，必須判斷足球的走向，你要知道球往哪跑，你就要看足球運動軌跡。技術發展亦是如此，如果要知道往哪裡走，你就要看技術的發展軌跡，所以，你要看整個技術發展史，從中歸納總結，你就知道要去哪裡了。

從歷史中不斷地看技術的變化路線，也要學會在變化中找到一直不變的東西。

另外，技術更迭，不要一直追新，往往有競爭性的新技術具備以下幾種特性：

有殺手級應用：無論是什麼技術，它一定要是能解決痛點問題的。

有大廠的支援：需要明白，大公司不會把錢浪費在一些“無用功”上，它一定會投資一些有價值的技術。譬如 Go 語言的背後是 Google、Java 的背後亦是很多巨頭公司支援的。

有強大的社群支援。

只要具備以上三點，我認為這個技術就可以全身心地投入進去。否則，建議大家先做觀望。

CSDN：對此，是否有一些面向雲時代的書籍推薦給開發者們？

陳皓：其實，雲原生時代包含了很多內容，我覺得最好的兩本書是《微服務架構設計模式》和《 Designing Data-Intensive Applications》（資料密集型應用系統設計）。除此之外，也建議大家多讀讀官方文件。

One More Thing

CSDN：畢業之後從國企到在亞馬遜、阿里巴巴、湯森路透再到自己創業，這一路走來，對自身無論是從技術上仍是管理上，要求都非常高，一直以來，保持持續學習的動力是什麼？有什麼樣的學習方法？

陳皓：首先，學習需要有動力。我最早學習的動力就是害怕失業，因為最初我決定放棄人人眼中的鐵飯碗——銀行的工作，隨後到網際網路浪潮中求職，恰遇 2000 年的網際網路經濟泡沫，很多公司相繼倒閉，這也讓我產生了很大的落差，當時只有一個想法，“如果最初花費力氣做下的決定，再失業，狼狽的跑回家，很多人都準備看你失敗的笑話”。所以，那時也有背水一戰的感覺，不能失敗，必需要去學。

第二個動力就是獲得成就感。當學到一定的時候，就會有一定的基礎解決一些技術問題，然後別人會給到很多的正反饋，包括創業也是。

其次，在學習方法上，我覺得最重要的是學會掌握資訊來源，因為資訊源不好的話，其實會有誤導性。所以我喜歡看一些英文的資料，然後應 Google 搜尋引擎。另外，學習一定要多問為什麼，多找最佳時間，多比較技術的優點和缺點（Pros/Cons），尋找最適合自己的。

CSDN：從銀行離職，到入職各種不同規模的公司，再到現如今的創業，期間是否有後悔過最初的決定？

陳皓：沒有！我覺得這是我迄今為止做的最正確的一個決定，從來沒有後悔過！甚至覺得還好當初在 24 歲的時候便做了這個決定。現在只是說如果在 2017 年創業的時候，要是能再早個五六年就好了。

CSDN：作為公司創始人，你現在還會經常寫程式碼嗎？可否簡單分享一下你的技術棧演進路線？

陳皓: 會寫的，現在我的時間太過碎片化，寫程式碼的時間大概佔 30%。

過去多年間，我的技術也在不斷變化：

後端：C -> C++ -> Java -> Go

Web：Perl -> ASP -> PHP -> Java、jQuery -> React.js

作業系統：Unix/Windows -> Linux

部署：Ansible -> Docker -> Kubernetes

架構：單機 -> CS -> BS- > 三層架構 -> SOA -> 微服務 -> 雲原生