今天上午杭馬報名開始了, 你成功進入抽簽池了嗎? 如果是, 恭喜你; 如果沒有, 也不用灰心, 這不是你的問題, 杭馬報名網(wǎng)站又又又又崩潰了.

四個又仍然只是虛指, 簡單在某博上搜索"杭馬網(wǎng)站崩潰"甚至還能看見13年的動態(tài), 可見杭馬網(wǎng)站崩潰的歷史是相當古早了. 具體發(fā)生了多少次, 不得而知.

作為一個曾經(jīng)的Java不太老程序員, 讓我簡單分析下杭馬官網(wǎng)崩潰的可能原因. 如果組委會有幸看到, 請改進下, OK?

客觀原因, 流量真的很大

首先流量確實很大, 杭馬是國內(nèi)歷史比較悠久的雙金賽事, 規(guī)模達36000多人, 報名不可謂不火爆. 根據(jù)21年的歷史數(shù)據(jù), 剛開始的一個小時內(nèi)就有2.2萬人報名. 平均下來雖然每秒只有5次報名請求, 但流量往往不是均勻到達的, 在巔峰時刻或許有一秒數(shù)百次的報名請求. 此外, 一次成功的報名請求會伴隨著數(shù)十次的網(wǎng)絡資源請求, 對服務器的壓力很大.

對于盈利敏感的淘寶來說, 這樣的流量不算什么, 但是對于一年只用一次的杭馬報名來說, 他們的技術架構太老, 又缺乏改進的動力, 用戶蜂擁而至, 服務就顯得捉襟見肘了.

陳舊的基建和技術棧

查看了下hzim.org的網(wǎng)絡請求, 希望能看出一些端倪.

基建&技術棧太老

首先我查看了返回的header

HTTP/1.1?200?OK
Date:?Mon,?28?Aug?2023?06:14:53?GMT
Content-Type:?text/html;charset=UTF-8
Transfer-Encoding:?chunked
Connection:?keep-alive
X-FRAME-OPTIONS:?SAMEORIGIN
X-Powered-By:?Servlet?2.4;?JBoss-4.2.2.GA?(build:?SVNTag=JBoss_4_2_2_GA?date=200710221139)/Tomcat-5.5
X-Powered-By:?JSF/1.2
Set-Cookie:?tslanguage=;?Path=/
Set-Cookie:?tslanguage=;?Path=/
Content-Encoding:?gzip
Vary:?Accept-Encoding
Set-Cookie:?SERVERID=4936242e6e0aab9cf6b2968c3140d0a1|1693203292|1693203282;Path=/
Strict-Transport-Security:?max-age=31536000

第一個?X-Powered-By?字段指示網(wǎng)站使用了 Servlet 2.4、JBoss 4.2.2.GA 和 Tomcat 5.5。這些都是相對較舊的版本(，Servlet 2.4 和 Tomcat 5.5 是比較舊的技術棧。Servlet 2.4 是 Java Servlet 規(guī)范的一個較早版本，發(fā)布于2003年。Tomcat 5.5 是 Apache Tomcat 服務器的一個較舊版本，發(fā)布于2004年)，意味著網(wǎng)站正在使用過時的技術棧。這可能導致性能方面的問題，因為較新的版本通常會提供更好的性能、安全性和功能。如此低版本的Tomcat并發(fā)能力夠用么?線程池容量夠用么? 這么老的組件能發(fā)揮現(xiàn)在服務器的性能么?

第二個?X-Powered-By?字段顯示網(wǎng)站使用了 JSF/1.2，這是 JavaServer Faces 的一個版本。同樣，這也是一個較舊的版本，意味著網(wǎng)站的前端技術棧也比較陳舊。

除此之外, 我注意到杭馬的網(wǎng)站極度依賴負服務端渲染, 一個簡單的查詢成績和報名的功能都是服務端渲染并全局刷新頁面, 這樣服務器的壓力很難降低.

數(shù)據(jù)庫問題

考慮到這么陳舊的基建, 我很難相信網(wǎng)站服務端使用了緩存, redis之類的緩存中間件大約是2009年才出現(xiàn)的, 更廣泛的使用是再之后的事情了.如果有, 可能也是內(nèi)存緩存, 但不太可能, 因為內(nèi)存緩存通常是在單個服務器機器上的, 如果用戶跨機器請求, 緩存就無法命中了,也就失去了意義.

沒有使用緩存, 數(shù)據(jù)庫的流量都用會直接命中數(shù)據(jù)庫. 早期的數(shù)據(jù)庫能不能承擔起蜂擁而至的瞬時流量, 我表示懷疑.

很多靜態(tài)資源沒有使用CDN

我注意到網(wǎng)站存在一些如?https://www.hzim.org/s/f/template/obj/515851065/templatecss/20230827205752491.css?的請求沒有使用cdn, 而是直接放置在服務器中, 這樣一個文件有55kb, 但是在假如有10000人同時訪問, 10000 * 55 /1024 = 537Mb, 這還只是一個文件. 目測總有10個左右這樣的文件, 這類文件不放置到cdn, 對服務器出口帶寬整體的消耗不容小覷. 不過大多數(shù)靜態(tài)文件還是放置到了CDN中. 考慮到有些讀者不知道CDN, 簡單科普下. CDN（Content Delivery Network）是一種分布式網(wǎng)絡架構，旨在提供高性能、可擴展和可靠的內(nèi)容傳輸服務。CDN 的主要目標是通過將內(nèi)容分發(fā)到離用戶更近的邊緣節(jié)點，減少用戶訪問內(nèi)容時的延遲和帶寬消耗。

最后

馬拉松報名網(wǎng)站只是一年一度地使用, 我認為杭馬即便是背靠阿里的團隊也沒有動力去把網(wǎng)站優(yōu)化得像淘寶一樣流暢好用. 那么就沒有什么方法能緩解熱門賽事報名就崩潰的窘境么?

鑒于此, 我給出幾點意見.

• 如果有可能, 還是優(yōu)化一下網(wǎng)站,改進技術棧, 增加一點機器預算. 這是投入比較大的下策.

• 參考分槍起跑,采用分批次報名, 先馬拉松然后是半程歡樂跑, 人為分流不要讓流量一次性進入網(wǎng)站. 這是中策

• 中國田協(xié)出面來做一套更可靠的系統(tǒng)供各個賽事方使用. 這是上策. 不過嘛,不在其位,難謀其政 :)