由浅入深纵观腾讯文档的云原生实践之路
导语｜云原生重塑了研发流水线，重新定义了软件交付方式并对运维模式进行了升级。通过对底层资源的深度整合，全面帮助企业降低了从开发、测试、交付到运维的技术复杂度。本文带你由浅入深了解腾讯文档的上云历程。读完本文，你将对云原生的发展历程和架构价值有更清楚认知，本文作者宋扬也将剖解腾讯文档的上云历程和经验感悟。期望对你有帮助。目录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工程师通过发布视图进行服务版本，发布行为的追踪。
2.7 运维模式的升级配置变更是运维场景下的高频操作。针对配置变更，云原生的理念是提倡采用不可变的基础设施，即任何变化都是基于容器重新生成一个镜像来进行部署，而不是在原有环境下直接变更配置，也就是说，基础设施是只读的。这样做的好处是任何变更都是可版本化的，因此也就更容易维持变更的质量，从而避免各种未记录的变更给系统带来不可知的影响。当然，对于大型系统而言，变更的相互影响也是非常大的，因此建议一个环境不要只用一个大的镜像，而是将大环境分成若干个小环境，从而避免出现每个小环境发生变化时需要将整个大环境全部重新做镜像和部署升级的问题。
从2021年1月开始，腾讯文档根据是否为开关配置逐步将开关配置迁移到七彩石，非开关配置收归于代码仓库(CAC)中，第一，七彩石开关配置：保证配置文件的修改必须进行code review，审核人审核；保证发布走单实例到全量的灰度发布。第二，非开关配置：Configuration as Code，保证配置文件的修改必须进行code review；保证从低环境到高环境的灰度发布。
2.8 组织结构的升级
云原生的升级还会涉及IT文化的升级以及IT组织结构的升级。一个企业中的IT文化，实际上是开发、运维等IT人共同认可和遵守的工作流程、知识体系、工具集的总和。云原生作为一种全新的计算模式，带来了工具集的升级、知识体系的更新和工作流程的改变，也变更了企业的IT文化，从瀑布模型到DevOps不适应，产生新的技术债务，甚至部分岗位会被淘汰（如大机运维人员）和产生新的岗位（如SRE，Site Reliability Engineer，网站可靠性工程师），等等。这些变化都可能会对企业的IT部门产生巨大的影响。
腾讯文档从2021年成立架构和工具链组，其工作职责不仅包含了SRE的方方面面，还肩负着腾讯文档服务云原生建设，Devops建设(CICDCOCTCE)，高可用建设，基本架构建设以及效能方面的协助工作的重任, 2022年的目标：文档C端SLA 99.95%,B端99.99%，MTTR 2小时内。
云原生架构的价值3.1 云原生架构的定义云原生架构的目标更简单，主要是帮助企业改善软件的架构，使其能够快速、有效地享用云计算提供的各种服务，提升软件的交付效率，降低软件的整体成本，提高软件的交付质量。在这个框架下，很多基础的软硬件环境等都由云厂商提供，且它们提供的云服务往往都包含业界最佳实践的产品及解决方案。云厂商所具备的大量行业属性的文档也可以作为模板供企业参考，以便企业能够更好地梳理相关流程，实施这些云服务。 云原生架构是基于云原生技术的一组架构原则和设计模式的集合，旨在帮助企业和开发人员充分利用云平台所提供的平台化能力和弹性资源能力。
对比传统架构与云原生架构，可以清楚地看到两者的区别：第一，云原生架构可以最大化地剥离云应用中的非业务代码部分，从而让云设施接管应用中原有的大量非功能特性（例如，弹性、韧性、安全、可观测性、灰度等），使业务能够摆脱被非功能性业务中断的困扰，同时具备轻量、敏捷、高度自动化等特点。第二，云原生架构可以通过与基础设施深度整合与优化，将计算、存储、网络资源管理以及相应的自动化部署和运维能力，交由云基础设施执行，应用自身会因此变得更为灵活，且具有弹性和韧性，从而大大降低管理成本。
3.2 云原生架构的价值3.2.1 降低研发成本和项目维护复杂度相较于传统架构，云原生架构强调业务研发应充分利用云平台所提供的IaaS和PaaS的通用能力。虽然云计算不能解决所有的非功能性问题，但是云平台确实能够处理大量的非功能性问题，特别是分布式环境下的复杂非功能性问题。以最具挑战性的高可用性为例，云平台在多个层面为应用提供了解决方案。
第一个方案：虚拟机层面，当虚拟机检测到底层硬件异常时，可以自动将应用热迁移，且迁移后的应用无须重新启动就具备对外服务的能力，应用对整个迁移过程甚至都不会有任何感知。
第二个方案：容器层面，有时，虽然应用所在的物理机运行正常，但应用由于自身的问题（比如，出现Bug、资源耗尽等）而无法正常对外提供服务。对于这种情况，如果采用容器，就能够通过监控探测到进程的异常状态，从而实施异常节点下线、新节点上线和生产流量切换等操作。整个过程自动完成，无须运维人员人工干预。
腾讯文档所有服务都配置云原生标准的检查机制，并完成参数优化。POD自动重建如下：POD配置自动迁移，当母机出现瓶颈，POD将完全自动化的迁移到其他低负载的母机上。https://mmbiz.qpic.cn/mmbiz_png/VY8SELNGe963blWxQqSA3pbGLCwleGUria0A2UvrXgQbG3bACwMFffl7JMvpTLPViaicAZNoHbyeEFIjBwOmrZzCA/640?wx_fmt=pngWorkload和POD的监控告警，可以7*24小时对服务的健康度进行监控，告警，并在达到一定阀值时上升到oncall。
第三个方案：云服务层面，云服务具备极强的高可用特性和7×24小时服务能力，如果应用把有状态部分（如缓存、数据库、对象存储等）全部交给云服务，加上进程内存中全局对象的持有小型化和应用快速重构能力（比如基于快照快速恢复到最新状态），那么应用本身就会变成更轻量的无状态应用，从而使可用性故障造成的业务中断时间降至分钟级；如果应用采用的是N-M对等架构模式，那么结合负载均衡产品则可获得几乎无损的高可用能力。
借助云原生架构，业务研发可以降低原本大量耦合的非业务逻辑占比，缩减业务代码开发人员的技术关注范围，并通过云平台提供的服务提升应用的稳定性和可持续发展性。
腾讯文档所有的中间件都配置云原生的监控告警能力，可以7*24小时对中间件进行监控，告警，并在达到一定阀值时上升到oncall。
3.2.2 加快软件迭代速度，降低管理和运行成本
[*]面向单机资源变为面向云服务与云API研发
云原生架构对开发人员的最大影响就是，它使编程模型发生了巨大变化。如今，大部分编程语言都包含文件、网络、线程等元素，这些元素虽然为充分利用单机资源带来了好处，但也增加了分布式编程的复杂性，因此市场上不断涌现出大量的框架和产品，意在解决分布式环境中的网络调用、高可用性、CPU争用、分布式存储等问题。而在云平台中，存储获取变成了若干个服务，比如，对象存储服务、块存储服务和文件存储服务的访问和使用等。
云原生不仅为开发人员提供了解决上述问题的技术支持，而且通过OpenAPI及开源SDK，提供了解决分布式场景中的高可用性、自动扩缩容、安全、运维升级等诸多挑战的界面。开发人员不用再关心诸如节点宕机后如何在代码中将本地保存的内容同步到远端，或者当业务峰值到来时如何对存储节点进行扩容等问题；运维人员也不用再考虑诸如在发现零安全天问题时如何紧急升级第三方存储软件等问题
[*]高度自动化的软件交付能力
腾讯文档B端CD交付能力流程图：
腾讯文档C端CD发布交付能力流程图：
腾讯文档C端发布流程：
自动化CD发布能力说明：前端流量最大的表格服务为例，11月完成接入，已支持常规发布+紧急发布29次，已支持分支灰度发布19次，最近的一次hotfix从确认到可发布到完成25min。
总结与展望4.1 腾讯文档云原生方法总结随着云原生理念和云原生技术的普及，越来越多的企业展开了基于云原生架构的实践和探索，虽然不同的行业的云原生的实践方式有所不同，但腾讯文档团队总结出一套基本方法论来供大家参考。
第一，引入云原生的PaaS和BaaS产品，利用云原生中间件和数据库产品自身携带的自动化部署，无缝升级，扩容便利，高可用部署，多地域多可用区的数据自动化同步等云原生特点，企业可以将更多的注意力放在业务领域本身上面；在数据安全方面，云上数据可以轻松异地备份，专业云厂商的数据存储体系下的归档存储产品具备高可靠、低成本、安全性、无限存储等特点，可以更好地保证企业数据的安全性。云原生PaaS平台为业务能力层和核心能力层及能力开放管理平台提供的基本技术支持具体包括：分布式服务框架、分布式消息服务、分布式数据服务、分布式监控等云原生技术服务，以及云管理能力、技术组件、云原生运维管理服务。
第二，应用容器化，伴随着容器化技术的普及和发展，应用容器化可以有效解决环境不一致产生的问题，确保应用开发、测试、生产环境的一致性。与虚拟机相比，容器化让效率与速度都得到了提升，让应用更适合微服务场景，从而有效提升产研效率。通过容器化部署，利用容器服务的快速弹性优势，实现大促时对资源快速扩容。
第三，微服务改造，将业务逻辑变成更具备复用性的微服务架构，同时将业务按业务域进行拆分，让整个系统变得更易于维护；将服务的计算和存储分离，将有状态转转变成无状态，既便于服务多实例的自动化横向扩展(HPA)；使用云原生架构搭建整个服务体系，形成高内聚，低耦合，减少服务之间的依赖关系，拒绝循环依赖。
第四，平台层改造，基于Kubernetes打造的云原生PaaS平台优势非常明显，打通DevOps闭环，可进行统一测试、集成，预发、生产环境在资源隔离方面具有天然优势，机器资源利用率高，流量接入可实现精细化管理，集成了日志、链路诊断、Metrics平台，统一了APIServer接口及扩展，可以很好地支持多云部署和混合云部署。
第五，应用服务层改造，每个应用都在Kubernetes上创建一个单独的命名空间，使得应用与应用之间实现资源隔离。规范定义了各应用的配置YAML模板，部署时可直接编辑其中的镜像版本快速升级；在本地启动历史版本的镜像可实现快速回滚。
第六，CICD的自动化编排实现服务的灰度部署和环境中的自动化判异：CI采用pipeline as Code完成；CD采用IAC的方式，做到每一个资源的可控化和每一个部署步骤的代码化控制；利用gitops完成CI和CD的版本化和环境化隔离化。
第七，可观测性的加持。有全链路监控平台，将trace，log，metrics结合在一起形成全链路的可观测性，提前接入全链路监控平台，以跟踪分布式环境下复杂的服务调用，定位出现异常的服务，帮助客户在测试和生产中快速定位问题所在并及时修复，从而降低问题对业务的影响；根据链路和服务的核心重要性，持续将链路和服务进行等级化(P0,P1,P2..)，从而根据等级对对应的链路和服务进行监控和告警的持续metrics优化和收敛，为精细化运维和oncall做好基础铺垫。
第八，高稳定性的建设：针对链路完成过载保护的改造，即在链路拥塞时对链路进行整体限流，对非核心服务进行熔断，对服务的特殊功能及性能降级，防止服务的雪崩效应；对数据库和缓存的慢日志，高频日志进行处理，防止存储层的雪崩效应；SLA方面，链路至少达到3个9以上，黄金链路尽量达到4个9以上。
第九，高可用性建设和部署，对中间件或数据库进行多地域或多可用区的集群部署，尽量做到读写分离；对整个项目的大多数服务进行同城双活或或两地三中心或多set化的异地部署，实现整个项目的高可用性。
第十，边界能力数据的全面掌控，使用专业云厂商提供性能测试服务，利用秒级流量拉起、真实地理位置流量等功能，以最真实的互联网流量进行压力测试，确保业务上线后稳定运营。采集压力测试数据，解析系统强弱依赖关系和关键瓶颈，对关键业务接口、关键第三方调用、数据库慢调用和系统整体负载进行限流保护。
第十一，容量规划，单服务的可用资源的评估和服务实例数量HPA的评估，链路可承受的性能边界的评估。
4.2 云原生未来发展思考 4.2.1 计算需求催生新一代容器随着5G、AIoT等新技术的普及，随处可见的计算需求不断涌现。不同的计算场景对容器运行时有不同的需求。Kata Container、Firecracker、gVisor、Unikernel等新的容器运行时技术层出不穷，分别解决了安全隔离性、执行效率和通用性三个不同维度的需求。OCI（Open Container Initiative，开放容器计划）标准的出现，使得不同的技术可以采用一致的方式管理容器生命周期，从而进一步促进容器引擎技术的持续创新。
4.2.2 云原生操作系统的发展
随着Kubernetes逐渐成为容器领域的事实标准以及其在不同场景的不断发展，Kubernetes已经成为云原生时代的操作系统。Kubernetes的发展历程和特性与Linux有着诸多相似之处。如图8-2所示，对比Linux与Kubernetes的概念模型可以发现，它们都是定义了开放的、标准化的访问接口，向下封装资源，向上支持应用。
Linux与Kubernetes都提供了对底层计算、存储、网络、异构计算设备的资源抽象和安全访问模型，可以根据应用需求调度和编排资源。Linux的计算调度单元是进程，调度范围限制在一台计算节点上；而Kubernetes的调度单位是Pod，调度范围是在分布式集群中，甚至可以跨越不同的云环境。 过往在Kubernetes上运行的主要是无状态的Web应用。随着技术的演进和社区发展，越来越多的有状态应用、大数据和人工智能应用负载正逐渐迁移到Kubernetes上。Flink、Spark等开源社区以及Cloudera、Databricks等商业公司都开始加大对Kubernetes 的支持力度。Kubernetes的技术价值也会在以下四个方面集中展现。
[*]统一技术栈，提升资源利用率
多种计算负载在Kubernetes集群上统一调度，可以有效提升资源的利用率。Gartner预测在未来3年，70%的AI任务会运行在容器和Serverless上。AI模型训练和大数据计算类工作负载需要Kubernetes提供更低的调度延迟、更大的并发调度吞吐率和更高的异构资源利用率。
腾讯文档一直在努力通过自动化工具来完成资源阀值的计算，以提高资源利用率和增强系统的稳定性，例如Pre-stop采用脚本动态设置容器可以关闭的时间。
STKE集群剩余配额自动统计，以便后续的自动扩缩。
[*]统一技能栈，降低人力成本
Kubernetes可以在IDC、云端、边缘等不同场景中进行统一部署和交付。云原生提倡的DevOps文化和工具集可以有效提升技术的迭代速度并降低人力成本。第一，腾讯文档所有服务已经完全上云，完成云原生化建设；第二，CD采用TF直接调用STKE提供的API自动化完成服务的部署；第三，Workload统一采用K8s原生的类型：STSP(Statefulplus,对原生Stateful类型做了封装)和Deployment。第四，所有灰度发布按照云原生标准的灰度发布方式：STSP：自动分批+批之间设置间隔时长；Deployment：自动分批滚动升级，先创建新版本的Pod,然后再删除旧版本Pod。
[*]加速数据服务云原生化
由于计算存储分离具备巨大的灵活性和成本优势，数据服务的云原生化也逐渐成为发展趋势。容器和Serverless的弹性可以简化对计算任务的容量规划，结合分布式缓存加速和调度优化，可让数据计算类任务和AI任务的计算效率得到很大提升。
[*]容器Serverless化降低运维和资源成本
Serverless和容器技术也开始融合并快速发展。Serverless化容器，一方面可以从根本上解决Kubernetes自身的复杂性问题，让用户不再受困于Kubernetes集群容量规划、安全维护、故障诊断等运维工作；另一方面还可以进一步释放云计算能力，将安全、可用性、可伸缩性等需求下沉到基础设施中实现。
从离线业务到在线业务：按请求次数计费和按启动到结束的响应时间计费之间存在天然的矛盾，这也导致了以FaaS为代表的Serverless技术最初都是从对响应时间不敏感的事件驱动类离线业务入手。加速推动基础设施和服务Serverless化：业务代码托管给Serverless平台后，即可享受自动弹性、按请求计费等功能。
实现最佳性能功耗比和性价比：虚拟机和容器是取向不同的两种虚拟化技术，前者安全性强、开销大，后者则正好相反。Serverless计算平台一方面要求最高的安全性和最小的资源开销两者兼得，另一方面还要保持对原有程序执行方式的兼容，例如，支持任意的二进制文件。
更小的镜像实现更快的分发速度：Serverless平台要求应用的镜像足够小，以实现快速分发，同时要求应用的启动时间极短。
解决FaaS状态传递的中间层研究：由于函数之间串联需要状态传递，函数处理需要与外部存储进行频繁交互，因此未来Serverless在函数场景下的最大挑战是由上述因素带来的时延放大问题。
Serverless和Fass在腾讯文档的使用也是相当广泛。
[*]云函数应用fiber-test
在fiber workflow中无法直接触发 OrangeCI 中的自定义事件，因此使用云函数，将触发时需要的 token 存储在云函数中，根据需要触发对应的 OCI 事件。
4.3 常见问题解答腾讯文档团队上云实践历程公开后，收到了来自众多司内外业务团队关心和好奇。在此腾讯文档团队将一些高频被提及的问题进行解答，希望对你有帮助～如果您有疑问，欢迎在评论区继续提问。
Q:最开始接到上云任务时是什么情景？接到任务后自己心中是什么感受，身边的开发同事是什么感受，这样的感受是否有在后续发生变化？现在对于上云的认知是什么？A:腾讯文档在2021年1月开始进行服务上云计划，其中涉及到传统服务到符合云原生架构服务的重构，服务docker化，线网老服务从云下迁移到云上，CICD pipeline流水线创建等任务，最开始部分同学不理解为什么要花力气走云原生，认为直接部署到织云，物理机上挺好的，本地测试+打包后直接部署，但随着服务云原生的落地，CICD自动化pipeline的成功上线使用，同学们认识到云原生的优势价值，尤其对：无状态服务的自动弹性能力，生产环境中灰度部署能力赞不绝口。
Q:在上云过程中遇到过什么具体困难，怎么解决的？其中最艰难的是在什么时候？业务强需求的产品服务能力有哪些方面，是如何在云上实现的？A:服务上云后需要做很多的参数配置工作，哪些配置应该修改，应该设置什么值一度困扰着腾讯文档团队，比如存活/就绪检查参数，pre-stop参数，内核参数等，于是腾讯文档团队进行参数分类，然后指定专人对这些参数进行解释，使用场景说明，官方推荐参数值，如果参数与服务或运行时挂钩，就通过多次压测服务来进行综合分析获取符合该服务的最佳值域。
Q:通过怎样的手段确保和提升了文档的发版和用户体验？A:第一，保障的核心就是流程+自动化工具，为了提升文档发版稳定性和健壮性，腾讯文档团队制定了详细的BC发布流程。
腾讯文档C端CD发布交付能力流程图：
腾讯文档C端发布流程：
第二，为了增加不同维度用户的体验，腾讯文档团队在灰度发布过程中，增加SIT、UATStaging和Canary环境。
云原生拥有传统IT无法比拟的优势，它能从技术理念、核心架构、最佳实践等方面，帮助腾讯文档平滑、快速、渐进式地落地上云之路。在未来，腾讯文档将更加倚重云原生的能力，在聚焦于自身业务发展的同时，让更多的开发者基于云原生的技术和产品，提升开发效率，并将精力更多地聚焦于业务逻辑实现。云原生正在成为新基建落地的重要技术抓手，只有提前拥抱新基础设施，才不会被时代淘汰。
页:
[1]