由浅入深纵观腾讯文档的云原生实践之路

微信邦

导语｜云原生重塑了研发流水线，重新定义了软件交付方式并对运维模式进行了升级。通过对底层资源的深度整合，全面帮助企业降低了从开发、测试、交付到运维的技术复杂度。本文带你由浅入深了解腾讯文档的上云历程。读完本文，你将对云原生的发展历程和架构价值有更清楚认知，本文作者宋扬也将剖解腾讯文档的上云历程和经验感悟。期望对你有帮助。

目录

1 云原生的发展历程

   1.1 云原生的基本概念

   1.2 云原生与云计算

2 腾讯文档的云原生实践

    2.1 腾讯文档上云背景

    2.2 启动/更新/回滚优化

2.3 使用云原生中间件

    2.4 环境治理和重塑研发流水线

    2.5 重新定义软件交付模式

    2.6 工具链和平台的建设

    2.7 运维模式的升级

    2.8 组织结构的升级

3 云原生架构的价值

    3.1  云原生架构的定义

    3.2 云原生架构的价值

4 总结与展望

    4.1 腾讯文档云原生方法总结

    4.2 云原生未来发展思考   

    4.3 常见问题解答

云原生发展历程云原生可分解为“云”（Cloud）和“原生”（Native）两个词。这里还隐藏了一个词——“计算”（Computing），因为云原生本质上是一种与云计算（Cloud Computing）相同的计算方式，因此通常在说云原生的时候，实际上是暗指云原生计算（Cloud Native Computing）。本章讲述云原生的发展历程和定义，如果您对云原生基本概念有了解，可直接跳过本章继续阅读～
1.1 云原生的基本概念既然说到了云原生（计算），那么哪些计算方式不是云原生（计算）呢？要回答这个问题，同时辨析云原生的概念，需要先回顾云计算的发展历史，以及与之密切相关的分布式计算的复杂性问题。
云计算的概念最先由戴尔公司于1996年提出。2006年，亚马逊公司率先推出了弹性计算云（Elastic Compute Cloud，EC2）服务，随后越来越多的企业开始逐步接受云计算这一概念，并将应用逐步迁移到云端，享受这一新型计算方式带来的技术红利。
纵观软件架构的演化历史可以发现，任何新的底层软硬件技术出现后，上层应用软件都需要很长一段时间才能够真正认识到新的软硬件给上层应用软件带来的价值，并开发新的软件架构，以便充分利用新软硬件的能力。最典型的例子就是x86 CPU和服务器在面世二十多年后，以CORBA、EJB、RPC、瘦客户端等为主的多层架构才逐步成为 应用开发的主流架构。类似的还有容器技术，它最早是由FreeBSD于 2000年在Jails中提出的，但真正得到大规模应用是在2013年Docker兴起之后，而应用层的代表则是几年之后基于容器的微服务架构。
对于云计算这一新基础设施来说，也是如此。在2015年之前，对于大多数应用来说，云端只是一个用于计算的场所，开发人员所要做的就是将原来在私有数据中心或IDC中的应用，迁移到云端。在迁移的过程中，应用无须重新编写，只需要重新部署，因为云平台提供的计算、存储、网络等，完全兼容应用迁移之前的计算环境。在迁移模式中，应用通常会将原来的物理机部署模式改成虚拟机（规格更小）部署模式；存储则选用兼容的块存储或者文件存储；网络使用 SLB（Server Load Balancer，服务器负载均衡）替换传统的负载均衡器，构建VPC（Virtual Private Cloud，虚拟私有云）或NAT（Network Address Translation，网络地址转换）网络环境；使用云数据库替换原来的MySQL或SQL Server，或者自行在云上搭建 Oracle数据库。迁移之后，应用的整体成本（Total Cost of Ownership，TCO）因为采用了按量付费的模式而大幅下降，同时，企业的IT支出从CapEx（Capital Expenditure，资本性支出）模式转变为OpEx（Operating Expense，管理支出）模式，整个IT支出变得更可控。
如果对迁移过程进行技术分析，就会发现大部分应用使用的技术或者产品都在进行一对一的替换，只有极少量应用会基于OSS（对象存储服务）、MaxCompute（大数据计算服务）等云服务进行部分重构。OSS能够帮助解决分布式状态的存储问题，而MaxCompute能够解决数据仓库的快速搭建和成本问题。但由于没有或者只进行了少量重构，因此应用的技术栈本身几乎没有发生变化，也就是说，软件的架构没有发生变化，只是软件运行的平台和运维的技术体系发生了变化，即只有平台层面的变化。而软件在分布式场景下需要解决的问题，包括稳定性、组件或服务之间的数据同步、整体的高可用或容灾、CI/CD过程的自动化、资源利用率不高、端到端链路跟踪等，仍然需要应用自行解决。这些问题并不会因为应用迁移到了云平台就从根本上得到了解决。当然，各云平台为了帮助应用解决上述分布式复杂性问题，不断推出各类云服务，但是由于应用架构本身并没有发生变化，因此这些云服务并不能帮助应用解决整体问题，只能从局部提升应用的效率。
面对大量的业务需求和场景迭代，很多云平台都提供非常专业的垂直领域服务，这些服务比企业基于开源自行搭建的系统具备更高的SLA（Service Level Agreement，服务等级协议）。比如，在数据持久性方面，亚马逊AWS的数据持久性可以达到99.9…%（11个9）；在跨可用区的高可用方面，腾讯云的高可用达到了99.95%，即使整个机房不可用也能继续对外提供消息服务。如果不是应用的所有存储访问代码都在S3或OSS上重构，那么木桶效应就会凸显，即整个系统的数据持久性将取决于能力最差的组件；如果应用不是将所有自持的开源组件都迁移到云平台上，那么当一个机房出现故障时，应用仍然会出现高可用性的问题；如果应用不是基于FaaS（Function as a Service，功能即服务）技术开发的，那么应用仍然需要自行解决单个组件不可用时的Fail Over（失效转移）以及故障恢复时的Fail Back（失效后自动恢复）等问题。
可见，应用迁移到云上并不代表从此以后就高枕无忧了，如果应用本身没有基于新的云服务进行重构，而是继续采用老的架构，那么即使业务运行没有问题，应用也不能充分利用新的云运行环境的能力。因为这些架构是为了老的分布式运行环境而设计的，不是云原生的，所以需要对这些架构以及围绕这些架构建立的技术栈、工具链、交付体系进行升级，依托于云技术栈将其重新部署、部分重构甚至全部重写，才能将应用变成云原生的，从而保证能够充分利用云计算的能力。
为了让应用能够更好地使用云的PaaS平台能力开发SaaS（Software as a Service，软件即服务），Heroku于2011年提出了十二因子应用的概念。十二因子应用适用于任何编程语言，通常被认为是最早的云原生应用的技术特。
之后，Pivotal于2015年明确地提出了云原生的概念，指出云原生是一种可以充分利用云计算优势构建和运行应用的方式。
在经过CNCF的修改后，最新版云原生的定义为：云原生技术有利于各组织在公有云、私有云和混合云等新型动态环境中构建和运行可弹性扩展的应用。云原生的代表技术包括容器、服务网格、微服务、不可变基础设施和声明式API。这些技术能够构建容错性好、易于管理和便于观察的松耦合系统。结合可靠的自动化手段，云原生技术使工程师能够轻松地对系统做出频繁和可预测的重大变更。       上面三个主流的定义，分别从顶层架构原则、计算模型和代表技术的角度，对云原生进行了描述。这些定义的共同点是它们都将云原生看作一种新的计算方式，让应用能够充分使用云的计算优势。进一步分析这些定义所体现出的技术观点，可以达成这样一个共识：只有结合云原生所提供的云服务，改造应用的架构，才能够更好地使用云原生技术，更好地构建弹性、稳定、松耦合的分布式应用，并解决分布式复杂性问题。此外，对架构的改造还意味着相关的开发模式、交付方式、运维方式等都要随之改变，比如，采用微服务架构重写应用，用声明式API和自动化工具升级运维方式，等等。简单来说，云原生使得整个软件的生产流水线都发生了巨大的变化，而具体的变化程度又取决于企业对云原生的使用情况。       实际上，云原生的范围还不止于此。要正确实施云原生这一新计算模式，还需要企业的IT决策者、架构师、开发人员与运维人员正确理解和应用云原生的理念，利用合适的云原生技术及产品。有太多的反例可以证明，仅靠单边的技术升级是很难让云原生升级产生价值的。云原生相关概念之间的关系如图所示。

