腾讯终于把云原生改造说明白了

今年 9 月，一家云原生数据仓库厂商上市，上市当天市值即破 700 亿美元，成为软件史上最大 IPO。更令人惊讶的是，从不投资上市公司的巴菲特，破例以 IPO 价购买价值 2.5 亿美元的股票，还从现股东处额外购买 404 万股原始股。

云原生，这个生于云、长于云、号称是“下一个云时代”的技术体系，已经流行起来了。

Gartner2019 年的报告曾预测，“2020 年，有 50% 的传统老旧应用被以云原生化的方式改造，到 2022 年，将有 75% 的全球化企业将在生产中使用云原生的容器化应用”。前者与 CNBPA 组织完成的《第二期 (2019-2020) 云原生实践调研报告》中得到的数据相符。

前不久，CNCF 进行的第八次云原生调查显示，在全球疫情大爆发的背景下云原生工具和技术的持续增长。仅看容器的使用率一项，约 92% 的受访者表示他们在生产过程中使用容器，这相比 2016 年 3 月的第一次调查的 23% 增长了 300%，也是继 2018 年的 73%、2019 年的 84% 后的持续跃升。这说明，云原生时代软件开发和运维的标准基础设施已经成熟。

在企业积极进行数字化转型，全面提升效率的今天，IT 大厂们都不约而同的将云原生视为发展方向。腾讯、阿里、华为等国内厂商，争先恐后抢占云原生基础设施建设和应用开发管理两大市场，并在今年下半年陆续推行云原生战略：

• 9 月，阿里巴巴成立云原生技术委员会，推动阿里经济体全面云原生化；
• 12 月初，华为发布云原生 2.0 全景图，并预测，到 2025 年，所有企业信息技术解决方案都会被云化，85% 以上企业应用会被部署到云上；
• 12 月 20 日，腾讯发布了云原生路线图，从开发、计算、架构、数据、安全的维度重新定位了云原生。值得关注的是，这份落地路线图，首次梳理了腾讯与企业共同落地的典型案例，从实践角度诠释了云原生改造的全过程。

与此同时，企业的云化动作也在加速，大部分传统业务云迁移已经完成。如果说，云迁移解决了传统应用软件在云环境中的使用问题，也就是“能用”的问题；那么，原生化改造要解决的就是“好用”的问题。毫不夸张的说，云原生化可能会成为大部分企业新的分水岭。

云原生的改造路线：分步、标准化

大量企业云原生化改造的过程并非一蹴而就，往往会选择一种稳妥的方式逐步迭代进行，尤其是传统企业，系统规模大、关联关系复杂、网络架构复杂、技术架构传统。业务部门要求系统可伸缩、支撑数据的快速增长，又不额外增加成本。技术部门考虑破除商业产品的锁定的方案、拥抱开源，还希望上云后的服务质量不比商业产品差。

一般的做法是，先拿一些简单的模块试水，摸清路数后再逐步进入深水区，完成企业整体云原生技术改造。那么问题来了，企业在云原生改造过程中，一般会经历哪些阶段？每个阶段的侧重点是什么？会用到哪些技术或产品？改造后的衡量标准怎么定？

腾讯把云原生改造分为 4 个阶段，分别是：开发云原生、计算云原生、架构云原生、数据云原生，在这个过程中，安全云原生为整个改造过程以及之后的系统运营提供数据安全及稳定性保障。

（腾讯云原生路线图）

第一阶段：开发云原生

这一阶段的重点是解决“企业研发运维流程效率”问题。在传统的开发模式中，研发人员需要了解和学习不同 API 的具体使用方式和含义，开发完成还需要负责编译、打包并申请资源，过程复杂且耗时良久。运维技术支持不足、流程不完善、缺少监管手段等，也让运维过程缓慢低效。

以腾讯自身的云原生实践为例，最先切入的点就是软件研发运维流程。之前来自技术团队各方面经常会听到一些抱怨，开发人员说环境太少，构建发布流程太慢；测试人员抱怨太多非标准版本或者发布，版本质量不可控；运维人员埋怨发布不可控，疲于救火...... 正是因为大家在这里都很痛，并且涉及到大部分团队成员，就很容易快速推进。

这个阶段完成的好与坏，有两个关键的衡量标准：

• 第一，企业的组织架构、研发运维流程是否符合 DevOps 理念，是否能够支持企业对应用进行快速的迭代、测试、发布、试错和优化；
• 第二，是否能建设和使用软件流程中的工具平台，提升团队协作效率，同时根据流程规范搭建一个自动化的“构建 - 测试 - 灰度发布”平台，减少因为“人”的因素导致的低效或者失误。

举个栗子

