背景
从2019年末，新冠疫情突然爆发，至今已持续了2年多。从不明病毒爆发，到武汉封城，再到现在防疫常态化，大规模核酸检测成为我们重要的防疫利器，而核酸检测系统的稳健和性能直接影响人们的工作和生活。
健康码崩溃！
冬季气温降低，更有利于病毒传播。2021年冬季，各地爆发疫情，迅速开展全民核酸检测。集中时间、地区的大规模核酸检测，导致高并发请求，极大考验了现有的核酸检测系统。 西安疫情爆发，一码通崩溃，核酸检测工作停滞，人员集聚风险增加，非常不利于疫情控制，负面舆论的影响也在扩散。类似的，还有粤康码超时、天津健康码崩溃等......
疫情爆发急、时间紧、数量大、干系繁、关注高、影响广，对防疫数字化产品的稳定性和性能提出了更高的要求。
科技向善
腾讯践行科技向善，致力于科技改变生活，构建智慧未来，履行社会责任。新冠疫情极大影响人们的日常生活和工作，腾讯云医疗行业责无旁贷推出了 SaaS 应用防疫通，和人们群众一起用数字化防疫利器共同抗疫。
医疗防疫通
12月23日，腾讯配合某省上线全员核酸检测系统并持续优化，支持全省多地市至少 4 轮的大规模核酸检测工作开展，实现居民打开微信即点即用，支持超 800W 人的用户申报及核酸检测。这款被选中的产品，正是由腾讯 CSIG 推出的防疫通。
以满足全省使用为目标，依托腾讯公司在云计算、大数据、人工智能等技术优势，辅助工作人员实现信息采集、条码绑定、样本监测、信息发布、查询统计等流程管理，并在系统性能及并发要求上采用流量分发排队、业务和统计分库分表、缓存技术、接口配置管理等方式完成性能指标要求及稳定运行。应用的产品包括：
- 防疫通大规模核酸检测系统（居民端、医护端、管理端）
- TCS 云原生技术底座、人脸核身、OCR 识别、短信等腾讯云资源
- 腾讯健康疫情服务工具箱、微信居民电子健康卡
TCS 临危受命
就像我们的手机安装了操作系统后，才能安装使用 App，我们需要一个底座，作为云的操作系统，来支撑防疫通私有化部署。为确保高性能、稳健运行，防疫通选择了已帮助近百款 SaaS 或 PaaS 产品部署的私有化交付利器——TCS。
TCS整体架构与能力概述
坎坷发展
“顺利上线？”
起初整个项目交付过程非常顺利，交付同学两天内就完成了 TCS 以及防疫通 SaaS 产品的部署。经过客户验收，以为就这样 “顺利上线” 了。
偶遇黑天鹅：IaaS IO 不稳定
锅从天降
上线没多久，现场反馈“医生打不开录入系统”、“系统掉线”......
果然，业务组件访问 redis 报错，紧接着客户现场支持群里就有用户反馈防疫通产品封箱操作掉线......
TCS 技术同学第一时间介入排查，发现集群执行基本运维指令异常卡、访问中间件集群异常……当时还纳闷，交付的这么顺利怎么会突然这么多问题？经过环境监控发现，客户 IaaS 虚拟机 IO 性能非常不稳定，数据盘 IO 利用率偶发性被打满，诡异的是并没有任何读写。
要注意 vdb、vdc 两块数据盘一块用于容器运行，一块用于 LocalPV（负责有状态服务的数据存储），这两块数据盘 IO 性能下降会导致数据库写入异常，会直接影响业务产品的可用性，同时也会影响 TCS 云原生技术底座的稳定性。
这锅，TCS 背的好辛苦......
屋漏偏逢连夜雨
前面磁盘性能差的问题还没彻底解决，紧接着又收到前线反馈运营端页面打不开......
定位过程中发现还是因为数据盘 IO 性能下降导致的连锁反应。数据盘 IO 异常情况下，会影响 TCS 底座 etcd 集群健康，导致依赖 etcd 选主的组件选主失败引发连锁反应，比如 LB 组件 keepalived-manager 。
在定位到是客户 IaaS 层磁盘性能恶化之后，第一时间联系了客户 IaaS 层提供商，提供了 IO 期间的监控截图，提出磁盘在没有读写的情况下 IO 利用率为什么会被打满的疑问？在 IaaS 层提供商分析之后确认到是底层存储池性能恶化导致。
同客户做了充分沟通和论证之后，同步是因为 IaaS 提供商提供的云硬盘性能恶化导致系统稳定性下降的结论。希望提供性能好一点的硬盘，并要保证磁盘本身性能，来避免硬件性能较差，影响核酸防疫通产品的稳定。
客户看到我们的论证数据，也是相当震惊：“这用的都是些什么烂机器？磁盘怎么这么差劲！我们直接上 SSD，库存不够的话马上提申请走采购流程，要全力保证防疫通系统稳定。”
本身 TCS 在入场交付前，是提供的有前置环境检查工具并要求要做前置环境检查的，区技同学在交付的时候漏掉了检查环节。当然我们后面在复盘此类问题的时候，也强调同步到了交付兄弟团队，前置检查作为交付前必须的环节，对不满足入场要求的环境要提前和客户提出提前暴露风险。
偶遇变成了常客：故障频发
更换磁盘之后，本以为可以睡个好觉。结果好景不长，因为 IaaS 层网络不稳定、业务产品上线前压测不充分等因素，在大规模核酸检测的时候，还是引发了一些系统不稳定的故障。
数据库连接数被打爆？
在交付的时候采用 TCS 作为云原生技术底座，这里依赖到的 MariaDB 和 Redis 用的 TCS 提供的 PaaS 产品能力。但这里数据库的一些参数比如连接数未经过特定场景优化，在大规模核酸检测的时候，真的就遇到了数据库连接数被打满的情况，数据库读写异常，导致产品功能可用性下降。
一开始对接的时候在公司内部是有充分测试的，用来做 SaaS 产品和 TCS 的接入联调。防疫通在 现场上线前，尤其针对大规模核酸检测这种场景，需要做严格的性能压测，数据库连接数被打满的问题正常是可以提前发现的。这里因为压测参数以及测试方案不充分的原因没能提前发现问题，导致防疫通产品在现场的稳定性下降。
TCS 本身提供了丰富的容器化中间件，包含 MariaDB、Redis、Zookeeper、Mongo 等，同时内置丰富的中间件状态监控。在业务反馈中间件异常的第一时间，TCS 私有化组以及中间件团队同学第一时间介入，通过稳定性大盘迅速定位到是数据库连接数过小被打满的原因，及时调大了数据库连接数，从而故障恢复并提升了产品稳定性。
缓存读取失败？
因为 IaaS 网络不稳定等因素触发 Redis sentinel 切主，导致业务侧读取 Redis 缓存失败的问题。这里为了优化切主过程对业务的影响，一方面和客户侧反馈 IaaS 网络不稳定的问题，一方面优化切主逻辑，调大对网络抖动的容忍时间、设置最大内存和内存清理机制，以及切主后 Redis Operator 对之前主节点进行长连接断开操作，避免切主后业务访问 Redis 只读的问题。
这里不得不说客户 IaaS 层的基础环境存在的稳定性问题确实不少......当然也是对 TCS 云原生技术底座的考验。经过一番分析和优化，TCS 对不同 IaaS 的适应能力也在逐渐增强。对异构 IaaS 环境的较好兼容适配，也是 TCS 云原生技术底座的一大优势。
IaaS 网络不稳定
客户 IaaS 层网络不稳定导致 MariaDB 数据库多主节点之间协商报错，进而导致核酸检测应用异常，用户感知明显。
产品又一次为客户基础设施不稳定背了锅......
挑战不断：“稳定性、高性能”
客户：“够稳定吗？”
因为其他省健康码崩溃， 该省卫健委对防疫通系统的稳定性也提出了灵魂三问：
“我们的系统够稳定吗？”
“会不会出现类似问题？”
“万一真的出现了怎么快速恢复？”
客户的每一次发问都是这么的直击人心。
为了解答客户关于稳定性方面的疑问，现场专门组织了一次稳定性架构评审会议，我们从 防疫通系统 到 TCS 云原生技术底座，从架构设计、弹性伸缩、限流策略、熔断降级、可观测性以及故障切换等角度详细阐述了使用 TCS 作为云原生技术底座的优势，经过和客户的一番答疑论证，最终客户对我们的汇报竖起了大拇指：“腾讯技术可以的