现代化应用在不少场合与云原生应用的概念是等同的，因为它们的很多特征都是相似的，比如，都采用了容器技术打包和交付，都具备很强的弹性能力等。这两个概念的细微差别在于：现代化应用可以与云相关，也可以与云不相关；而云原生应用通常都与云相关。     所以云原生（或者说云原生计算）应当包括云原生技术、云原生产品、云原生架构以及构建现代化应用的开发理念，如DevOps，具体说明如下：第一，云原生产品和云原生技术需要基于公有云、私有云或混合云的云基础设施（IaaS）。第二，云原生架构和云原生开发理念是基于云原生技术和产品构建或实现的。注意，对于不是基于云原生技术或者产品的架构和理念，如基于传统物理服务器发布、构建的DevOps，是不会被划分到云原生范畴的。第三，现代化应用和云原生应用是基于云原生的架构和开发理念构建或实现的。

1.2 云原生与云计算
从技术发展趋势看：更多企业将会广泛应用云原生技术。在国家政策和企业需求的双重驱动下，更多企业会选择上云，中国云计算的强势增长是必然趋势，这也注定了更多企业将会关注、应用、采纳能够充分利用云计算能力的云原生技术和产品。
从软件开发角度看：云原生技术为企业带来了更快进行业务创新的价值。越来越多的企业逐渐意识到了云服务的专业性和高SLA，这些企业在数字化转型的过程中将IaaS和PaaS的通用技术复杂性委托给了云平台，从而能够更好地专注于自身业务逻辑的创新。利用云原生技术重塑企业的软件生产流水线，可以加大业务组件的复用程度，将软件交付周期从周、天降低到小时甚至分钟级别，从而提升业务的市场嗅觉灵敏度，增强市场反应能力。
从应用技术栈角度看：越来越多的企业发现传统的应用已经无法满足数字化业务的需要，所以会对应用进行彻底升级，会更多地采用云原生技术和云原生架构作为构建现代化应用的核心框架，从而帮助企业打造具备弹性、韧性、可观测性、API驱动、多语言支持、高度自动化、可持续交付等特性的现代化应用软件。
通过以下3个图，各位可以快速看到云原生及其架构成熟度。

