核酸检测3秒背后的故事
背景
从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 作为云原生技术底座的优势，经过和客户的一番答疑论证，最终客户对我们的汇报竖起了大拇指：“腾讯技术可以的👍🏻”。
第三方压测团队：“性能不达标”？
为了满足 500 万人口的城市核酸检测系统的稳定性，客户提出了系统架构设计上要有冗余，架构要能撑得住 1000万人的核酸检测，客户压测团队通过模拟 三地约1000万常住人口在1至2天内的核酸检测，来摸底系统性能是否达标。
一开始时候因为第三方压测团队和我们防疫通业务团队没有充分沟通，单方面制定了一版压测方案，首轮压测结果极度不符合预期，现场客情一度出现焦灼。
TCS 技术团队也是大为惊愕，是不是哪里没沟通清楚？看了下压测方案，居然要求 14w 的 QPS……感觉这就是脑门一拍没有一点科学依据啊，压测结果这么低也不太能理解，一定是哪里没对齐。
为了搞清楚问题出在哪里，TCS 技术团队和防疫通业务同学还有现场的第三方压测团队来了一次面对面沟通，对齐了压测方案和压测目标，联合业务同学一起对业务架构做了复盘，对业务网关层以及后端 DB 做适当扩容，对前端网关接入层做适当资源调整，对负载均衡算法做优化，对客户虚拟机网卡中断优化以及 MariaDB 架构优化（强同步的多主架构改为异步同步的主从架构），以及对客户压测团队所使用的压测工具的压测参数提出了一些优化建议，并对压测集群扩容等。
经过多轮反复压测、链路分析、性能优化，压测结果有了明显提升。其中，单交易写 TPS （Transactions Per Second）提升69倍，单交易读 TPS 提升 6 倍，混合 TPS 提升 11 倍。远超客户现场第三方压测团队的压测目标值。
压测团队把压测报告交给客户的时候，客户一度不敢相信，经过我们对之前性能瓶颈做了详细分析后，客户再次竖起了大拇指：“腾讯技术果然强👍🏻”。
中心容灾：“多活架构/两地三中心”
西安健康码、粤康码、天津健康码相继出现崩溃的问题，再次引发客户的担忧：
“如果我们当前数据中心网络或者电力异常导致系统挂了怎么办？”
“是否可以支持两中心主备架构？”
“是否可以支持两地三中心架构？”
客户的担忧不无道理，一个数据中心本身也存在单点风险，防疫通这种业务关乎民生，应当最大限度的保障业务 SLA。春节前时间紧任务重，马上临近春运，省内外人员流动加剧，带来的就是核酸检测的频率会大幅度提升。
关键时刻一定不能掉链子。
TCS 技术团队收到客户需求之后，加班加点，调研客户现场环境。从硬件资源、到数据中心距离、网络延迟，以及业务架构依赖，综合考虑了各项条件限制，最终拿出一份中心容灾的方案给到客户，春节前快速建立起同城双数据中心的主备容灾架构。两数据中心的主备架构建设，有效地支撑了春节期间该省三地市大规模核酸检测的需求，系统运行非常稳定。
随着硬件资源在春节后的陆续到位，也在逐步开展两地三中心的架构建设。
产品思考
怎么定义一款好的产品呢？
必然是符合市场规律的
防疫通，为什么不能用公有云，必须搭载 TCS，私有化输出到客户现场呢？
这要从 SaaS 产品私有化说起。SaaS 产品的私有化部署往往能够满足其个性化定制的需求，且系统部署在本地，数据更加安全、可控。像政府、金融这种行业客户，在使用云平台的时候，还需要满足监管部门的安全合规需求。这种种市场需求表明，SaaS产品的私有化部署将长期在企业IT市场里占有重要的位置。
必然是直击客户痛点的
如果说公有云是开飞机，提供足够的算力，让用户直接使用就可以了，不需要关注运维等相关问题。那么私有化是把飞机卖到客户现场，让飞机停到客户的停机坪上，很可能要做改造、换发动机、教用户怎么开飞机等，这对私有化整个的交付运维能力提出了非常高的要求。
部署资源小型化、交付成本、运维问题、合规问题等一直是 SaaS 产品私有化上的巨大挑战。防疫通，也面临了这种难题。借助 TCS 云平台，只需三台机器可以拉起一套私有云云平台，6小时云平台一键部署完毕，且有完善的监控巡检体系，来辅助用户完成后期运维的工作。监控巡检体系能够帮助用户完成快速修复、执行简单变更，以及完成部分组件升级的任务，在一定程度上可降低人力成本。
合规方面，TCS 作为数字化抗疫的容器支撑平台，其上承载了大量的公民个人信息、防疫信息等敏感数据。因此支撑平台本身的网络安全、数据安全性成为重中之重。TCS 具备完善的网络安全及数据安全合规能力，可满足等保及密评的合规要求。从而应对大企业、政务、金融等各个行业对网络安全、数据安全、个人隐私信息保护的严格要求。与此同时，TCS 也通过了主流的信创厂商的兼容性互认证。
必然是经过客户验证的
TCS 不仅在抗疫现场经受住大规模、稳定性、突发性的考验，也支持了腾讯会议、腾讯企点、腾讯千帆 aPaaS、音视频、智能平台等近百款 SaaS 及 PaaS 产品的私有化部署。TCS 也是腾讯专有云 TCE 的底座，支持 TCE 服务了政务、金融、能源、交通、传媒等行业的100多家头部客户。
尤其腾讯会议，以 2000 PCU（Peak concurrent users）在线为例，最早评估需要5人2周来进行部署，经过培训后，只需要1人2天，熟练人员可以1人1天内部署完成。私有化部署效率的显著提升，使得腾讯会议在金融、能源、政务等行业快速推广。
必然是不断演进的
通过在防疫通和腾讯其他 SaaS 产品上的应用实践过程，TCS 对自身能力进行不断迭代和沉淀，逐渐走向成熟。既然能对腾讯的 SaaS 产品进行私有化输出，又拥有强烈的市场需求，那么是不是能够帮助行业的更多 SaaS 厂商实现私有化交付呢？
所以未来，Tencent TCS 团队会加大产品和技术投入，将 Tencent TCS 建设成为用户无感知的云的操作系统，只需一次编译，实现多处部署。“不重复造轮子”将成为 SaaS 产品私有化部署未来的演进方向，并且从面向腾讯 SaaS 产品的解决方案到助力行业其他 SaaS 厂商实现高效交付。腾讯云也正在朝着这个方向努力着。
TCS产品愿景