微信读书小程序，继承了微信读书 APP 最核心的阅读功能，同时也是七对外分享与运营的最重要渠道，在上线 10 个月之内，日均 PV 过千万。而这离不开“小程序云开发”为微信读书研发团队带来的效能提升，上线 10 个月，微信读书小程序累计发布了 349 次版本，开发效率分别是 APP 和 H5 的 4 倍与 2 倍。

微信读书小程序上线之初，由于原先使用的 Node 框架上线流程繁琐、面对突发流量运维响应慢以及开发人力不足等原因，开发效率极低。

通过“小程序云开发”，他们开始逐步使用云开发替代原有的 Node 服务，从小程序端获取的数据通过云函数、云存储等功能传输到 Server 后台，并生成业务发展数据的报表，相当于一套从后台到前端的完整服务。

小程序·云开发，让前端代码和服务端代码共存在一个项目中，统一的技术栈、统一的 IDE 环境，可以调试开发更高效，还支持动态扩容，这使得微信读书小程序研发团队效率大大提升。

不仅如此，相应的，技术团队也因为“小程序云开发”的前后端统一，也重新调整了分工。以前其团队按照前端开发、Node 开发和运维人员进行分工，现在前端负责全栈开发，团队的关注点更多集中在服务性能、稳定性、资源利用率方面。

（微信读书开发团队的变化）

第二阶段：计算云原生

这个阶段有两个关键词：“容器化”、 “Serverless 化”。改造目标是降低对 IaaS 层的异构和差异、资源的部署和调度 (包括计算资源、网络资源、存储资源) 的关注。

这个阶段涉及的业务模块大多与“数据”相关度低，比如无状态类服务 (Web 网站、接入 层服务、逻辑层服务等)，消息触发类服务 (转码、定时任务等)。所以往往改造成本较低，灰度验证也容易，一旦出现问题也能够快速恢复。改造成本和风险较低，也最适合在云原生改造初始阶段切入的地方。

这个阶段同样有 3 个关键的衡量标准，在改造完成后，我们的业务模块能否具备：

• 第一，极致的调度能力包括：自动伸缩、跨界点、跨集群、跨机房的调度等；
• 第二，全面的故障容灾能力包括：业务、节点、机房的容灾；
• 第三，极简的运维模式，需要屏蔽 IaaS 差异和具备 Serverless 计算能力。

举个栗子

作业帮历时 3 个月，通过容器化改造并向腾讯云容器服务 TKE 迁移，让整体成本下降 43%，接口响应提升 10%，稳定性从 99.95% 提升到 99.995%，发布效率提升两个数量级，平稳支撑了疫情期间业务爆发式增长。

作业帮的业务，大规模使用 Kubernetes 原生的负载均衡和服务发现，而 Kubernetes 在分散的流量调度架构上天然存在瓶颈，容易导致业务负载严重不均衡。另外，作业帮的业务对服务间时延敏感，部分业务连接超时时间设置为 5 毫秒，无法承受细微系统调度和网络波动，容易引起业务大面积超时。服务间访问会带来巨大的 DNS 并发，极易触发主机的 QOS 限速和引起主机的 conntrack 冲突……

此外，改造过程中排查并解决的典型问题有：

