深度 | 数字政通市民通——在疫情防控期间如何应对300万用户高频使用

新冠疫情防控期间，为更加有力配合和支持各地政府开展新型冠状病毒肺炎疫情的防控工作，数字政通自主研发微信小程序"数字政通市民通"在2月中旬按照疫情防控需求进行改造并上线，该程序提供了“肺炎自查“、”隔离自查”、“返工申报“、”电子通行证“、”肺炎知识“等多个疫情防控模块，为各地的疫情防控工作提供了有效的技术支撑。
数字政通研发的“网格化社区疫情防控系统”分为项目版（本地部署）和全国版（云端接入）。全国版即“数字政通市民通”小程序。在疫情防控期间，“数字政通市民通”用户数从日注册5000左右增长到日注册30万以上，截止3月底，注册用户数已达300万，且为活跃用户。为应对300万用户的高频使用，政通技术团队采用K8S集群对“数字政通市民通”系统部署进行了深度优化，具体内容详见本文。

1.项目部署架构

项目初期，初步预估用户增长较为平稳，采用的是传统ECS服务器自建MySQL数据库、自建缓存Redis、脚本启动Springboot微服务的方式进行部署和运维。在前期用户量增长缓慢时，系统性能和运维成本尚在可控范围内。

初期整体部署架构如下：

2.用户数指数增长时遇到的性能问题

2月中下旬，随着疫情的发展以及各地防控工作的有效推进，移动端用户数出现指数式增长，服务部署规模和架构逐渐暴露出请求响应慢、服务扩容费时、服务更新中断等运维问题。

2.1平台用户数连日暴增

2月20号开始，公司的推广力度增大，用户数出现了指数级增长。从中旬的日注册数5000左右，增长到日注册30万以上，累计用户达到百万级别。进入3月份，虽然疫情得到有效的控制，但截止当前，用户总数已达到接近300万。

2.2 Nginx静态资源响应压力大

受限于单节点出口带宽上限，单Nginx服务的吞吐量有限，开始暴露出无法支撑静态资源加载的问题。由于用户端无法在一定时间内获取到页面内容，日志中出现大量因前端取消请求后响应499问题。

小程序主要使用vue进行开发，打包的单页面js相对较大。比如截图中所示的js，单文件压缩后达到了345KB。在早高峰期间，一分钟内请求数达到接近300。按照3s响应到用户侧计算，这一个请求就需要消耗268Mbps的带宽。

300*353090*8/3/1024/1024=268Mbps

受限于阿里云弹性IP带宽上限200Mbps，造成大量请求超过60s都无法响应到用户侧。

2.3 Redis缓存数据库压力过大

由于用户并发数过多，缓存的用户token等相关信息过大，Redis内存占用持续过高，甚至发生过OOM killer。

同时单节点的Redis一旦出现故障，整个系统将完全宕机，隐患非常大。

2.4 Java后台压力过大

JVM忙于GC，消耗过多的CPU资源。

老年代内存使用率经常性达到99%。

虽然通过分析代码进行了部分优化，但在高峰期时，核心后台服务仍存在节点负载过高而无法及时响应的情况。

2.5 传统ECS部署方案扩容造成业务中断

在初期用户数量剧增时，曾通过对ECS升级配置规格（MySQL和Redis所在ECS节点）进行优化性能。而升配后，需要重启ECS实例，系统的中断造成的影响是巨大的，用户体验非常不好。

3.全面上云架构方案

经过评估，后续用户数量仍将持续指数增加，目前QPS已达到1000以上，后续预估将达到2000甚至更高。现有的部署架构已无法满足性能扩容和运维的需求。经过短暂的商定，我们决定用一天时间进行全面上云，使用Kubernetes集群管理所有服务。

整体架构如下：

3.1 DNS智能解析搭配双负载Nginx服务器

经过评估，单节点Nginx服务器已无法满足现有并发请求，通过DNS智能解析，可以将用户对域名的请求，均匀分到2台Nginx服务器上，以此实现Nginx服务的水平扩展。

针对入口负载均衡方案，这里还有一个小插曲。在部署期间，Kubernetes集群创建过程中，打包创建了SLB负载均衡实例。SLB负载均衡带宽上限为1Gbps，切换前期我们也是选择的此方案，但由于未注意到默认集群规格是简约型I（slb.s1.small），其QPS上限值为1000，对切换后的一个小时产生了严重影响。考虑到2台Nginx负载能达到10000以上QPS，我们去掉了SLB负载均衡，直接使用DNS智能解析分流到两台Nginx服务器。服务迅速恢复了正常，也节约了SLB负载均衡每小时的规格计费。

