平台的首场考验一项全国性赛事圆满结束了,现在有时间回顾总结一下,便于继续前进。
1、微服务架构的弹性伸缩机制非常实用。赛事期间根据流量监控情况,可以随时启动新的服务应对大流量变化。新启动的服务在nacos的调度下动态加入服务序列。nice!
2、根据几天下来持续跟踪,这样业务场景,CPU资源、内存资源不是问题,真正的瓶颈在带宽。由于租用的是云服务器,带宽资源也可以临时增加,增加的最小单位是周,正好覆盖比赛周期。所以平常维持10M带宽,一旦比赛可以临时加到30M(只需一周),即获得很好的效果花钱也不动。
3、批量生成参赛证、批量下载伴奏这些操作瞬间会把cpu拉满到100%。所以循环中要主动减速,sleep下(今年暂时使用了这个办法了 因为整体上只用了1个服务器,明年考虑增加服务器)
4、同上把后端业务操作 和前端操作(指小程序)分别走两个网关可以分流。今年只用了一个springgate,这里成为瓶颈。
5、小程序端,不要高估操作人的水平。本来报名设计了暂存和提交两个按钮,可以暂存输入结果,最后再提交。总有人不提交。还有类似的情况,例如集体节目报名流程明明写的很清楚,总是报成多个个人节目。
6、收费、退费各种情况很多,要设计好表格,方便对账。尤其微信支付是异步操作(提交申请后,等微信来调你的回调接口来返回信息)会造成信息不同步,甚至有丢失情况。
7、获奖证书、参赛证会重复生成,如果每次在minio里产生新文件,会造成大量空间浪费。所有第一次生成时获取文件名,重复生成时才有文件名不变,文件覆盖原来旧的
=======持续总结中=====