杭马报名网站又又又又崩溃了|三点建议

今天上午杭马报名开始了, 你成功进入抽签池了吗? 如果是, 恭喜你; 如果没有, 也不用灰心, 这不是你的问题, 杭马报名网站又又又又崩溃了.
四个又仍然只是虚指, 简单在某博上搜索"杭马网站崩溃"甚至还能看见13年的动态, 可见杭马网站崩溃的历史是相当古早了. 具体发生了多少次, 不得而知.
作为一个曾经的Java不太老程序员, 让我简单分析下杭马官网崩溃的可能原因. 如果组委会有幸看到, 请改进下, OK?
客观原因, 流量真的很大
首先流量确实很大, 杭马是国内历史比较悠久的双金赛事, 规模达36000多人, 报名不可谓不火爆. 根据21年的历史数据, 刚开始的一个小时内就有2.2万人报名. 平均下来虽然每秒只有5次报名请求, 但流量往往不是均匀到达的, 在巅峰时刻或许有一秒数百次的报名请求. 此外, 一次成功的报名请求会伴随着数十次的网络资源请求, 对服务器的压力很大.
对于盈利敏感的淘宝来说, 这样的流量不算什么, 但是对于一年只用一次的杭马报名来说, 他们的技术架构太老, 又缺乏改进的动力, 用户蜂拥而至, 服务就显得捉襟见肘了.
陈旧的基建和技术栈
查看了下hzim.org
的网络请求, 希望能看出一些端倪.
基建&技术栈太老
首先我查看了返回的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 字段指示网站使用了 Servlet 2.4、JBoss 4.2.2.GA 和 Tomcat 5.5。这些都是相对较旧的版本(,Servlet 2.4 和 Tomcat 5.5 是比较旧的技术栈。Servlet 2.4 是 Java Servlet 规范的一个较早版本,发布于2003年。Tomcat 5.5 是 Apache Tomcat 服务器的一个较旧版本,发布于2004年),意味着网站正在使用过时的技术栈。这可能导致性能方面的问题,因为较新的版本通常会提供更好的性能、安全性和功能。如此低版本的Tomcat并发能力够用么?线程池容量够用么? 这么老的组件能发挥现在服务器的性能么?
第二个 X-Powered-By 字段显示网站使用了 JSF/1.2,这是 JavaServer Faces 的一个版本。同样,这也是一个较旧的版本,意味着网站的前端技术栈也比较陈旧。
除此之外, 我注意到杭马的网站极度依赖负服务端渲染, 一个简单的查询成绩和报名的功能都是服务端渲染并全局刷新页面, 这样服务器的压力很难降低.

数据库问题
考虑到这么陈旧的基建, 我很难相信网站服务端使用了缓存, redis之类的缓存中间件大约是2009年才出现的, 更广泛的使用是再之后的事情了.如果有, 可能也是内存缓存, 但不太可能, 因为内存缓存通常是在单个服务器机器上的, 如果用户跨机器请求, 缓存就无法命中了,也就失去了意义.
没有使用缓存, 数据库的流量都用会直接命中数据库. 早期的数据库能不能承担起蜂拥而至的瞬时流量, 我表示怀疑.
很多静态资源没有使用CDN
我注意到网站存在一些如 https://www.hzim.org/s/f/template/obj/515851065/templatecss/20230827205752491.css
的请求没有使用cdn, 而是直接放置在服务器中, 这样一个文件有55kb, 但是在假如有10000人同时访问, 10000 * 55 /1024 = 537Mb, 这还只是一个文件. 目测总有10个左右这样的文件, 这类文件不放置到cdn, 对服务器出口带宽整体的消耗不容小觑. 不过大多数静态文件还是放置到了CDN中. 考虑到有些读者不知道CDN, 简单科普下. CDN(Content Delivery Network)是一种分布式网络架构,旨在提供高性能、可扩展和可靠的内容传输服务。CDN 的主要目标是通过将内容分发到离用户更近的边缘节点,减少用户访问内容时的延迟和带宽消耗。
最后
马拉松报名网站只是一年一度地使用, 我认为杭马即便是背靠阿里的团队也没有动力去把网站优化得像淘宝一样流畅好用. 那么就没有什么方法能缓解热门赛事报名就崩溃的窘境么?
鉴于此, 我给出几点意见.
如果有可能, 还是优化一下网站,改进技术栈, 增加一点机器预算. 这是投入比较大的下策.
参考分枪起跑,采用分批次报名, 先马拉松然后是半程欢乐跑, 人为分流不要让流量一次性进入网站. 这是中策
中国田协出面来做一套更可靠的系统供各个赛事方使用. 这是上策. 不过嘛,不在其位,难谋其政 :)