这里也建议大家在购买云产品实例时，一定要确认并评估好实际需求，选择合适的实例规格。

3.2 托管版Kubernetes容器化集群

阿里云容器服务 Kubernetes 版（简称 ACK）提供高性能可伸缩的容器应用管理能力，整合阿里云虚拟化、存储、网络和安全能力，为应用的全生命周期管理提供强有力的支持。考虑公司之前在项目上有成熟的私有云Kubernetes集群的技术实践经验，本次直接将所有前后台服务改造为容器化部署的时间满足一天内切换系统的需求。通过对比阿里云ACK服务，我们选择的是托管版 Kubernetes，只需创建 Worker 节点，Master 节点由容器服务创建并托管。具备简单、低成本、高可用、无需运维管理 Kubernetes 集群 Master 节点的特点，可以使我们只关注业务系统本身。

这里贴一张集群拓扑，目前所有服务均基于阿里云产品进行容器化部署。

创建Kubernetes集群有几个经验与大家分享

• Java服务容器一般内存消耗较多，建议采购1:4甚至1:8规格的ECS，如4C16G或4C32GB。
• 建议每个集群创建独立的交换机，便于管理POD与SVC的CIDR。同时为了与RDS等通信，建议复用原来的VPC。
• 交换机的掩码位数要合理设置，不宜过小，IP数量根据集群规模适当预留即可，以减少对整个VPC的IP数量占用。
• 如果业务场景确实要跨VPC，也可以通过云企业网打通跨VPC的内网通信。
• SLB负载均衡会有额外的小时配置费用，如果QPS达不到很高的级别（1万以上），不推荐上SLB。
• 阿里云的日志服务可以替换为自建的EFK，主要根据日志存储量评估下日志服务的费用。

3.3 动静分离CDN加速

CDN被誉为"互联网高速公路的最后一公里"，CDN将源站资源缓存到全国各地的边缘服务器，供用户就近获取，极大的降低源站压力。这点特性，恰好用来解决我们现在面临的静态资源加载问题。通过对比，我们最终选定了"全站加速"这款产品，支持智能识别动态静态请求、支持https。

在业务高峰期，带宽峰值接近400Mbps，静态文件的QPS突破800。虽然后台接口动态QPS是静态的2倍，但是由于响应包大小较小，静态请求由CDN分担压力后，Nginx响应速度得到大幅度的提升。

使用CDN的主要操作步骤

• 全站加速控制台添加CDN域名（设置回源域名、设置HTTPS证书等）。
• DNS域名解析控制台添加CDN域名及CNAME。
• html文件引入前端js或css时，使用CDN的绝对路径。
• 之后用户侧访问到CDN的地址后，CDN会自动从源站回源静态文件并缓存到CDN服务器，进而缓解了源站的压力。

我们在npm打包前端文件时，直接将需要替换CDN的地方写成了固定前缀EGOVA_CDN，之后在启动前端pod时，使用脚本替换为正式的CDN地址。这样做的优势是，一次打包，适配不同CDN域名的场景（如区分测试环境和生产环境）。

