技术分享：突然500万人来查，台风路径实时发布系统如何应对？
程序员文章站
2022-04-17 14:04:30
...
【编者按】近期台风肆虐沿海地区，给人民群众的生命和财产安全带来了很大的危害，如果可以及时了解台风信息，进行安全防范，显然可以规避很多损失。浙江省水利厅所做的台风路径实时发布系统是很好的信息预报平台。其背后是阿里云的支持。浙江省水利信息管理中心高级工程师骆小龙及阿里云工程师王徐就“台风的季节性带来IT系统访问量出现波峰波谷的巨大差异，机器的复用等问题”实践经验进行了深入的分享。
根据*气象台信息，台风苏迪罗将于8月8日登陆我国沿海，*、福建、江西、浙江、安徽、江苏等地将受影响。“台风到哪里了”，这两天又成了一个全民话题。
浙江省水利厅研发的台风路径实时发布系统，可以让任何一个人都能通过网络及时了解台风信息。但台风的季节性反应在IT系统上，是访问量波峰和波谷的巨大差异。随着关注度的提升，这种差异被不断拉大。台风来的时候需要紧急扩容，台风走了机器就闲置了。冗长的采购扩容流程和机器的复用等问题难以解决。比如：
服务器无法灵活的增删
先看一下网站近些年的业务量变化情况（由于缺少2012年及之前的数据故只能用现在的数据来让大家有个直观的感受）：
2012年“海葵”期间峰值PV达到350W，UV达到120W
2015年“灿鸿”期间峰值PV达到1434W，UV达到508W
这些业务高峰基本上都是每年的7月至10月间产生的，其余时间网站访问量只有几千。对，没错，就是几千。
从数据来看，三年时间网站的关注度有了近5倍的增长。与之对应的服务器数量，也是随着季节变化而变化。比如平常只需要2台服务器即可，但是台风来了就需要增加到12台，那么10台物理机采购就需要近30W块，但是台风过后这10台物理机又没有任何负载了，怎么安置他们又是个问题。未来，这一问题可能还会进一步加剧。
运维成本太高
由于浙江省水利厅内部IT平台较多，人员较少，没有办法安排专门的运维工程师和DBA来支持台风网站，平时都是由开发人员来兼职。需要每个月基于网站的访问情况和历史数据，对平台服务器数量进行评估、调整，人力和工作量较大。如果产品可以承担大部分的运维工作，做到自动化处理服务器的增删，数据库的备份等工作，那么将大大的节省了成本，并且能将更多的精力集中在台风平台的优化、业务逻辑优化上。
攻击无解
普通的IDC和自建机房最怕的就是大流量DDoS攻击，这种攻击会导致线路拥塞影响所有用户和业务。而应对这种攻击的办法只有硬抗并做进一步分析，将正常的请求过滤出来并转给应用。而这种传统的处理方式反应速度太慢。对于台风路径实时发布系统这种灾害预警网站，如果长时间无法打开，容易影响到台风期间大家的日常生活安排。毕竟现在通过手机就可以第一时间获取最新的台风位置等信息，非常便捷。
经过反复论证，2012年，浙江省水利厅选择将系统迁移到阿里云上，借助云计算的弹性应对巨大的峰谷差异。迁移分三阶段进行。
第一阶段实现弹性扩容
之前传统的方式会经常遇到“平常时刻好用不要用，关键时刻想用不能用”的尴尬局面。于是浙江省水利厅在2012年做出创新，将台风网站迁入阿里云，当时主要考虑到平稳上云，所以并未对网站架构等做大量调整。当初仅使用了阿里云的云服务器（ECS）、负载均衡（SLB）和开放存储服务（OSS）产品。上云之后，浙江省水利厅体会到了按量购买、快速调整的便利性，再无之前的顾虑。
当时的网站架构简单的描述如下：
经过这样的改造后，当年网站仅用5台云服务器就成功的支撑了峰值350W的访问量。
第二阶段增加数据库服务，应对移动端访问
台风网站下一步需要对外提供移动端的支持，一旦移动端开放了，那么访问量将会剧增，毕竟移动端的便利性是PC端无法比拟的。同时台风网站初次改版上云后发现使用开放存储服务（OSS）来做台风路径数据、云图数据的中转还是会有延时的问题。于是，浙江省水利厅又再次对网站架构及产品使用上做了如下调整：
由于台风路径数据同步周期为1个小时及以上，所以网站前端机没有必要每次访问都调用数据库。在网站前端机中配置缓存，节省数据库的资源，提升网站访问体验。
经过这样改造后，今年“灿鸿”期间，峰值PV达到1434W，UV超过500万，其中有1000W的访问量来至于移动端。
第三阶段，高防与优化
在实现第二阶段目标后，对于系统整体的高防和优选还在继续。比如：
台风路径实时发布系统本身也在优化，增加更多新功能。这些反馈到系统中，也还有很多技术需求。这都是未来工作的重点。
根据*气象台信息，台风苏迪罗将于8月8日登陆我国沿海，*、福建、江西、浙江、安徽、江苏等地将受影响。“台风到哪里了”，这两天又成了一个全民话题。
浙江省水利厅研发的台风路径实时发布系统，可以让任何一个人都能通过网络及时了解台风信息。但台风的季节性反应在IT系统上，是访问量波峰和波谷的巨大差异。随着关注度的提升，这种差异被不断拉大。台风来的时候需要紧急扩容，台风走了机器就闲置了。冗长的采购扩容流程和机器的复用等问题难以解决。比如：
服务器无法灵活的增删
先看一下网站近些年的业务量变化情况（由于缺少2012年及之前的数据故只能用现在的数据来让大家有个直观的感受）：
引用
2012年“海葵”期间峰值PV达到350W，UV达到120W
2015年“灿鸿”期间峰值PV达到1434W，UV达到508W
这些业务高峰基本上都是每年的7月至10月间产生的，其余时间网站访问量只有几千。对，没错，就是几千。
从数据来看，三年时间网站的关注度有了近5倍的增长。与之对应的服务器数量，也是随着季节变化而变化。比如平常只需要2台服务器即可，但是台风来了就需要增加到12台，那么10台物理机采购就需要近30W块，但是台风过后这10台物理机又没有任何负载了，怎么安置他们又是个问题。未来，这一问题可能还会进一步加剧。
运维成本太高
由于浙江省水利厅内部IT平台较多，人员较少，没有办法安排专门的运维工程师和DBA来支持台风网站，平时都是由开发人员来兼职。需要每个月基于网站的访问情况和历史数据，对平台服务器数量进行评估、调整，人力和工作量较大。如果产品可以承担大部分的运维工作，做到自动化处理服务器的增删，数据库的备份等工作，那么将大大的节省了成本，并且能将更多的精力集中在台风平台的优化、业务逻辑优化上。
攻击无解
普通的IDC和自建机房最怕的就是大流量DDoS攻击，这种攻击会导致线路拥塞影响所有用户和业务。而应对这种攻击的办法只有硬抗并做进一步分析，将正常的请求过滤出来并转给应用。而这种传统的处理方式反应速度太慢。对于台风路径实时发布系统这种灾害预警网站，如果长时间无法打开，容易影响到台风期间大家的日常生活安排。毕竟现在通过手机就可以第一时间获取最新的台风位置等信息，非常便捷。
经过反复论证，2012年，浙江省水利厅选择将系统迁移到阿里云上，借助云计算的弹性应对巨大的峰谷差异。迁移分三阶段进行。
第一阶段实现弹性扩容
之前传统的方式会经常遇到“平常时刻好用不要用，关键时刻想用不能用”的尴尬局面。于是浙江省水利厅在2012年做出创新，将台风网站迁入阿里云，当时主要考虑到平稳上云，所以并未对网站架构等做大量调整。当初仅使用了阿里云的云服务器（ECS）、负载均衡（SLB）和开放存储服务（OSS）产品。上云之后，浙江省水利厅体会到了按量购买、快速调整的便利性，再无之前的顾虑。
当时的网站架构简单的描述如下：
经过这样的改造后，当年网站仅用5台云服务器就成功的支撑了峰值350W的访问量。
第二阶段增加数据库服务，应对移动端访问
台风网站下一步需要对外提供移动端的支持，一旦移动端开放了，那么访问量将会剧增，毕竟移动端的便利性是PC端无法比拟的。同时台风网站初次改版上云后发现使用开放存储服务（OSS）来做台风路径数据、云图数据的中转还是会有延时的问题。于是，浙江省水利厅又再次对网站架构及产品使用上做了如下调整：
- 云服务器（ECS）里的网站环境部署及网站代码调整优化，与数据盘解耦，软件及数据全部放置到系统盘。使用该系统盘制作自定义镜像，后面扩容机器即可使用自定义镜像快速扩容无需重新配置环境和拷贝网站数据。
- 启用弹性伸缩服务（ESS），对同一角色的服务器性能评估并在SLB中自动完成扩容、缩容，解放人力、提升效率。
- 将台风路径数据从开放存储服务（OSS）里迁移到云数据库（RDS）中。可以保证各WEB服务器获取到的台风路径数据的实时性和一致性。
由于台风路径数据同步周期为1个小时及以上，所以网站前端机没有必要每次访问都调用数据库。在网站前端机中配置缓存，节省数据库的资源，提升网站访问体验。
经过这样改造后，今年“灿鸿”期间，峰值PV达到1434W，UV超过500万，其中有1000W的访问量来至于移动端。
第三阶段，高防与优化
在实现第二阶段目标后，对于系统整体的高防和优选还在继续。比如：
- 台风期间使用高防IP功能。高防IP是将大量攻击用户的流量引入到高防平台，由平台进行分析过滤，将正常的请求转发给真实的业务服务器。这块需要研究一下，如果台风网站用起高防，那么将不再担心DDoS攻击问题了。
- 网站架构持续优化。“灿鸿”期间的峰值PV里有70%的流量是来自于移动端，且网站的访问量增长剧烈。需要结合阿里云更多的产品，对自身架构上做些改造以应对未来的高速发展。
台风路径实时发布系统本身也在优化，增加更多新功能。这些反馈到系统中，也还有很多技术需求。这都是未来工作的重点。