1. 解决 IPVS 模式高并发场景下连接复用引发连接异常 (对应 issue https://github.com/kubernetes/kuber- netes/issues/81775)，内核补丁已被 Linux 社区接受；
2. 在高配节点 (核数多) 下 IPVS 规则过多引发网络毛刺问题；
3. 大 Pod(占用核数多，单核占用高) 在高配节点 (核数多) 场景下，CPU 负载均衡引发网络毛刺的 问题等。

作业帮将在线业务、大数据离线任务、GPU 业务都进行了容器化改造，改造方案如下：

（作业帮云原生改造解决方案架构图）

1. 在线业务方面，作业帮开发语言众多，通过 Service Mesh 实现多语言的服务治理与服务感知；
2. 为提升 GPU 资源率用率与隔离性，作业帮采用共享 GPU 模式，并在业务层通过限制入口流量的方式做了不同 Pod GPU 使用量的隔离；
3. 由于在线业务和 GPU 业务的特性，CPU 利用率波峰波谷明显，作业帮采用大数据容器化及在离线混合部署方案提升节点资源使用率；
4. 通过 EMR on TKE 方案，在不改变原有 yarn 集群使用模式的前提下，渐进式的将大数据任务调度到 TKE 在线集群，并通过 TLinux 提供的 CPU 离线调度器，实现离线任务对在线任务的避让，从而在保障在线任务不受影响的前提下，离线任务充分利用 CPU 资源；
5. 利用 EMR on EKS 方案，将紧急的大数据任务或者临时的计算任务运行在 EKS 弹性集群里，避免了复杂的资 源规划及储备工作。

第三阶段：架构云原生

这个阶段会深入到复杂的软件架构层面，伴随着微服务化和架构改造，因此难度较大，但收益也会更大。

在改造过程中，一些成熟的框架服务的使用，能让改造事半功倍。例如微服务平台 TSF、服务网格、云开发 TCB 等，它们集成了很多运维能力，包括日志、监控、服务注册和发现、故障容灾等。除了提高研发效率外，也能提升改造后系统的整体运维能力。

在这个阶段其实也有两个关键的衡量标准：

• 第一，整个架构的微服务化改造是否拆分到位，流量是否可以调度、可以治理、可以观测；
• 第二，企业的研发和运维模式是否极简，企业能否聚焦在业务逻辑本身的开发和运维上。

举个栗子

南网云平台由南网数研院牵头，腾讯云负责承建，2019 年 12 月 31 日就已正式上线。今年 2 月 12 日，南网云平台进行了首次电费结算业务, 该系统共发行 2000 多万用户电费数据，省网通道同步 1.2 亿条数据。2 月 16 日当天，日访问量超过 100 多万人。

而在此前，南网用了 45 天就完成了总部基地主节点的扩容和 9 个分子公司云平台的上线，平均响应时间 0.52s，保障了亿级互联网客户平台、电力市场交易系统等 376 个重要系统和 519 个微服务的安全稳定运行，实现主节点 58 个存量云应用迁移，分节点 6 个异构云纳管。

电网是关系国计民生的基础性行业，安全运行要求高，业务复杂度高，应用呈现多样化，IT 基础设施的复杂程度也远超传统企业客户。这对南网云平台的安全性、可靠性、灵活性和可控运行提出了更高的要求：

1. 需要支持南网的基础设施标准化，以多样化的应用架构，全面支撑南网金融业务、综合能源业务等企业级应用的快速生成；
2. 需要具备灵活性和扩展性，方便统一规划管理和统一技术标准，提升系统集成效果，减少运维难度和工作量；
3. 需要具备弹性伸缩、资源快速交付、开发测试敏捷、应用快速部署、故障资源和 IT 资源标准化等能力，包括一级部署多级管理的主分节点、两地三中心、开发环境、测试环境，节点总数达到 4000 个；
4. 灾备采用平台连续性和应用连续性保护机制，根据南网业务系统需求，结合国家标准《信息安全技术信息系统灾难恢复规范》，灾备等级分为 2、3、4 和 5 级。采用两地三中心灾备建设模式，同城双活，异地容灾。

改造的具体方案是：

1. 对南网现有的多个业务系统的共用能力进行分析和整合，实现系统解耦；
2. 搭建微服务架构，逐步积累南网云的中台能力。
3. 围绕南网调度运行、电网管理、运营管控和客户服务等业务，根据微服务治理平台的监控服务负载情况、CPU 使用率、内存使用率、响应时间、请求 QPS，自动增减服务节点；
4. 结合日志与监控数据，当出现风险时，通过日志和监控快速定位问题，监测可能发生的意外和故障，提前预警和告警；
5. 通过自动化工具实现南网云的微服务研发和运维流水线；
6. 数据中心采用双 region 设计，所有云平台均同时部署分布式存储与集中式存储。其中，集中式存储组成同城同步复制、异地复制的集群。业务侧使用 TSF 微服务平台就近路由和跨可用区实现容灾，业务同时部署在两个可用区。开启就近路由后服务消费者会将请求流量路由到相同的可用区；当同一可用区不可用时，自动进行跨可用区的服务调用实现服务容灾。

第四阶段：数据云原生

在这个阶段，企业的云原生改造已经进入到深水区，目标是将 Kubernetes、Serverless 的技术和理念应用到“数据服务”中，让“数据服务”也具备极致的弹性伸缩能力，在资源成本上能够做到最优。

这个阶段有三个关键的衡量标准：

• 第一，数据服务的计算与存储是否分离，存储是否可以支持不同存储介质；
• 第二，数据服务的算力资源是否能够真正做到按需分配，按量计费，并且在需要的时候自动且快速自动扩充；
• 第三，数据算力与在线业务能否做到混部，最大限度的提升资源利用率，降低我们企业的成本。

举个栗子

疫情防控期间，健康码成为全球疫情下中国科技抗疫“智慧防线”的重要一环。健康码落地 20 个省级行政区，覆盖 300 多个市县，承载访问量累计达 260 亿次，覆盖人口超 10 亿，成为全国服务用户最多的“健康码”。

健康码涉及的应用场景繁多，数据类型方面需要支持如通行时间、车辆信息等结构化信息查询，也有如街道 / 社区 / 小区名这样的长文本信息。另外，伴随着疫情防控的需要的调整，还需具备快速调整增删字段的功能；在查询方面，不仅需要支持传统的结构化信息的查询，还需要支持关键字的搜索技术、海量数据的聚合分析技术以及地理位置区域计算技术。

传统的关系数据库 MySQL，在事务型应用及多业务多表关联查询方面有着出色的表现，但是面对健康码系统复杂繁多的数据类型，特别是文本关键字搜索能力时显得捉襟见肘。对于比较热门的 NoSQL 类产品 MongoDB，虽然能满足多样化的数据类型的支持，且可以根据业务的需要随时动态的增加字段且不影响业务正常的查询写入，但是同样缺少文本关键字的检索能力。

而在海量数据的存储方面，虽然相当多的大数据产品，如 hive 数仓、Hbase 等，拥有海量的数据存储能力，且具备一定的数据分析能力，但整个技术栈及架构比较重，需要维护的开源组件繁多，通常需要一支专门的运维团队进行集群的日常维护。对于开发人员来说，开发方法及接口也较为复杂。

因此，该项目数据库采用了 Elasticsearch（以下简称 ES）。具体的项目方案如下：

（健康码解决方案架构图）

随着疫情防控在全国范围内的铺开，接入健康码的省市自治区快速的增加，截止目前已扫码次数达 16 亿次，覆盖 9 亿用户。如何应对业务急速的数据查询增长？

1. 需要支撑 10 亿级别的数据访问和查询数据的急速增长。索引数据通过分区算法分割为多个数据分片  (shard)，平均分布在集群的多个节点上。通过节点和数据分片的能力，可以线性的扩展索引数据写入查询的吞吐。
2. 需要存储系统 7*24 小时不间断提供服务。腾讯云 ES 集群在多个可用区机房中平均部署节点，如果设置的副本数和可用区数目一致，当有一个节点乃至一个可用区机房不可用，剩余节点中的分片仍是一份完整的数据，且主从分片可以自动切换，集群仍然可以持续的对外提供写入查询服务。
3. 为防止因不严谨的聚合分析语句导致节点发生 OOM 问题造成的集群雪崩。腾讯云 ES 在存储内核上开发了基于实际内存的熔断限流机制。当集群发现部分节点的 JVM 使用率超过设定的熔断阀值，即会进行服务降级，梯度拦截部分查询请求，直至 JVM 使用率超过 95% 导致最终熔断，阻止所有查询请求。这一熔断请求拦截机制会覆盖 Rest 层及 Transport 层，通过将熔断提前至 Rest 层，可以尽早拦截请求，降低集群在熔断状态下的查询压力。
4. 在数据备份方面，通过 ES 索引生命周期管理功能，定时增量的备份底层数据文件到腾讯云对象存储 COS。需要时即可随时将数据备份恢复至任意集群，做到数据的万无一失。

无所不在：安全云原生

企业在进行云原生化建设的同时，安全能力应贯穿云原生的整个生命周期，这称之为“安全云原生”。

在开发阶段，提供集成的代码级安全及合规检测能力，提前发现风险隐患，或通过向开发者提供安全 SDK，使产品具备内生安全能力。处于发布阶段的制品 (例如容器镜像) 需要持续地进行自动扫描和更新， 从而避免遭受漏洞、恶意软件、危险代码以及其它不当行为的侵害。完成这些检查之后，应该对制品进行签名来保障其完整性和不可否认性。

在部署阶段，集成的安全性能够对工作负载的属性进行实时的持续验证 (例如完 整性签名、容器镜像和运行时的安全策略等)。在上线运行阶段，能够提供对应用、服务和工作负载的运行时 防护、并通过态势感知能力和云平台的灵活、弹性机制，对网络安全事件进行实时自动化响应并进行协同处置，帮助客户实现高效的安全防护及合规。

安全云原生部署达标参考标准:

• 第一，代码安全漏洞和开源合规检测；
• 第二，自动化镜像加固及扫描 ; 镜像签名及安全 策略的实时校验；
• 第三，应用、服务、工作负载的动态可弹性扩展运行时防护；
• 第四，安全事件的自动化响应。

写在最后

现代企业的 IT 规划要面对两个紧迫事实，一是当前的客户需求、行业竞争状态已和 20 年前、10 年前全然不同，企业业务的更新速度很多已经从以周为单位提升到按小时计；二是云原生是新生事物，企业技术人员从零学习、到消化吸收、再到创新都需要人力成本和技术试错成本。

当面临着行业竞争紧迫、技术试错成本和人才培养成本的三大压力，找到一个合适的参照，以此为基础迭代自己的业务解决方案和产品技术架构，是当前很多企业所需要的操作。

目前，腾讯针对云原生的产品就有 30 多个，服务着几十万家企业。这篇文章里的所有案例，来自腾讯云原生服务的真实场景。后续也希望能看到越来越多的落地案例，为有云原生改造需求的企业，提供参考。