# deployment中的环境变量
- env:
  - name: CDN_REPLACE_FILES
    value: mobile-vue/*/index.html
  - name: CDN_SERVER
    value: https://****.egova.com.cn
  - name: CDN_PREFIX
    value: EGOVA_CDN

#对应触发的脚本
function replace_cdn()
{
  if [ "${CDN_REPLACE_FILES}" == "" ];then
       return 0
  fi
  [ "$(echo ${CDN_SERVER}|grep -E '^http*|^https*)'|wc -l)" -eq 0 ] && CDN_SERVER="."
  echo CDN_SERVER=${CDN_SERVER}

  [ "${CDN_PREFIX}" == "" ] && CDN_PREFIX="EGOVA_CDN"
  echo CDN_PREFIX=${CDN_PREFIX}

  for files in ${CDN_REPLACE_FILES}
  do
       sed -i "s#${CDN_PREFIX}#${CDN_SERVER}#g" /usr/share/Nginx/html/${files}
  done
}

3.4 RDS与云Redis替换本地部署，降低监控与运维成本

前面提到了自建数据库服务的弊端，为了减轻运维压力，使运维只专注于业务系统本身。决定将数据库迁移到RDS，并且使用云数据库Redis。迁移当晚，使用mydumper快速导出并导入到rds，整体业务中断时间相对可以接受。

#使用mydumper导出本地库
mydumper -u $u -p $password -h $host  -G -E -R -B $db -o $dbname/ -v 3 -t 16 
#使用myloader导入到rds
myloader -h ${pub_host} -u ${pub_user} -p ${pub_password} -B $dbname -q 25000 -d  ./$dbname/ -v 3 -t 16

使用了高配置8核64GB的RDS后，在用户数持续增加的十几天内，数据库持续稳定运行。但这中间也有个小插曲。RDS MySQL8.0版有个bug，默认存储引擎为TempTable，此模式下，执行部分group by会导致MY-013132异常，而异常sql查询的表数量其实很少。最后是提交工单，由阿里云售后工程师从后台改为Memory后问题解决（此BUG阿里云已在3月下旬进行了修正）。

2020-02-29T11:10:48.304107+08:00 96313 [ERROR] [MY-013132] [Server] The table '/home/mysql/data3066/tmp/#sql10956_17839_7' is full!

3.5 高性能NAS服务替换本地fastDFS方案

小程序后台的多媒体存储，在设计时使用了fastDFS分布式文件存储方案。考虑到云平台本身提供了NAS、OSS等分布式文件存储方案，服务容量和性能扩容便捷且集成监控、混合云备份服务（HBR） 等各种服务。NAS与Kubernetes中的存储层PV能直接集成使用，最终将多媒体存储方案更改为NAS高性能。

实践的结果显示，在搭配CDN后，多媒体存储层的性能完全不用担心，读压力已全部转义到CDN服务器：

从费用上考虑，OSS存储成本是NAS存储的30%，且OSS也可以作为Kubernetes PV挂载到deployment中，也可以使用ossfs工具挂载到磁盘进行基本的维护。长远考虑，还是要切换到OSS存储以节省费用。

4.切换后的性能表现

整体的改造工作量其实很大，涉及到方案制定、数据库迁移、多媒体迁移、镜像制作、Kubernetes服务编排以及整体功能完整测试。公司领导考虑到时间紧任务重，紧急协调了研发、测试、DevOps约十人协作，经过一个通宵的努力，成功的将由原服务进行了容器化集群部署，全面上云服务。虽然迁移后出现了SLB实例规格过低导致QPS上不去的小插曲，但由于快速发现了根源并予以调整，服务很快恢复了正常，至今已正常运行一月有余。

目前运行成果如下：

• 平台用户数达到接近300万
• 日活（DAU）最高达到80万
• 登录页PV最高突破250万
• 日发送短信验证数量最高190万次
• 同时在线用户数最高达到4万以上
• QPS峰值突破3500
• 压测QPS能达到1.3万

5.经验总结

• 对于互联网产品，除了正常预估用户增长幅度外，也要考虑到突发情况（比如新冠疫情）下的应对措施，提前在技术上有响应储备，便于应急时快速上线。此次公司"智慧市民通"虽然一晚上完成了全面上云的过程，但在这期间，业务系统处于中断状态，对用户来说，体验相对不友好。
• 云产品有很多种，一定要挑选适合自己的产品来构建系统，不能只考虑架构不考虑实用性。比如"智慧市民通"小程序，在目前300万用户量级别，使用SLB负载均衡实例除了浪费实例配置费用外并不会有多大的性能效果（推测达到千万级别用户时，SLB方能显示优势）。
• 阿里云产品（及其他供应商产品）各种计费模式要择优选取。比如针对纯后台api的外网出口ip，适合采用按流量计费的弹性公网IP，后台接口具有QPS高但流量小的特性，如果采用按照带宽计费，每月费用至少增加一倍以上。又比如对于静态文件的CDN加速，用户访问量比较平稳的情况下，按照带宽峰值计费会比按流量计费更为节省费用；而对于全天有早晚高峰的业务，按流量计费则更为划算。具体可以根据实际使用情况进行计算并调整。
• 百万用户量级别的产品，非常适合Kubernetes集群，服务的水平伸缩功能大大的提高了高并发性能。在业务量降低时，也能实现快速释放ECS资源，可节省很大的成本和时间。

来源：政通研发团队

往期回顾