从云原生的定位可以看到，云原生包含大量新的PaaS层技术和新的开发理念，是释放云计算价值的最短路径，也推动着云计算的再升级。
整个云原生技术栈都是基于开源、开放的技术标准。CNCF也在致力于云原生技术的标准化，为云原生技术和产品的用户提供使用云服务的标准界面，同时避免了厂商锁定。       进一步看基于云原生技术和云原生架构重构或重写的应用，比如，基于服务网格或无服务器技术（Serverless）的应用，它们天然具备水平扩展的能力，可随时应对互联网时代高速增长的业务规模，同时还内置了高可用能力，所以应用无须关注分布式环境下的高可用方案。       对于云平台而言，云原生技术也催生了诸如腾讯云TKE、AWS Nitro系统之类的架构升级，使得新的计算基础设施能够为应用提供更高的性能、弹性和计算密度；云存储能够帮助企业实现存储计算分离，避免分布式环境下多副本存储，同时还具备自定义密钥加密落盘的高级安全特性；基于硬件offload（卸载，通过硬件提供加速功能）的网络在overlay（一种在现有网络架构上叠加的虚拟化技术）的场景下为应用提供千万级PPS（Packet Per Second，数据包/秒，宽带速率）的SDN（Software Defined Network，软件定义网络）能力。       所以，云原生不仅是对使用云的应用架构的再升级，也是对云平台的技术和云服务的再升级。从构建现代化应用的角度，腾讯文档团队可以发现，云原生对应用的重构体现在应用开发的整个生命周期中。

腾讯文档的云原生实践
2.1 腾讯文档的上云背景从2021年1月开始到8月结束，腾讯文档开始对所有服务按照云原生的规范进行重构、docker化，并逐步将部署在云下的服务迁移部署到STKE上，利用云原生基础设施为应用提供更高的性能、弹性和计算密度。
服务上云里程碑如下：



腾讯文档微服务上云接入情况：文档前端22个服务接入，已完成前端统一；文档后端120个服务接入，已全部完成统一。
多集群部署策略：同服务同区域多集群部署，异地集群部署

服务Docker化

STKE


2.2 Workload配置优化以及容器的启动/更新/回滚优化
首先，使用mini镜像优化镜像大小缩短构建和拉取时间，并优化了服务在运行中内存使用率：在容量方面mini镜像容量缩小60%左右，构建镜像和推送时间减少33%～50%，在服务部署中，如果没有缓存的情况下拉取镜像的时间缩短了66%，有基础镜像缓存的情况下减少了2～18s。workload构建的时间缩短到两分钟左右。优化报告详见下方地址：https://doc.weixin.qq.com/doc/w3_ABYA0QbtACgbQaMjUo1RD2WSXTNwp?scode=AJEAIQdfAAo51cd2D1ABYA0QbtACg
其次，通过埋点方式逐一优化Atta耗时，将restart.sh改成start.sh脚本实现容器启动耗时优化，实现服务能够快速启动时间。优化报告详见下方地址：https://doc.weixin.qq.com/doc/w3_AM0AqgZGACguCHXt0bjQYG2jwK0N4?scode=AJEAIQdfAAouXLl4vJAM0AqgZGACg
此外，通过动态设置容器preStop时间优化耗时：使用脚本依照不同服务的特性动态设置preStop时间，替换掉原来固定preStop时间的方式，避免人为预估的不准确性，也避免了容器在流量处理完之后依然等待到最大超时时间。优化报告详见下方地址：https://doc.weixin.qq.com/doc/w3_AM0AqgZGACg161qxjkRTnKkb7Q0sf?scode=AJEAIQdfAAo0MtknzFAM0AqgZGACg
在优化了镜像大小、容器创建完成到服务启动时间、preStop时间之后，容器启动优化结果如下：
更新/回滚镜像：由原来的单pod 3分钟优化到如下结果STSP: eks 46-56stke: 56-70sDeployment: EKS/TKE 90s 左右
pod重建: 由原来的单pod 5分钟优化到如下结果STSP（EKS/TKE）90s左右Deployment：90s左右
2.3 使用云原生中间件从2021年3月开始，腾讯文档逐步将中间件替换成云原生或腾讯云推荐使用的云原生中间件，目前购买的是腾讯云TDSQL、Redis、ES、Mongodb、Kafka。下面以TDSQL为例：

