成都核酸檢測系統崩潰，成了這兩天的熱點。
關鍵時刻緊急上線，東軟稱與我無關；官方稱對短時超大併發量預估不足，導致系統出現卡頓問題。四川通管局稱沒有出現網絡擁塞和故障。
這件事誰是誰非，局外人說不清楚。就我以往經驗來說，如何在高併發場景下，達到高性能，做到高可用，擅長行業應用的傳統軟件開發商是惰于思考的。一方面可能甲方投入太少，另一方面也不具有互聯網應對經驗，系統往往停留在單體架構，不支持彈性擴容，沒法擴展。
政務信息化項目現在都在上雲。但重在建設雲資源，資源供給粗放。政務應用系統與雲資源缺少協同，系統上雲架構未上雲，分層設計，資源和應用相互獨立，未能充分利用雲資源彈性和分佈式優勢。
一碰到流量上來，就要求甲方擴容，增加網絡帶寬，增加計算性能、存儲性能；出了問題，就是網絡故障，服務器性能不夠，把問題拋給基礎設施服務商，反正他們離用戶遠嘛。
高併發代表着大流量，一個高併發系統應該靠架構設計，抵抗巨大流量的衝擊，帶給用戶良好的使用體驗。
面對高併發，擴容，是最簡單粗暴懶惰的方式。
除了擴容，在應對高併發大流量時，一般還有三種方法。
一是分佈。分而治之是一種常見的高併發系統設計方法，採用分佈式部署的方式對流量分流，讓每個服務器都承擔一部分併發和流量。
二是異步。在某些場景下，一個用戶請求未處理完成之前，可以先反饋請求，在數據準備好處理好之後再通知用戶結果，這樣可以在單位時間內處理更多的請求。
三是緩存。把一些時效性不強的數據臨時存儲在用戶端或者服務器前端，避免與數據庫或服務接口過多交互。使用緩存來提高系統的性能，就好比修個水庫抵抗洪水的衝擊。
只是，這些方法都需要軟件開發商對系統進行改造，甚至是動大手術，遠不如一句“擴容”來得簡單。
傳統軟件開發商做行業客戶，講故事的多，面對互聯網的極限挑戰不多，系統設計很少考慮高併發的場景。因爲不同量級的系統有不同的痛點。
淘寶、微信、抖音的系統雖然能夠解決同時百萬、千萬人同時在線的需求，但其內部的複雜程度也遠非我們能夠想象。盲目追求高併發下的高可用，只能讓我們的架構複雜不堪，最終難以維護。這是靠財政資金無力支撐的。
但從單體架構往分佈式演進來說，淘寶也是在經歷了多年的發展後，發現系統整體的擴展能力出現問題時，開始啓動服務化改造項目的。
淘寶當時在業務從 0 到 1 的階段，通過購買的方式快速搭建了系統。而後，隨着流量的增長，阿里做了一系列的技術改造來提升高併發處理能力，比如數據庫存儲引擎從 MyISAM 遷移到 InnoDB，數據庫做分庫分表，增加緩存，啓動中間件研發等。
當這些都無法滿足時，就需要對整體架構做大規模重構。比如說著名的“五彩石”項目，“先花它2000億”，讓淘寶的架構從單體演進爲服務化架構。
正是通過逐步的技術演進，淘寶才進化出如今承擔過億 QPS （每秒處理事務數）的技術架構。歸根結底一句話：高併發系統的演進應該是循序漸進，以解決系統中存在的問題爲目的和驅動力的。
如果都按照百萬、千萬併發來設計系統，電商一律向淘寶、京東看齊，即時通訊全都學習微信和 QQ，那麼這些系統的命運一定不長久。
羅馬不是一天建成的，系統的設計也是如此。我們熟知的 12306 網站，也是一步步實現大型高併發系統架構。
一個成熟的系統，在業務流量平穩時就要考慮隨時可能出現的高併發需求場景，並在流量和併發不斷提升的情況下，一步步地優化它，具備應對能力。一夜之間上線就去應對高併發的需求場景，崩潰是必然的。
源不深而望流之遠，根不固而求木之長，不可矣。