2.4 环境治理和重塑研发流水线
具备持续发布的能力，是众多软件企业的目标之一，但持续发布需要面临诸多挑战，例如配置基线、版本管理和自动化等。特别是当应用具有多个不同的硬件环境、OS或者第三方软件/库依赖的多个组合时，如何进行有效的变更管理才能保证任何微小的变化都不会使这些组合出现错误呢？腾讯文档团队经常遇到的问题之一就是，开发人员在本地环境中运行和测试时都是正常的，但是一旦部署到测试或者生产环境中，就会因为依赖的第三方软件或库的配置问题，导致软件不能正常工作。
容器可用于对制品进行打包和分发，即结合GitOps和不可变基础设施，可以实现软件运行环境的整体化部署。换句话说，对运行环境的任何变更，都必须提交到Git中，经过版本管理后重新持续集成，形成新版本的制品并进行部署。这样做的好处是，关于软件运行环境的所有变更都有迹可循。任何时候都可以查找（checkout）需要的版本，通过脚本构建出对应的制品。如果代码和脚本本身没有错误，那么整个构建过程就会非常顺利，并且是可重复的。如果某次变更后软件运行出现异常，可直接根据Git上的记录回溯到上一次正常运行的版本，重新进行部署。
整个过程不仅高度自动化，而且具备版本跟踪和回溯机制，也解决了上文提到的持续发布的挑战问题，减少了CI/CD中的错误发生概率，从而提升了整体的质量和效率。这样的研发流水线，虽然不一定具备7×24的发布能力，但也可以在软件实现新的功能后马上基于某个基线连续自动发布或者回滚。
GitOps的整体规划如下：

腾讯文档环境治理示意图如下：

首先，利用OCI完成CI pipeline。示意图如下：

其次，利用TF完成CD pipeline。示意图如下：

2.5 重新定义软件交付模式云原生软件交付模式主要有如下几个变化：第一，利用容器做整体交付。整体交付减少了容器内部组件之间的安装配置工作，随着容器及编排的开源和普及，更多硬件得到支持，使得容器成为软件交付的标准底座。这种标准底座加整体交付的方式，极大地降低了安装配置的错误风险。此外，还可以通过工具（如Terraform）和脚本自动完成软件交付，提升交付的效率。这就像购买组装家具一样，顾客更期望得到的服务是厂家到家里将家具组装好，以免自己在组装时出现错误。
第二，将Git作为Single Version of Truth（唯一真实版本）。Git作为交付和运维的仓库，记录了所有软件变更的版本、配置参数、脚本、用户名和密码等信息，同时所有脚本、工具和Kubernetes的Operator，都读取Git中的信息作为事实的唯一来源，即使是做版本升级或回滚，以及变更评审，都以Git中的信息为准。

第三，声明式API。很多软件交付都是告诉系统需要做什么，特别是脚本中往往会写明如何进行部署；而声明式API首先是告诉系统期望的目标状态是什么，比如，在这种环境下部署需要用到两个实例，其次才是脚本或工具需要做什么才能交付这个目标状态（即如何做）。声明式API本身并不复杂，实际上它是一种开发理念的彻底升级，因为系统更多的是关注需要什么（达到什么状态），所有的措施逻辑都是围绕这个目标状态来服务的。
第四，尽量采用OpenAPI作为系统间的集成方式。标准化的OpenAPI更有利于系统间的集成，因为OpenAPI有明确的契约描述或接口规格描述，且提供了各种开放的工具，可以用来做IoT（连通性测试）SIT（集成测试）等。同时，由于其开放接口（比如，基于RESTful）的特性，可以实现快速集成，从而提升集成的效率。
新CI后台流程图：

新CD后台流程图：

整个CICD的方案流程图：

新CICD的效果：前端流量最大的表格服务为例，11月完成接入，已支持常规发布+紧急发布29次，已支持分支灰度发布19次，最近的一次hotfix从确认到可发布到完成25min。
2.6 工具链和平台的建设
中间件云监控如下：

资源配额机器人如下：

Workload和POD实时监控大盘如下：

配套的dashboard，发布工程师和oncall工程师通过发布视图进行服务版本，发布行为的追踪。