1、1腾讯云技术实践精选集2腾讯云技术实践精选集卷首语近年来，云计算、5G、人工智能、大数据等新一代信息技术发展势头迅猛，加速了各行各业的数字化转型，数字经济俨然成了产业发展的新风口。身处技术革新的浪潮下的企业，更应顺势而为，抓住时代机遇。一直以来，腾讯云坚持以卓越的科技能力打造丰富的行业解决方案，构建开放共赢的云端生态，推动产业互联网建设，助力各行各业实现数字化升级以及产业的降本增效。与此同时，腾讯云不仅在技术领域不断创新突破，取得了沉甸甸的收获，还将积累的成功经验向外部技术同仁赋能输出。回望 2021，来自腾讯云的技术专家分别在 QCon 全球软件开发大会、ArchSummit 全球架构师峰会

2、、GMTC 全球大前端技术大会中，围绕“云原生技术应用”“数据库与存储技术”“前端业务架构”以及“架构设计”四个方面，分享了独到的技术见解与成功经验。腾讯云技术实践精选集 2021第一期将二十余位腾讯云讲师的演讲内容进行了收录，以期帮助更多中国互联网行业的同仁们学习腾讯云在技术演进、能力落地以及行业探索等方面的经验。展望 2022，腾讯云将持续输出更多的技术能力、沉淀更优质的技术内容，也期待与更多业界同仁一道推动产业升级，促进业务创新。3腾讯云技术实践精选集推荐序数据库行业迄今已有数十载，而历久弥新。随着互联网行业及云计算、5G、人工智能等技术发展，多种类型的数据呈爆发式增长，各种创新业务场景

3、层出不穷，冲击着这块古老而全新的软件领域，也促进了技术和产品架构的创新，使得中国数据库市场进入了百花齐放的阶段。从我的从业经历来看，越来越复杂的业务场景对数据容量、并发量、实时性、数据分析、安全性、容错性、可信赖等方面提出了更高的要求。硬件发展和软硬件一体化优化技术，给数据库设计者和开发者提供了更多解决问题的思路。腾讯云数据库构建了企业级分布式事务能力、云原生能力、超融合能力以及全球部署能力，在提供强大存储和计算能力的同时，简化了业务开发模型，在金融、游戏、物联网等众多关键领域中，都取得了亮眼的成绩。本册电子书收录了与数据库上海品茶相关的文章，结合了腾讯云数据库的实践经验，向外界传递我们的前沿探索/技术

4、实践，让更多业界同行从中获得有价值的见解。腾讯云副总裁 林晓斌“生于云，长于云”，短短几年时间，云原生技术便从出现走向成熟，在企业的数字化转型中发挥着重要作用。与此同时，云原生技术所涵盖的范围也越来越广，从容器、微服务、DevOps 到 Serverless、大数据、AI，只要符合云原生理念的，我们都可以称为云原生技术。那么这些云原生技术演进背后的逻辑是什么？究竟能够给企业带来什么价值呢？我认为用“降本增效”四个字可以涵盖。本册电子书的“云原生技术应用”部分将主要介绍如何利用云原生技术帮助企业实现“降本增效”。腾讯云容器产品中心总经理 邹辉4腾讯云技术实践精选集目录云原生技术应用数据库与存储技

5、术PART 01PART 02Service Mesh 在游戏行业大规模落地实践解决万千节点可观测性数据压力腾讯内部实践正本清源，你真的了解 Serverless 吗？百万级大规模容器平台的设计与实践腾讯云 Serverless 在音视频处理的探索与实践腾讯 Kubernetes 大规模离在线混部与内核隔离实践腾讯百万级容器规模的云原生平台设计与实践1000+企业云原生改造成本优化总结破解 Kubernetes 应用开发低效之困:一键调试，实时热加载腾讯大规模云原生平台稳定性实践Kubernetes 环境下极致开发体验-实时热加载和一键调试云原生 Serverless 数据库的设计与实践企业级

6、分布式数据库 TDSQL 元数据管控与集群调度TDSQL-C PostgreSQL 在云原生架构下的新活力“缓存+存储”架构下 Redis 持久化的探索与实践云原生数据库的“能与不能”腾讯云存储数据湖三层加速1.2.3.4.5.6.7.8.9.1.2.3.4.5.6.07263707790983138CONTENTS10.11.5腾讯云技术实践精选集前端业务架构架构设计PART 03PART 04TRTC Web SDK 新架构设计解析云剪辑实时渲染引擎设计音视频跨平台应用与元宇宙未来畅想Serverless 时代的低代码实践十亿级 Node.js

7、网关的架构设计与工程实践云原生微服务治理架构深度解读和实践腾讯云亿级 QPS 弹性负载均衡系统演进1.2.3.4.1.2.3.01791891976腾讯云技术实践精选集云原生技术应用PART 017腾讯云技术实践精选集近几年，云原生工具和技术应用持续增长，容器的使用和编排愈加流行，Serverless（无服务器）、Service Mesh（服务网格）等技术兴起。在大规模服务网格性能提升的需求面前，其过程中的探索价值凸显。在游戏行业的上云过程中，腾讯积累了深厚的经验，也探索出了自己的路。在 2021 年 Qcon 全球软件开发大会【北京站】中，腾讯云高级工程师钟华带来了主题

8、为Service Mesh 在游戏行业大规模落地实践的演讲，分享了腾讯云在这一领域的成功案例与最佳实践。Service Mesh 在游戏行业大规模落地实践钟华 腾讯云高级工程师Istio contributor，Dapr contributor,Tencent Cloud Mesh 技术负责人。专注于容器和服务网格，腾讯服务网格 Oteam PMC，在容器化和服务网格生产落地和性能调优方面具有丰富经验。发展趋势与挑战据 CNCF 发布的 2020 年服务网格发展趋势报告显示，在 1300 多家 IT 企业中，生产环境里使用 Mesh 技术的比例为 27%，较上一年（2019 年）提升了 50%

9、，预计未来还会持续增长；而所有的 Mesh 技术栈中，Istio 的使用比率最高。8腾讯云技术实践精选集数据面的统计数据中，2020 年在生产环境中使用了 sevice porxy 的比例大概是 37%，其中前两名是 Nginx 和 Envoy，分别是 62%和 37%，值得关注的是，Envoy 的增长率达到了 116%：为了获得更强的七层流量管控能力，一部分用户会从老牌的 proxy 迁移到 Envoy，比如 Nginx 和 HAProxy。这份报告中体现了两个主要的信息：一，服务网格生产落地持续增长；二，在技术选型方面，Istio 和 Envoy 还是主流的选择。但这份报告没有体现规模化体

10、验方面的内容，比如，使用这些 Mesh 的用户规模如何？实际上，在我们接触的 Istio 用户中，中小规模占了很大比重，这并不表明 Istio 大规模落地没有需求，而是其需求更复杂、要求更严苛。我们在大规模落地过程中遇到的问题，包括性能开销、场景限制、复杂度。其中最难的是性能开销，在给腾讯大规模的游戏客户做服务网格支持的时候，体会更深。大规模服务网格性能优化游戏服务本质上是互联网的产物或者互联网的组成部分，所以它有互联网服务的一些共性。比如，它们都是分布式环境，要求高可用，强调分离基础能力，有很多微服务等等。同时也有行业自身的特点，比如会产生更多有状态的服务。由于游戏体验强调实时性和强交互，所

11、以对延迟更敏感，稳定性要求更高。比如，Web 程序通常是读多写少，CPU 通常还好，但 IO 很密集；而游戏的读写都很频繁，CPU 和 IO 都非常密集。此外，游戏中的大量差异化玩法，在微服务方面则体现为更多的版本。1.利用 BPF 技术优化数据面转发链路优化为了提高性能，我们做的第一个优化是利用 BPF 技术优化数据面转发链路优化。首先，相比于服务直接通信，Istio 数据面的通信模型在引入 Sidecar 模型后，通信路径明显增加，具体来说，每个被劫持的报文会多经过 2 次协议栈，多 2 次数据拷贝。根据测试，这个架构在内核态的开销，大概占总开销的 30%左右。9腾讯云技术实践精选集BPF

12、 的全称是伯克利包过滤器，它在内核中已经存在很多年，是一个高效的虚拟机，它能以安全的方式在很多 hook 点执行我们提供的字节码。这里的核心工作是在 Socket ops 挂载我们的 eBPF 程序，拦截应用程序和 Envoy 之间的流量，直接发给对端的 Socket，这样就跳过了后续的内核协议栈处理。业界对这个问题的一些探索：业务进程和 proxy 之间使用 UDS 通信，数据包不会经过协议栈。但是 UDS 的缺点是对代码有入侵，需要用户显示面向 UDS 编程，这种做法常见于一些私有的 Mesh 方案，不适合公有云的场景。我们的方案是利用 BPF 来跳过协议栈的处理。10腾讯云技术实践精选集

13、在具体流程中，我们要关注连接创建和数据发送。当监听到连接创建事件后，程序把两端的 Socket 信息存到 Socket hash 中，这是一个高效的 KV 存储，Key 包括源和目的的四元组，Value 是 Socket 对象。当监听到消息发送的事件时，可以从当前的 Socket 信息中，分析出目的端的缓存 Key，利用这个缓存 Key，再去 Socket hash 取到对端的 Socket 对象。这样就实现了源和目的两端都跳过了后续协议栈的目的。这样操作的优化效果也比较明显：吞吐量提升了约 7.4%，延迟 p90 降低 15.6%，延迟 p99 降低 27%，基本符合我们的优化预期。2.xD

14、S Lazy Loading第二个主要是优化 Istiod 设计的缺陷 xDS 全量下发，带来的性能瓶颈。目前，Istiod 下发 xDS 的机制是全量下发，以左图为例，Workload1 虽然只依赖 Service2，但它的内存里会始终加载 Service2、Service3、Service4，因为 Istiod 会把所有数据都发给 Workload1。这会导致 Workload1 中的内存急剧膨胀，同时还要花大量的 CPU 去解析这些 xDS。另外，HPA 也会受到影响，Kubernetes HPA 通常是 Pod 维度，如果 Sidecar 里内存已经很高了，业务容器的内存可能就无足轻重

15、了，HPA 基本就失效了，这会导致系统稳定性比较差。当 Mesh 的规模增长以后，内存开销上升地非常明显。11腾讯云技术实践精选集具体流程是，一开始限制所有服务的可见性，Workload1 不加载任何服务，有任何请求都会拦截到 Lazy Egress（类似网络里的默认网关）去，Lazy xDS Egress 会分析流量的特征，然后把流量转发到下一跳中，紧接着在 Egress 会把这次访问关系，以 Access Log Service 形式上报到 Lazy-xDS-Controller 中，由 Controller 分析服务依赖关系，并将其以 CRD 的形式写到 Mesh。Istiod 更新了这

16、些服务依赖以后，后续就会把 Service 2 的信息下发给 Workload 1，后续 Workload 1 再次访问 Service 2 就是直连的。对此，我们也做了对比测试：在一个 Kubernetes 运行两个 BookInfo，左边开启 xDS 懒加载，右边不开启，频繁下发一些它不需要访问的服务。最终的优化结果是 900 Pods 规模 Mesh，单个 Envoy 减少 14M 内存；10 万 Pods 规模 Mesh，单个 Envoy 内存降低约 1.5G，优化效果比较明显。以上两个重要的优化，能够帮助我们支撑一些比较大规模的服务网格场景落地。面对这种情况，社区中有一个解决方案：用

17、 Istio Sidecar 这个 CRD 来做优化，在 CRD 里可以去配置服务的可见性或者服务依赖。但在大规模场景下，由于服务依赖关系频繁变化，很难梳理清楚，因此 Istio Sidecar 在大规模场景下比较难落地。我们的方案是实现 xDS 的动态懒加载，在网格里增加两个组件：一个是 Lazy-xDS-Egress，另外一个是 Lazy-xDS-Controller。12腾讯云技术实践精选集腾讯云服务网格在游戏行业生产实践TCM 是基于目前主流的 Mesh 技术栈：Istio 加 Envoy，所以 TCM 是完全兼容开源 Istio API。TCM 提供对 Mesh 全生命周期的管理，包

18、括 2 种部署模式，独立部署版和全托管版本，其中全托管版本中的 Istio 相关控制面组件全部由云平台来管控，对用户不可见，极大地降低了用户的运维成本。另外还有很多扩展能力，包括全托管遥测系统、深度的性能优化、协议扩展能力等等。典型落地案例欢乐游戏是腾讯老牌的游戏，主要的游戏品类已经运营了很多年，其核心的技术架构已经比较稳定，但在业务上云的大背景下，大家认为拥抱云原生技术，能提高大家的研发效率，降低运维成本并提升资源利用率。另外系统引入 Service Mesh，主要是为了实现精细化的流量管控，并提升系统的可观测性。这是目前欢乐游戏的整体架构，是公有云和 IDC 服务混合部署的架构。在上云之前

19、，欢乐游戏使用的是私有的 RPC 协议，上云后，云上使用的是 gRPC，云上和存量 IDC 服务间，通过自研的 Mesh Gate 做协议转换。同时这还是一个多集群服务网格，使用了 TCM 多集群单控制面，每个具体的游戏独占一个Kubernetes 集群，13腾讯云技术实践精选集还有一个存放公共服务的集群，所有服务网格相关的控制面组件都由 TCM 托管。欢乐游戏绝大部分都是有状态服务，大家知道 Kubernetes 有状态服务通常用 Stateful Set 来管理，Stateful Set 的特点是可以给每个 Pod 分配唯一的网络标识，能有序地部署和扩缩。但 Stateful Set 不是

20、很能满足欢乐游戏的调度场景。缩容时，Stateful Set 会从最后一个开始缩，比如这里有 1 2 3 三个 Pod，有可能最后一个 Pod 还有赛事在进行，而第二个 Pod 的赛事已经结束了。所以现在缩容时，不能删掉第三个，而是应该删掉第二个。欢乐游戏自研了一个工作负载控制器 game server set，可以把它看作是加强版的 Stateful Set，或者更能理解棋牌业务的一个有状态控制器。控制器会根据 Pod 里正在进行的游戏场次信息、当前容量等等业务数据，去实现扩缩容，而不仅仅是 CPU 和内存，这样实现了更智能化，或者和业务场景联动的有状态 Pod 调度。定向流量调度是什么意思

21、呢？大家知道游戏通常都有匹配系统，比如每个 Pod 上开启了不同的赛事，容量和资源也在实时地变化，简单来说，匹配系统需要根据这些输入信息，结合当前用户请求的特征，把用户请求路由到一个最合适的 Pod 里去。具体的匹配算法是游戏业务的核心逻辑，这里不展开。假设这个最优的目标 Pod 已经确定了，用户流量是怎么精确地到这个 Pod 中，这就是定向流量调度需求。简单来说，就是要把一个用户的流量，精确地路由到一个指定的 Pod 去，这是原生 Kubernetes 不具备的，这正是使用了 Istio 强大的流控能力。最后，欢乐游戏还用到 TCM 的一个高级特性CRD 中心化托管。每个业务集群都有自己的

22、Game server 控制器，每个控制器都要读写 Istio 流控规则，也就是各种 CRD，VirtualService，DestinationRule 等，熟悉 Istio 多集群架构的同学可能知道，在多集群 Mesh 中，CRD 是存在于主集群上的，只有主集群才能读写 CRD。TCM 在这里做了扩展，TCM 不但托管了 Istiod 相关服务，还把 Istio 相关 CRD 对象也做了托管，也就是把 CRD 存储也做了托管，这样 Mesh 内任何一个成员集群，都可以直接读写这些 CRD 资源。第二个案例是游戏电竞直播，这是一款海外直播平台，主要给欧美市场提供海外游戏直播服务。核心的技术诉

23、求是：电竞业务范围包括欧洲和北美多个地区，各地区服务需要具备就近访问和自动容灾切换的能力。首先，团队把开发语言切换到 Golang，RPC 切换到了 gRPC，这样可以更好地和云原生技术接轨。对于跨国流量穿梭，Istio Mesh 本身有多集群互通的能力，TCM 在此基础上提供了云上跨国际地域服务网格。14腾讯云技术实践精选集企鹅电竞在硅谷和欧洲等地部署业务集群，集群之间通过腾讯云云联网打通，这些集群的服务发现数据会接入统一的 TCM 网格控制面。这是典型的单控制面多集群服务网格。硅谷或欧洲用户的流量都会优先访问本地域集群服务。当本地域服务出现异常，会触发服务断路器，并将流量自动降级到另外一个

24、就近地域。整个就近访问、失效转移都是自动化的，开发运维同学不需要过多的配置和介入。企鹅电竞在整个系统中使用了大量的 Istio 流控策略，除了常见的灰度发布、流量镜像以外，另一个高级的流控场景是对有状态消息的定向路由。举个例子，在直播场景里有一个消息聚合服务，逻辑上需要 300ms下发一次，从性能上考虑会把一个直播间的消息都收集在一起，确保同一个直播间的消息都发到一个实例上，由一个实例来处理会更高效。为实现带状态路由，我们需要把相同特征的请求路由到一组相同特征的 Pod 上。在使用服务网格技术之前，需要我们在业务 SDK 中实现。在使用 TCM 后，这就变得很简单了，Istio mesh 对

25、gRPC 提供了一致性哈希负载均衡策略。比如，我们可以配置使用直播间 id 来做一致性哈希，通过使用这种方案，业务代码层无需做任何变更，由网格层来接管并实现带状态的消息路由。控制面板灰度升级与负载平衡的最佳实践对于大规模的 Mesh 落地，仅仅关注性能优化是不够的，还要重点关注控制面板的健康程度，这里分享两个最佳实践：第一，控制面板灰度升级，Isito 目前三个月发一个版本，版本更新比较频繁，而且经常有比较大的改动。所以大家总是觉得升级 Istio 是一个大工程，又容易出错。其实我们经常利用 Istio 的能力，对数据面业务做灰度升级，这是一种发布的最佳实践。对于 TCM mesh 的控制面，

26、它里面也是一些服务，所以灰度发布策略用于控制面也是很有价值的。所以在 TCM 上，我们对控制面灰度升级做了产品化支持，首先我们把新的控制面部署好，然后再对 namespace 逐个地注入新的 proxy，指向新的控制面，在这个过程中，可以随时去验证业务是否正常，异常情况可以随时回滚，升级完，老的控制面还可以保留一段时间，以备回滚之需。使用 TCM 控制面灰度升级，极大地降低了升级过程中的风险。15腾讯云技术实践精选集第二个控制面最佳实践是确保控制面负载平衡。先看看控制面负载不均问题：在 Istio Mesh 中，sidecar 和 Istiod 之间的 xDS 是一个 gRPC 长连接，当数据

27、面规模增长到一定程度，会触发 HPA 策略，Istiod 副本会进行扩容，但因为 Kubernetes 默认的随机负载均衡，老的 Istiod 还是会接到新 proxy 的连接。这会导致老的 Istiod 的连接和负载仍然会持续上升，进而影响其稳定性，在大规模的 Istio Mesh 中比较明显。目前社区提供了一个姑息的方案：周期性地断开 sever 和 client 之间的长连接，让 client 重连实现负载平衡。断连的周期由 Max Server Connection Age 参数控制。但这个方案比较鸡肋，如果时间设长了，控制面需要较长的时间来实现负载平衡，在实现平衡之前，控制面可能已经

28、出现了负载不均异常。如果设短了，数据面和控制面之间会有太多的断开和重连，会导致 xDS 数据流的低效，影响网格的稳定性。开源 Istio 难以解决以上问题的主要原因是，社区只能围绕 Istio 来做解决方案，而在云上，可以联合其它基础设施做解决方案，会有更多的选择。在腾讯云上，CLB 支持最小连接数算法，理论上可以满足我们的需求。但在实现过程中，还要解决一些链路转发问题。默认情况下，LB 绑定的后端 rs，是 Kubernetes service 在节点上的 node port，而当流量进入 node port，又会被 kube-proxy 的 iptables 拦截，所以最后结果又是随机的。

29、在 TKE 上还有一个高级的能力，CLB 直通 Pod，这种模式会给 Kubernetes 里的 Pod 增加弹性网卡，然16腾讯云技术实践精选集后 CLB 的后端直接指向 Pod 弹性网卡，就跳过了中间的 node port 和 kube-porxy。通过一个简单的例子就能够说明优化的效果：先启动 2 个 Istiod，数据面有 60 个 Pod，大概每个 Istiod 有 30 个 xDS 连接，中途再启动一个 Istiod，模拟 HPA 扩容的效果，同时把数据面扩容到 90，也就是增加 30 个数据面 Envoy。可以看到，在没有优化的情况下，新的 Istiod 接收到的连接大概是 10

30、 个，也就是新连接数的三分之一；优化以后，新的 Istiod 接收到了 26 个连接，用标准差来衡量负载均衡的效果，可以看到默认情况下的值是 18，优化后的值是 4，优化效果非常明显。17腾讯云技术实践精选集兵法有云：“知己知彼，百战不殆”。在企业 IT 系统运维层面，“知己知彼”用技术术语来讲就是系统要具备充分的可观测性，良好的可观测性能够让企业及时诊断故障、发现根因，有效降低运维成本、提升系统运行效率。Apache Pulsar 消息流平台，是云原生时代可观测性领域备受瞩目的一项创新技术，解决了海量数据聚合层面的很多问题和挑战。如何在企业内部集成并有效运用 Pulsar 平台是很多技术团队

31、关注的一大主题。在 2021 年 Qcon 全球软件开发大会【北京站】中，来自腾讯云微服务团队的赵善从发表了主题为解决万千节点可观测性数据压力腾讯内部实践的演讲，分享了腾讯解决万千节点可观测性数据压力的实践经验。解决万千节点可观测性数据压力的腾讯内部实践赵善从 腾讯云高级架构师曾历任 IBM 研发 Leader，AIOps 产品负责人，先后为国内外众多金融客户提供产品侧技术支持和解决方案。在云原生、大数据领域均有丰富的研发和落地经验。18腾讯云技术实践精选集云原生概述在腾讯看来，云原生本质上是一种行为方式和设计理念，凡能够提高云上资源利用率和应用交付效率的行为或方式都是云原生的。云原生的目标包

32、括控制成本、增加弹性、提升开发与部署速度、缩短迭代周期等。云原生的几大代表性模块包括：微服务：高内聚，低耦合，便于扩展；服务网格：控制应用的不同部分之间共享数据的方式；容器：应用实例容器化，跨平台屏蔽开发和底层差异，实现弹性扩缩容以节省成本；声明式 API：关注应用自身，而非系统执行细节。如 K8s 提供了服务编排能力；不可变基础设施：对于底层设施采用版本控制和可溯源的变更，避免产生冲突和事故。云原生应用的实现形式多种多样，并没有严格的规范和路径约束，在云原生领域也存在很多认知误区：第一个误区是云原生的使用误区，一些企业只是对应用做容器化改造，打包成镜像托管到 K8s 上；或者只是频繁 CI，

33、频繁使用 Jenkins，做很多 Pipeline，但不敢把应用发布到生产环境，不敢在生产环境中快速迭代，这样的系统很难称之为云原生系统。第二个误区是认为分布式、微服务可以解决一切问题。美国火星气候探测者号的失败就是个很好的例子。该案例失败的根因是地面与飞船的传感器分别使用了英制与公制单位，导致同步失败，没有对接成功。从微服务视角来看，这是两个微服务通信出现了问题，但追根溯源是微服务交互层面的设计出现了问题。微服务场景中，上下界切分与交互 API 是重要环节，也是保障微服务健壮性的关键。另一方面，探测器这样的场景属于典型的分布式系统，这个案例说明分布式并非解决问题的灵丹妙药，其本身有时会成为最

34、大的问题根源。那么，要如何处理好这样的生产问题？这里涉及到事件的可观测性。所谓可观测性，就是围绕着数据的生成、收集、捕获以及过滤的过程，对数据流进行处理来绘制数据流向，将复杂场景简单化，将问题抽象化，通过大数据处理等方式寻找根因的一整套体系。19腾讯云技术实践精选集可观测性的现状与展望可观测性最早起源于电气工程领域。随着系统复杂度提升，工程师需要一套机制来监控系统内部运行状态，通过一些方法和手段辅助解决问题。例如汽车生产厂商会在车身内安装各类传感器，来监控采集汽车的运行状态信息，以便发现和定位问题。在 IT 领域的云原生转型过程中，用户将业务上云后，需要一整套基于新架构的配套设施来助力企业转型

35、。新的架构效率要求更高、系统更加复杂、环境更加动态化、上下游依赖更多，这些因素都对可观测性提出了更大的挑战，针对每一项挑战也诞生了对应的解法：应用数量庞大、接口繁多、数据体量巨大：这一现状给后端带来了海量数据的上报+计算+存储困境，在 UI 层面则出现了页面信息不够直观，影响排障效率的困境。针对这两项困境，腾讯在后端引入大数据计算+存储+ETL 解决数据压力，在前端则提供丰富的筛选+排序工具，展现数据的立体视图，提供定制化的页面信息。应用关系复杂：由于应用层级众多、节点较多，应用关系逻辑图也很容易变得混乱无序。对此，腾讯的解法是锚定应用、定向过滤，定时高亮某个节点，或根据业务复杂度情况选择数据

36、流向图、力导图来展现信息。数据高效准确的需求与低成本的矛盾：需求越多，成本一定越高。海量数据和高效准确，精准实时计算和低成本之间都是一对矛盾点。为此，腾讯做了很多尝试，通过大数据后端计算和存储架构、通用计算平台来提升平台的整体利用率。20腾讯云技术实践精选集在可观测性架构落地实践中，可以在容器与中间件之间，部署一些埋点或无侵入式配置来生成下半部分的链路图。链路图从左至右，从上至下描述了当前的可观测情况，包括各个节点、链路、到达的中间件、时延等观测数据。可观测性架构也会收集一些基础资源的监控指标和日志。监控指标、调用链和日志共同形成了可观测性的三驾马车，三者良好结合就能输出很好的可观测性结果。当

37、前的可观测性架构也存在一些问题，如涉及的系统较多，运维成本较高；监控、日志和调用链并未打通，需要自行接通；相关工具容易被云厂商绑定等等。面对这样的混乱局面，行业也在向标准化、统一化的方向演进。腾讯正在设法更进一步，在不同协议之间做好适配工作，协调 OpenTracing 和 OpenSensors之间的不同点、三驾马车之间的不同点，最终形成可观测性领域的大一统框架。OpenTelemetry 是未来可观测性所遵循的统一框架。OpenTelemetry 统一了可观测性涉及的协议与采集端 Agent，同时支持云原生，提供良好的向下兼容能力：腾讯正在设法更进一步，在不同协议之间做好适配工作，协调 O

38、penTracing 和 OpenSensors之间的不同点、三驾马车之间的不同点，最终形成可观测性领域的大一统框架。OpenTelemetry 是未来可观测性所遵循的统一框架。OpenTelemetry 统一了可观测性涉及的协议与采集端 Agent，同时支持云原生，提供良好的向下兼容能力：统一协议：将调用链、日志、监控三者在源数据层面拉通，相当于采集到的数据是同样的对象，存储单元大致相同，从而方便互相传递和使用。统一 Agent：在采集层面拉通，所有语言遵循相同协议，各类数据按照同样的采集方式上报。云原生友好：支持容器与 Serverless，具备优秀的扩展性。兼容性：向下兼容谷歌、微软等国

39、内外厂商的各类标准、协议。目前 OpenTelemetry 也存在一些不足。首先是与各个厂商的沟通协调存在很大门槛；其次，由于后端架构种类繁多，如何协调统一的采集端也是一大挑战。接下来，三驾马车的数据如何有效关联和整合，产生联动效果同样是一个问题。OpenTelemetry 面对的最大挑战是海量观测数据与丰富的展现形式，给后台的存储和展现带来了沉重压力。为处理海量数据投入的资源成本也不可忽视，监控成本必须控制在合理水平，避免影响核心业务投入。21腾讯云技术实践精选集Pulsar x 可观测性云原生可观测性的降本增效针对上述问题，腾讯决定引入消息中间件 Pulsar，它具备很多竞品 Kafka

40、不支持的能力，例如计算存储分离设计、方便进行底层扩展等等。其中 Pulsar Function 提供了 ETL、数据实时聚合、分析、过滤和 Enhancement 等能力。通过腾讯的云原生可观测性实践，用户可以节省自建可观测性平台的成本，云厂商可以减少使用过多组件的成本，而 Pulsar 能够对云原生资源进行深度分解，实现高弹性伸缩，做更好的系列分析。在上述架构中，采集端 Agent 采集到监控数据后进行初步压缩，走 APM Gateway 做协议转换，拿到Span、Trance、Reference，通过 Pulsar Function 做 Splitter 或聚合操作，再到下一层的 Inde

41、x 做入库处理，或用 Flink 做更高维度、更复杂的大数据场景，最终放到时序数据库里就可以在前端直接展示。其中，Pulsar Function 具备一些区别于 Kafka 的能力。例如前者支持流式计算、无状态；开发人员可以自己编写代码扩展 Pulsar 的能力，例如做简单的数据驱虫或过滤时，直接在 Pulsar 上延伸就可以实现。在云原生支持方面，Pulsar Function 使 Broker 可以基于容器做横向扩展，提供很好的弹性能力。22腾讯云技术实践精选集总结而言，腾讯在可观测性领域希望达到“突破最后一公里”的效果，实现以下几大目标：更简单的追踪埋点，降低监控接入成本；更轻量的大数据

42、支持，降低大数据分析成本；更友好的用户界面，降低用户使用成本；追求应用可靠、稳定，实现性能与成本的平衡。23腾讯云技术实践精选集最近两年，业内关于 Serverless 的讨论主要围绕云厂商平台能够提供哪些能力，如扩缩容的效率、冷启动的时间、支持的语言运行时等，较少从应用角度思考，如何将传统的单体应用改造成 Serverless 架构？微服务是否是单体到 Serverless 的必经之路？对于这些问题并没有一个明确的答案，那我们究竟应该怎样去设计 Serverless 应用？在 2021 年QCon全球软件开发大会【北京站】中，来自腾讯云Serverless部门专家架构师杨政权带来了主题为正本

43、清源，你真的了解 Serverless 吗？的演讲。正本清源，你真的了解 Serverless 吗？杨政权腾讯云 Serverless 部门专家架构师曾任 ThoughtWorks 中国北美事业部技术总监，在过去的几年中，杨政权先后为电信、金融、税务、CPG、能源等行业客户提供提供定制化的软件开发和咨询服务。先后承担大型团队的研发组长、技术总监和企业架构师角色，作为客户主要的技术接口人，主导并参与客户的技术战略制定、技术战略实施和企业架构治理的过程中。他主要关注于企业架构、遗留系统改造、云原生架构以及企业数字化转型等方向。24腾讯云技术实践精选集云弹性之下，Serverless 价值几何？从物

44、理机、虚拟机到容器，随着抽象级别的提升，底层细节的关注度在弱化，比如关注虚拟机不再需要关注硬件，关注容器不再需要关注操作系统的一些细节。类比到 Serverless，可以减少开发者对服务器细节的关注。如果开发者要写一个 Serverless 应用，理论上只需要关注应用级别的一些属性，比如应用语言、内存占用、平均超出时间等。我们在提 Serverless 的时候，经常会提到 FaaS 和 BaaS 两个概念，FaaS 和传统的方式相比，具有更高的抽象级别，而抽象级别的提升也将促进社会化分工，比如，很多企业开始把和自己核心竞争力无关的工作交给云厂商处理，如虚拟机的运维、安全等。另一个相关的概念 B

45、aaS（Backendasa Service），云上大量开箱即用的服务可以直接使用，对于大部分企业来说，并不需要维护一个庞大的视频算法研发团队，也不需要招聘专门的人去做 OCR 模型训练等等，只需要调用现有的 API，直接复用现有的云上能力。Serverless 和传统的 PaaS 平台到底有什么区别？如果平台能做到以下几点，都可以叫 Serverless。第一，函数实例如 ScaleDowntoZero、容器等能否缩减到零，还是要一直运行；第二，能否快速启动。不考虑应用级别，平台级别的冷启动时间是否可以缩减到 100-200 毫秒左右；第三，能否快速扩展 FastScale。如今，业界各家

46、FaaS 产品的扩容能力基线是每分钟可以扩容 300 500 个函数实例；第四，能否快速回收。Serverless 作为平台提供方，仍然需要挣钱，需要考虑资源利用率的问题，在尽量避免冷启动的情况下，需要快速回收资源，降低成本，提升利润率。25腾讯云技术实践精选集目前，业界对于 Serverless 的认知还有一些误区，大家会认为 Serverless 可能更适合一些边缘场景，不太适合核心业务。我今天想分享一个乐凯撒披萨的案例，它是一家知名连锁餐厅，在全国大概有一百四十多家门店，从 2018 年就开始使用腾讯云的 Serverless 产品，截止目前已经有 90%的业务跑在腾讯云的 Server

47、less 产品之上。可以说，腾讯云的 Serverless 产品在和这家企业一起成长。对于一家企业而言，为什么要去采用 Serverless？除了本身 Serverless 按照用量计费能节约成本之外，我认为更大的价值在于能够支撑业务增长。就乐凯撒披萨的业务模式而言，它需要不断复制现有门店，跨地区、跨区域地开新店，基础设施变更周期至少需要 2-3 周的时间。在使用了 Serverless 之后，企业可以只用一个简单的命令，就能快速复制一套系统，支撑业务的飞速发展。从这个角度来说，Serverless 不仅可以降低开发周期、研发难度以及基础设施成本，还可以提升业务的响应力，支撑业务的快速增长。还

48、有另外一个音视频处理的例子，一家企业用了 Serverless 之后，可以做到 10 分钟之内瞬间拉起 5000-6000 个实例去做视频转码，把之前的一个小时转码时间缩短到 10 分钟。从本质上讲，虽然成本只降了 20%，但是对于企业，这意味着可以在 10 分钟之内拿到所有的合成结果。从业务人员角度来看，这就是用户体验和产品竞争力的提升。事实上，基础设施成本不仅仅是服务器消耗，也包括服务器的运维成本。据TheSateofServerless2020调查报告显示，将近 75%的受访企业已经采用了 Serverless 技术，关注的价值点依次是快速伸缩、研发效率和降低运维成本。26腾讯云技术实践

49、精选集Serverless 应用在极致弹性方面有哪些设计方法？Serverless 应用极致弹性的设计方法是什么？领域驱动设计几乎是业内默认的微服务设计方法。如果只把这样的方法适配 Serverless，在战略设计阶段其实并没有太大的差异，但是在战术设计阶段，首先会遇到限界上下文边界冲突问题。限界上下文其实更多的是逻辑边界，从业务的视角去拆分，在一个边界内，可以提升整个团队的沟通效率和弹性边界，而弹性边界是什么？当业务在增长，系统出现瓶颈的时候，模块复制的单元并不是一一对应的关系，于是会出现弹性边界和逻辑边界阻抗不匹配问题：举一个例子，音视频处理的限界上下文，如视频合成，它非常依赖专业知识，需

50、要团队成员在音视频方面有专业的技术积累，对类似音视频编解码中的采样率、分辨率、H264、H265 等的术语有统一认知（Ubiquitous Language），沟通无障碍。而在不同场景下，限界上下文内，不同场景的内存消耗不一样，实时性的要求也不一样，例如对于基本的视频拼接只需要 128M，但是 QPS（每秒查询率）很高，处理时间也只需要 60 70 毫秒；对于单录视频和27腾讯云技术实践精选集多录视频，处理时间比较长，对于 CPU 资源消耗也很多，而内存和 CPU 是绑定关系，需要通过提升内存来提升可分配的 CPU 资源。如果我们在进行 Serverless 应用设计的时候，不进行场景的细分会

51、导致成本过高、内存并发超限等问题。对于这两种场景，如果我们合并为一个 FaaS，会导致高昂的运行成本，因为在云函数产品的计费方式中，内存规格对于最终成本的影响非常大：512M 需要 1 万左右，如果内存规格是 2048M，成本将近增加了三到四倍。所以这也给了我们启示：在讨论弹性伸缩时，一定要在固定的成本下，考虑如何最大化弹性伸缩效率。企业的 IT 预算有限，决策者考虑的是如何实现投资产出的最大化。根据刚刚的例子可以看到，细粒度的 Serverless 应用设计可以降低企业的成本，那么，Serverless 的弹性设计边界之内，应用是否被拆分得越细越好？应该怎么度量软件的复杂度？JohnOust

52、erhout 提出了这样一个公式，子模块的复杂度 Cp 乘以该模块对应的开发时间权重值 tp，累加后得到系统的整体复杂度 C。系统整体的复杂度并不简单等于所有子模块复杂度的累加，还要考虑开发维护该模块所花费的时间在整体时间中的占比（对应权重值 tp）。这里隐含着一个修改扩散的问题，当完成一个功能的时候，修改时是否有连锁反应？有多少个模块需要被修改？每一个模块的开发时间占比是多少？在微服务设计里面，有一个概念叫 DistributedMonolith（分布式单体），指物理上分离，逻辑上耦合，这种情况需要极力避免。在 Serverless 领域，早在 2019 年 Thoughtworks 技术雷

53、达已经提到了 LambdaPinball 的概念，这种过度的模块拆分会增加系统模块之间的耦合度，从而增加整体的软件复杂度，可维护性会降低。目前业界有两个比较流行的 Serverless 应用设计方法，第一个方法是面向对象设计，沿着领域驱动设计的思路，分解弹性需求。28腾讯云技术实践精选集第二种方法叫函数式流派或者业务流程、业务流程图驱动设计，通过强类型约束 API 的输入输出，以状态剥离的方式，剥离业务逻辑中无状态操作，作为纯函数和有副作用的函数。这种设计方法最大的好处就是强类型约束，让开发者不必在代码里去做各种各样的边界检查，仅通过类型就可以做质量控制；此外开发者拆分出的函数，可以更加平滑地

54、迁移到 FaaS 平台。除此之外，这种设计流派还可以促进组织内部再分工。比如，让新员工去负责较为简单的纯函数，让资深或者有经验的同学负责有状态的函数。如何优化 Serverless 应用的冷启动？除了方法设计之外，企业如何持续优化 Serverless 应用？Serverless 应用不会一直驻留，需要被事件触发的时候才会启动，这就涉及函数的冷启动问题，不同语言的运行时和冷启动时间是不一样的，比如 Python、Go 的冷启动时间比较快，相对来说 Java 会慢一些：如果企业业务对于冷启动时间非常敏感，比如某些面向最终 C 端的产品，对于首屏加载时间非常敏感，那么就可以用类似预置并发的方式，来

55、降低冷启动带来的影响。在 Java 方向我们看到社区也在针对 GraalVM 进行持续探索，通过 Native Image 的形式用更小的内存、更快的冷启动速度来运行 FaaS 类型的 Java 业务逻辑，大家可以保持持续关注。此外，冷启动问题和应用设计也有很大的关系，在初始化阶段，需要避免去运行过于复杂的业务逻辑，导致冷启动时间过长，影响弹性扩容的效率。Serverless 走向何方？最后，杨政权谈了谈个人对于 Serverless 趋势的一些展望：29腾讯云技术实践精选集他认为，首先，Serverless+X 这种按量付费、托管的可扩展性应用的产品形态会诞生，比如中间件、数据库等等。其次，

56、ServerlessasEngine，对于最终 SaaS 产品的使用者来说，并不需要关心业务运行在虚拟机、K8s 还是 Serverless 之上，但 SaaS 厂商可以把 Serverless 作为应用的执行引擎，让企业无需维护底层的基础设施，即可获得 Serverless 的按量计费、弹性伸缩的价值，而这些价值会为 SaaS 产品带来更高性价比、更好性能的优势。此外，目前在 Serverless 社区开发者体验方面，ServerlessDX（Developer Experience）还不是很成熟，还有很长的路要走，我们需要一个更成熟的的开发者工具，来提升 Serverless 开发者的效率

57、。30腾讯云技术实践精选集云原生转型是当今企业数字化浪潮中的热点主题，容器平台是业务向云端迁移过程中非常关键的基础设施，但对于业务达到一定规模，现有 IT 系统比较复杂的企业而言，如何设计一套高性能、高可用性，且有着良好兼容性和稳定性的容器平台是摆在 IT 团队面前的一大挑战。具体而言，容器平台可能会面临集群规模差异巨大、数量众多，业务混合分布、类型众多，Workload 规模巨大，业务需求复杂等诸多难题，需要从基础架构开始打造一系列平台能力来应对这些挑战。腾讯在云原生转型的道路上积累了比较丰富的经验，内部开发了一套能够满足企业复杂需求的大规模容器平台。在 2021 年 QCon 全球软件开发

58、大会【北京站】中，腾讯云高级开发工程师严申就带来了主题为百万级大规模容器平台的设计与实践的演讲，分享了腾讯云在这一领域的成果与见解。百万级大规模容器平台的设计与实践严申 腾讯云高级开发工程师负责腾讯内部业务自研上云平台的开发设计工作，超大规模集群的调度优化、监控、自愈系统、网络等能力；内部业务（腾讯会议、QQ 等）上容器的业务改造、稳定性优化等技术支持。31腾讯云技术实践精选集大规模容器平台的现状和问题大规模容器平台的一些最佳实践腾讯作为头部企业，在设计大规模容器平台时需要考虑很多现实因素：集群规模差异：平台需要管理多个 K8s 集群，节点数量从数十到数千不等；集群数量众多：业务地域分布广泛，

59、每个地域都有双活甚至多活，总数在 100+；业务混布：业务数量极多（10000+）、类型各异，包括游戏、会议、AI、直播、爬虫等；业务需求复杂：有状态、长链接、本地升级、快切升级等；Workload 巨大：单个 Statefulset 可能有数千 Pod；单一业务可能同时包含上述所有问题和需求。针对这样的复杂现状，腾讯云将业务需求的所有功能与能力实现为平台的基础能力。1.StatefulsetPlusStatefulsetPlus 是腾讯自定义的 K8s 负载类型，可理解为 Statefulset 的升级版本，该负载类型包含以下能力：1.自动灰度分批发布，升级时可以定义 Workload 的百

60、分比（Num%），大多数版本的发布与更新都需要这一能力的支持；2.暂停/自动回滚；3.自定义发布时间间隔；4.原地升级；5.批量配置更新；6.maxUnavailable（最大失效副本数量）。32腾讯云技术实践精选集与原生类型相比，StatefulsetPlus 更适合大量 Workload、复杂升级需求和较多参数依赖的业务场景。例如，一个理想的 Workload 升级场景，定义自动升级分为 30%和 70%两个批次：在实际生产业务中可能面临较复杂的情况，例如，升级批次较多，每一个批次占用比较少时，当升级到中途发现问题，原生自动回滚会一次性退回失败时间点之前的全部批次，而 Statefulse

61、tPlus 可以按照之前升级的批次按序回退，并可以调整回退的时间间隔。另一种情况是升级与 HPA 的配合问题。例如，前 30%的批次升级完成后，后 70%的批次升级之前，HPA 对副本进行扩容，导致新版本 Pod 所占比例增大，与原定升级比例值不符。为此需要引入最大失效副本数等参数来确保业务无损。StatefulsetPlus 还针对 UDP 类型业务定制了名为“快切升级”的功能：33腾讯云技术实践精选集部分 UDP 流媒体业务在执行完整升级流程时，需要删除原 Pod，拉起新 Pod，为此要先剔除流量再加回流量，对高敏感度流媒体业务不够友好。以腾讯会议为例，这一场景会导致业务 Pod 重启时间

62、长达十几秒甚至一分钟。快切升级逻辑则在原始状态下，标准业务容器之外增加一个业务容器与 EmptyDir Volume。该 Volume 中写入一个文件充当锁，在正常情况下，是由上图中间的业务容器来提供服务，业务容器轮询，询问文件是否拿到锁，如果拿到锁就对外提供服务。升级时，可以在业务容器提供服务的同时，将下面的 Backup 容器镜像拉下来，只需将业务流量切换到新容器即可在瞬间完成快切升级，实现几乎无感知的升级过程。该功能还支持共享内存，有状态的服务可以用共享内存的方式，保持两个容器的业务状态信息不丢失。2.Descheduler 与 NPDDescheduler&NPD 主要包含以下四个能力

63、：1.高负载自动迁移；2.基于事件的 Pod 驱逐；3.分布式 Ping 检测；4.节点自愈策略。由于腾讯业务平台的海量节点数量及繁多的节点类型，Descheduler 与 NPD 就此诞生，这两项组件能够以代码的方式实现较为智能的节点重启操作，显著提升了运维效率，节省人力成本。此外，由于各种类型节点的重启策略不同，自动化操作可以避免人工操作时出现的误判风险。34腾讯云技术实践精选集Serf-agent 获取整个集群里所有节点的 IP，并随机挑选几个节点做 Ping 检测，Ping 检测失败后，Serf-agent 会通知多个 agent 重复检测，全部失败后生成聚合信息发送到 API Ser

64、ver，告知某节点已下线。集群外的 NPD Server 组件获取 NPD 相关事件后，根据 Recover Policy 执行一系列重启（自愈）操作，使节点恢复到正常状态。如下图所示，该功能还包含一些其它插件：以 PIDPressure 插件为例，当某些业务容器因为一些原因发起了过量进程后，检测插件会检测到出问题的 Pod，并将 Pod 信息放入一个 PIDPressure 事件中，再传给 API Server，NPD Server 会获取该事件，驱逐该 Pod 或发送告警信息。对于 RuntimeProblem 插件来说，当 Runtime 出现问题时，该插件能够自定义策略，优先排空 Po

65、d 重启运行时，恢复业务并保留现场后再排查问题。根据实践经验，常用的自愈行为分为以下步骤，具体策略也可以根据实际情况做调整：重启运行时，解决 Pod 持续 pending/creating 的问题；驱逐业务 Pod，节点有问题时对外提供服务为最高优先级；重启 Node 节点，快速解决节点问题；删除节点，适合节点数量较大的情况。自愈特性方面的经验：跳过 Cordon 掉的节点，避免节点重启以便排查问题；节点可通过 labels 指定不生效的行为；35腾讯云技术实践精选集 强制重启；具备可观测性，所有自愈操作在 Prometheus 上可见。节点负载较高时根据负载情况进行 Pod 迁移，降低高负载

66、节点比例。Descheduler 根据 CPU、内存、PID等指标判断负载情况，并根据 Pvc 挂载情况、Pod 删除保护、label/annotation 标识等信息判断业务 Pod 能否被 Deschedule。分片的云原生监控在监控方面，腾讯容器平台提供了云原生标准监控方案、分片支持海量数据、全局查询、定制化精细监控指标等能力，这些能力能够更好地支持平台超 3 亿 Series、300+Prometheus 实例和大小不一的海量集群。在整体架构中，每个集群内有一个 Slipset，其中三个容器分别是 Prometheus、thanos sidecar 和 kvass sidecar：这里

67、的 kvass sidecar 负责解析 kvass 协调器下发的配置文件，并动态生成配置文件发送给 Prometheus 实例，让 Prometheus 收集相关监控指标。而 kvass 协调器负责读取常规的 Prometheus 配置文件，然后收集所有 Series，计算 Series 总量，并按照设置比例动态分配到多个不同 Prometheus 实例中，再分配给 kvass Sidecar。当集群中 Series 数量非常大时，无论让 Prometheus 收集还是人工拆分都很困难，而动态分片就可以根据 Series 数量的变化动态计算分片情况。Kvass 是 Prometheus 横向

68、扩展解决方案，分为 Sidecar 和协调器两个组件；Thanos 负责数据汇总和全局查询；Discovery 进行跨集群 Prometheus 实例发现，每一个集群里有一个 Discovery，负责汇总集群中所有 Prometheus 实例，上报到 Thanos Global Query 组件的配置文件，确保 Thanos Query 在集群扩容时识别所有实例；Container-exporter 是容器内监控实例。根据分片云原生监控实践，我们也总结了以下几方面经验：36腾讯云技术实践精选集1.单实例 Prometheus 一般设置为 200 万 Series，可以实现较稳定的状态和合理的内

69、存使用比例；2.200 万 Series 配合 24GB 到 32GB 内存+800GB 磁盘；3.Series 数量占比最大的是 Cadvisor 和 Kube-state-metrics。单集群里的 Kube-state-metrics 会暴露集群里所有对象的原数据信息，实践经验中一个集群可能有超过一百五十万条数据。类似地，Cadvisor 的 Metrics 数量可能占整个监控体系里面 60%；4.针对第 3 条可以有两个优化措施，首先，裁剪一下 Cadvisor Metrics。Cadvisor Metrics 有一些可以后续聚合计算，例如一个 Pod 的 CPU 使用情况，可根据 P

70、od 里三个容器各自的使用情况聚合计算得来；5.当集群太大时，Kube-state-metrics 的单个 Target 的 Series 会超量；且 Series 数量太多时，每一次采集在指定时间内无法全部读完。为此，可以做 Kube-state-metrics 分片，这是 Kube-state-metrics 组件原生支持的。但分片数量不能太多，因为 Kube-state-metrics 会频繁 List 所有 K8s 对象；6.Container_exporter 可以在容器业务较关键时，收集容器的进程、线程、CPU、内存等数据。该方案提供一个二进制基础镜像给业务使用，业务将镜像放入自身

71、容器，镜像将对应数据推到 Pod 所在节点部署的 pushgateway 上，之后再由 Prometheus 发现 pushgateway，收集数据做聚合计算。该方案的优势是高精度和高频率，其 Exporter 可定制，并且可以做到非常轻量化。之所以做容器内监控，是因为常规情况下很多业务没有原生暴露的 Metric，只能通过容器内监控进行数据收集。而 Node_exporter 不够轻量化，一些计算方式不兼容器类。而使用 Daemonset 的方式部署 Pushgateway，则是为了避免所有容器内监控数据推送到 Pushgateway 形成单点故障。37腾讯云技术实践精选集其他实践 IP 规

72、划与配额动态分配：当集群规模较大时，IP 数量可能不够用，为此要提前做好 IP 规划和动态分配，有些集群的 IP 空余时要设法回收。固定 IP 的优势：方便添加黑白名单，针对一些有状态业务的 IP 保持不变。HNA：集群节点可以横向扩缩容，从而提高集群资源利用率，降低集群故障率。HNA 还支持计划扩容，能够提前一段时间写好扩容规划。容器平台技术演进方向实现 EKS（弹性集群）的一些能力：通过无节点概念降低运维成本，同时完全兼容 K8s API；支持多个可用区；实现业务画像能力，通过中心调度决策系统从 Prometheus 读取数据，为不同的业务绘制画像，计算扩容等决策。服务网格：跨多个集群的服

73、务网格将逐渐淡化整个平台的集群概念，让所有业务流量通过服务网格的方式跨集群、跨地域进行优雅地切换和备份。每一个可用区有一个服务网格控制平面，整个平台上所有 K8s 集群内的 Pod 接入完整的数据平面，控制平面和数据平面的交互是用户不可见的。这样用户无需考虑服务部署在哪个集群，且服务部署时可以直接部署在多个可用区，通过服务网格的形式进行流量转发和备份。38腾讯云技术实践精选集Serverless 服务是腾讯云近年来发展的重点。在音视频处理领域，腾讯云也在积极探索将 Serverless 架构与音视频处理技术相结合，为用户带来更加低成本、高性能、高扩展能力的音视频处理底层服务能力。在 2021

74、年GMTC 全球大前端技术大会【深圳站】中，来自腾讯云的高级工程师，Serverless 应用后台模块负责人田梦敏，重点分享了音视频领域在 Serverless 场景下的落地实践。腾讯云 Serverless在音视频处理的探索与实践田梦敏 腾讯云高级工程师&Serverless 应用后台模块负责人2017 年加入腾讯，先后负责 CVM 候鸟迁移、域名解析、apigateway、云函数自动扩缩容等业务，目前主要负责 Serverless 应用的研发工作。39腾讯云技术实践精选集音视频市场背景音视频内容生产和消费的痛点据 UserTracker 2020 年的互联网网民数据显示，85 后已经成为互

75、联网主流的用户群。与此同时，互联网主流娱乐形式与过去相比发生了巨大变化，短视频成为了新的舞台焦点，这意味着音视频的市场需求大幅增长，UGC 创作场景常态化与视频消费形式的多样化，对视频底层技术也提出了更高的要求。例如，超高清回传、实时共享、自由视角、自由缩放、云端制作渲染和强交互等需求，均需要音视频底层基础设施具备更强的能力。市场需求落地到底层技术一侧后，可以提炼出音视频技术所面临的主要挑战。整体而言，当下行业面临的挑战可以用四组数字来总结：1.40：由于用户使用的设备多种多样，创作视频时使用的编码格式各不相同，生成的视频封装格式非常多样。平台需要应对的视频格式有 40 多种，要做到统一管理、

76、形成标准输出是一大挑战；2.320p/4k：主流视频清晰度的跨度非常大，从 320p 一直到 4k 不等。不同的清晰度需要对应不同的算力进行支持，如何做到灵活调度算力也是一大挑战；3.10：一般来说，视频生产者制作一到两小时时长的视频，转码、渲染到最终输出结果的过程需要在 10 分钟内完成，才能提供比较好的体验。这对后台的处理效率提出了很高的要求；4.1000w：考虑到上述复杂的需求，当平台用户量达到千万规模时，音视频提供商需要具备相当高水平的资源储备才能有效应对流量波峰。这样势必会造成底层资源的浪费，同时大幅提升资源成本。上述挑战进一步总结可以归纳为：1.带宽成本高昂：当视频数量或者用户量增

77、长的时候，迫切需要进一步减少码率，降低企业运营成本；2.服务器成本高：自建转码服务器开销和运维成本较高，需要考虑可用性、扩展性、监控、升级、容灾等情况;3.内容质量参差不齐：内容生产流程不规范，环节间剥离，沉浸感差，非常依赖于各个环节人员的经验；4.定制化不足：转码算法灵活度、定制化能力不足，无法满足用户或者企业对于个性化、定制化的使用需求。40腾讯云技术实践精选集基于 Serverless 的海量音视频处理方案为了让大家更好地理解 Serverless，这里举个小例子：日常出行的方式一般有网约车、汽车租赁和私家车三种选项。其中网约车是按需付费、随叫随到；汽车租赁需要付出租金、保险、油费等成本

78、；私家车则需要车主一次性投入一笔不小的资金，后续还有一系列的维护保养的投入。将驾车出行的情况类比到 IT 行业，就相当于 Serverless 对比虚拟机和物理机。像网约车对比私家车和租赁车一样，Serverless 的运维成本是有显著降低的。Serverless 更大的优势是弹性快速扩缩容，传统的音视频提供商如果没能准确预测业务的流量高峰，就可能遇到流量高峰时流量溢出的故障。但如果将 IT 资源准备得足够丰富，就会造成资源的巨大浪费。相比之下，Serverless 的核心优势就是基础资源设施具备极高利用率，其按需付费、弹性伸缩的特性能有效降低运维成本。基于上述特性，腾讯云探索了一系列 Ser

79、verless 解决方案来应对音视频领域的几大挑战。第一个场景是音视频转码方案。该方案有以下优点：1.中间转码层采用了腾讯云多媒体实验室的转码算法。该转码算法在多媒体领域深耕多年，是腾讯内部 QQ、腾讯视频等应用的基础支撑组件；2.方案灵活可定制。客户可以随意扩展云函数功能、修改入参，或者使用自定义算法完成视频的拼接、补帧等等；3.成本更低，支持高并发。充分利用 Serverless 天然的按需付费、快速弹性扩缩容特性；4.效率更高。云函数是按需付费的，一个大的视频文件拆分后，并行触发多个云函数转码，在大幅提升转码速度的同时，不产生额外费用。第二个场景是音视频的单流、混流录制后处理方案。该方案

80、是与 TRTC 深度合作的成果，利用 TRTC 团队的 SDK 进行了深度优化。例如，用户在互动直播的过程中，想要拉取 TRTC 房间里的某一路或者多路流做后处理工作，经过云函数优化后这一目的能够得以实现。该方案具备定制化优势，可以满足很多个性化场景。用户基于云函数的开发模式可以做到敏捷高效开发。同时该方案特性均以应用的形式深度集成了云上产品的 SDK，方便用户直接使用。41腾讯云技术实践精选集第三个场景是音视频全景录制方案，该方案也结合了 TRTC 的 SDK、云上白板，即时通讯的 SDK 等技术。该方案将整个 SDK 融合到一个客户端页面，云函数模拟一个客户端，接收客户传给方案的数据。相当

81、于一个虚拟的浏览器，把用户的所有数据通过实时截屏的手段录制下来，后续转码为用户想要的视频格式。该方案的优点有：1.具备一键触发能力，可以实时弹性启动，由服务端执行浏览器全景景象录制；2.实时截屏可以将多方视频源混流，大幅降低算法开销；3.多路直播流、白板、信令等同步集成，避免了时间不一致情况；4.录制过程中可以灵活调整布局，可以录制弹幕等内容。全景录制架构图包含多个函数，多个函数组成一个工作流，每一个功能对应的原子函数经过工作流编排，形成全景录制整体应用。发起任务时，向应用输入视频地址、录制时间、录制码率、输出格式等参数就可以开始录制。dispatch 功能负责增删查改，如发起录制、停止录制、

82、暂停录制、查询录制任务状态等。录制的文件是分段的，每一个小文件逐个上传到 COS 触发实时转码，录制完的文件可以上传到 COS、ARD 等，上传的原子函数完成之后，应用可以报告用户录制已完成，由用户决定下一步操作。该录制方案为了保障录制的可靠性，每一个环节都有专门的函数监控，确保足够高的 SLA，满足金融等高可靠性场景的严苛要求。目前，该方案的可靠性已经得到了重点行业客户的实践验证。在线输入媒体流方案主要针对定时发送视频的场景。例如，教师可以把上午录制好的讲课视频，上传到 COS 后建立一个定时任务，在指定时间将视频推送到指定房间。该方案具备很好的通用性，并利用 Serverless 的特性做

83、到了高性能与极低延迟。Serverless 视频智能化编排处理方案，使用户能够轻松通过可视化编排的方式，构建定制化视频处理流程。Serverless 应用将所有视频处理功能做成了原子化云函数，每一项原子能力都以 demo 的形式存在于云函数之上。用户可以自行更改 demo，之后，可以将各个云函数在可视化界面中组合起来。不同能力可以直接复用，整个流程也实现了标准化操作。42腾讯云技术实践精选集从上述解决方案可以看出，Serverless 音视频方案相比传统技术有三大优势：1.灵活性优势。云函数具备很多规格的算力资源配置，能够通过弹性伸缩能力自由处理各类任务。云函数的参数可以灵活修改，自由定制。云

84、组件支持自定义编排处理流程定制化，标准化；2.算法优势。腾讯云 Serverless 音视频方案标配腾讯多媒体实验室自研的高效编解码算法，其得到了腾讯多个业务及大量用户的实践验证，具备行业一流水平；3.成本优势。Serverless 支持按需付费、弹性伸缩，不需要运维或者运维需求极低，能够灵活应对流量高峰低谷，及时扩缩容，相比传统平台有明显成本优势。目前 Serverless 音视频解决方案主要有四大类应用场景：教育录播课、媒资管理审核、短视频编辑分发和直播与视频拆条回放。凭借 Serverless 方案的几大优势，这些场景的音视频应用可以获得性能、功能、开发速度、可用性、成本效益等多方面的显

85、著提升。43腾讯云技术实践精选集在线与离线业务混合部署的背景下，在线负载与离线负载之间的隔离变得尤为重要。在实践中，传统的资源隔离方式暴露出了隔离力度不够、无法保证强隔离等诸多缺点。在 2021 年 QCon 全球软件开发大会【北京站】中，腾讯云专家工程师徐蓓、专家工程师蒋彪两位老师分享了腾讯 Kubernetes 大规模离在线混部与内核隔离实践的主题，介绍腾讯 Kubernetes 利用自研内核 QoS 技术，实现主要资源强隔离，在内核层面保证在线离线资源服务质量，并在保证业务稳定的前提，将工作节点利用率提升到极致。腾讯 Kubernetes 大规模离在线混部与内核隔离实践蒋彪 腾讯云专家工

86、程师徐蓓 腾讯云专家工程师12 年专注于操作系统技术，在操作系统内核、虚拟化和性能优化相关领域有丰富的研发经验，负载腾讯云底层性能优化和相关研发，Linux Kernel 社区贡献者。11 年软件架构与研发经验，其中 7 年云计算经验，在 IaaS、PaaS、离在线混部和云原生大数据领域有丰富的研发与落地经验，Kubernetes Contributor，开源爱好者。44腾讯云技术实践精选集腾讯 Kubernetes 混部实践腾讯混部背景在生产环境中，观察资源申请或负载层面的资源消耗会发现，在线业务申请资源时往往按照峰值申请，峰值和真实利用率之间会很大 Gap。在线资源在 CPU 层面的整体利

87、用率均值小于 15%，这部分 Gap 资源称之为闲置资源，往往是被浪费掉的。反观离线资源会发现它是 Best Effort 属性。给它的资源供给越多，业务的运行质量会越好，运行时间也会越短。离线任务集群均值，按照实际经验，大概率会大于 40%。离线计算业务密度非常高的环境里面甚至可以达到 70%、80%左右。在资源管控或者调度层面，一般在线和离线业务分属于不同的资源管控和调度系统。如在线业务通过 Kubernetes 集群做资源调度和管控，离线业务使用专门的管控调度系统，比如 Yarn、Spark 和 Flink 等。在线和离线资源管控端的分离对业务方、资源运营方都会带来巨大的管理成本。在这两

88、个大的背景下，腾讯云希望通过 Kubernetes 层面在调度层面做到统一，提升研发效率。第二核心目标是将在线和离线通过 Kubernetes 部署在一个大的共享集群里，提升整体资源效率，大幅下降整体资源成本，大幅下降整体资源开销的 30%左右。腾讯混部发展腾讯很早就开始实践混部了，2009 年主要使用 LXC 容器做隔离，底层通过 cgroups v1 实现，但整体的隔离效果不是特别好。2014 年开始，随着 Docker 技术的日趋成熟，腾讯云把底层容器技术完全切到了 Docker 容器平台上。45腾讯云技术实践精选集2017 年开始，随着云原生领域以 Kubernetes 为代表的容器平

89、台的完全成熟，上层的管控端完全切到了 Kubernetes 上。彼时在线资源用 Kubernetes 做整体的资源管控和调度，在隔离层面更多依赖 v1。腾讯云内部还做了一个 Linux 发行版，加入非常多的面向容器的隔离实现，保证整体混部后在线不会受离线任务的影响。2019年开始，腾讯云逐渐把离线计算完全切到 K8s 上，最终做到了在线和离线统一，通过 K8s 统一管控调度，底层完全做混部。资源隔离层面完全切到了 v2。内部的 Tencent Linux 发行版升级成了 Tencent OS 完全面向云原生和容器的实现，在资源隔离层面做到了非常好的效果。Tencent Kubernetes 离

90、在线混部架构任务级别方面，根据任务负载的特点分为在线和离线。下面又会根据不同业务对 QoS 要求的不同进一步划分。比如在线这边划分成在线高敏和在线低敏，对应底层不同的资源隔离的实现。离线这边一般会设置成最低优的任务资源。调度层面，在线和离线分走不同的调度器，用原有的 K8s Schedule 做在线层面调度。除了性能层面做了一些大优化以外，在策略层面主要实现了节点层附带感知，从而在业务调度决策时动态感知整个集群节点层面的真实负载，维持较好的负载均衡。离线层面自研了 tke-scheduler 调度器，batch 性能对比 kube-batch 有约 10 倍提升。调度策略上实现了 gang-s

91、chedulling 等策略，完全满足大数据、机器学习等计算任务的调度需求。46腾讯云技术实践精选集资源层面，在线业务会把所有集群层面的账面资源用满。一个资源预测器模块会实时根据节点上在线资源的负载预测闲置资源，给离线调度器使用。通过这种方式做到了整体，尤其是离线资源层面的超卖。整个集群层面离线计算能大概超卖 60%左右。做混部之后，在线业务不能受离线业务影响。所以架构中一个非常重要的模块是 Resource QoS manager 插件式框架，内部实现了 4 个主要资源的隔离实现，包括 CPU、内存、磁盘和网络。Kubernetes 1.19 开始默认支持 cgroup v2，支持 v1 到

92、 v2 无缝转换，除了开源内核支持外，我们跟 Tencent OS 内部发行版的内核做了深度集成，在资源隔离层面做了非常紧密的结合。通过上述架构部署，集群达到千万级以上规模。集群整体 CPU 均值达到 46.5%左右，在有些离线计算密度非常高的集群里可以做到均值 65%。资源隔离：CPU 隔离CPU 隔离层面，因为 Tencent OS 内核是完全面向云原生容器领域，所以内核层面就提供了优先级的概念。腾讯云在 Kubernetes 层面做了三个优先级对应，Guaranteed 对应 p0 优先级，Burstable 对应 p4，BestEffort 对应 p7。OS 本身还提供一个非常重要的功

93、能，可以做到对低优先级任务的 100%抢占。内核在 CPU 调度上，一般采用 CFS 调度，有三种分配策略：第一种是 cpuset，是物理核绑定；第二种是 cpu quota/period，是 CPU 时间片分配；第三种是 cpu share，做权重分配。CFS 是基于 CPU 时间片的完全公平调度，但它实际上不能保证 CPU 100%抢占，底层资源节点 CPU 紧张的时候，高优资源并不能 100%保证在下个时间片区被分到。如果是一些 CPU 敏感型的业务，在资源紧张的时候可能会受损。在这样的前提下，Tencent OS 的 CPU 层面能在整体 CPU 紧张的时候被 p7 以上高优任务做抢占

94、，这样保证高优任务不会受到低优任务的影响。在整体核分配上，在线进一步划分成在线高敏和在线低敏。高敏业务一般做单独 cpuset 绑定，但是量不会特别多，目前预估整个集群 5%的业务会做单独绑定核操作，剩下 95%的 CPU 核会和整体的离线计算混部在一起。观察生产集群，干扰率能小于 5%，甚至离线计算压满的情况下干扰率也在 5%以下。这一套 CPU 隔离的47腾讯云技术实践精选集方案整体的效果非常好，完全达到生产级别的预期。资源隔离：内存隔离内存本身不可压缩，极端情况下可能高优或者中优的任务就直接被杀死，业务是不能接受的。在这样的背景下，我们更多采用对任务内存做抑制的方法，保证不会进入到任务杀

95、掉的粗暴路径。内存回收层面实现了优先级感知功能，可以根据优先级做排序的杀死。在整体内存回收的水位线做了分级实现，比如会把低优 wmark 的水位线上移，这样有些低优的资源密集型的任务在大量申请节点资源的时候会触及水位线，从而做到抑制的效果，使整个节点层面有一个缓冲的机会，保障整个节点的内存水位线处在比较健康的状态。资源隔离：内存 QoS这里利用了 cgroups v2 Memory Controller 提供的两个参数，一个是 memory.min，主要做 requests 级别的保留。在 pod、Container 或节点层面做内存申请时，会在 memory cgroup 里针对这部分内存做

96、预留，保证进程肯定能拿到这部分资源。第二个参数是 memory.high，做超分配内存的 throttling。比如有些 pod 创建的时候，requests 是小于 limits 的，limits 到 requests 之间是超分配的内存。如果默认是 80%限制，memory.high 就设置成 limits 乘以 80%，设置这样一个水位线。触及水位线以上的内存申请都会被 throttling。这样从超卖内存层面保证整个节点层面的内存不至于迅速被超卖的 pod 消耗完。Tencent OS 在腾讯内部已经演进了超过 10 年时间，是腾讯云独立维护的一个发行版，后续的目标是做成一个面对云原生

97、场景完全定制的操作系统。Tencent OS 在底层的资源隔离技术方面提供一个完整的解决方案叫 RUE。Tencent OS 面向容器场景的实践48腾讯云技术实践精选集以上是 RUE 的架构，最底层是 cgroup priority，在内核当中引入了 cgroup 优先级的概念。优先级是所有资源共用的基础，所有资源都基于优先级做 QoS。中间层是资源 QoS 的 4 个模块，分别是 CPU、内存、网络和 IO。最上层做了一个 Resource Quality Monitor，可以实时监控不同优先级的 pod 服务质量。服务质量方面主要包括几点内容。首先会对不同优先级容器的服务质量打分，当发现关

98、键的 SOI 不能满足要求的时候，会自动记录关键信息到 Monitor Buffer 里面，可以在出现干扰的时候实时抓到干扰的现场。RUE：cgroup prioritycgroup 优先级是所有资源共用的核心基础设施，统一优先级的概念刚好跟 cgroup v2 理念完美结合。目前 RUE 支持 8 个优先级，可以整体覆盖 K8s 云原生的三个 QoS 级别。这里最大的特点是不同优先级之间可以实现绝对抢占，高优先级需要资源的时候可以立刻绝对抢占低优先级的资源。同优先级的容器之间是按照权重分配资源。49腾讯云技术实践精选集RUE：CPU QoS腾讯云对于调度器做了非常彻底的改造。在资源隔离层面整

99、体的解决方案叫 TCNS，Tencent 云原生调度器。这个调度器整体上由三个调度类组成，可以覆盖所有场景的混部。第一个调度类叫 BT，离线调度类，主要针对容器的混部；第二个是 VMF 调度类，叫 VM First，专门针对虚拟机的混部，也可以针对安全容器的混部；第三个是对面对通用的场景，跟社区结合更紧，这个调度类是 ECFS。面向容器的场景主要用 BT 调度类。它的三个特点，第一个是绝对抢占。因为社区里面的 CFS 基于公平原则，要考虑通用性，要覆盖所有场景，所以很多决策都做得比较保守，没有办法达到极致的需求。比如说在高低优的优先级的进程之间，它始终是有时间片的分配，就是最低优先级也能分配到

100、一定的时间片。所以这种情况下，它的混部的 CPU 隔离效果就没有办法做到极致。但是如果按照社区的机制、思路去改造 CFS，对于社区来说是完全不能接受的。因为如果改造成绝对抢占的方式，离线有可能会出现饿死，有可能出现优先级反转的问题。社区在考虑这样的问题的时候，是不可能接受去做这样的深度改造的。腾讯云在很早之前就自己写了一个离线调度类，是在 CFS 后面加了一个调度类 BT，它的优先级比 CFS 更低，当有 CFS 进程运行的时候，其实离线任务是没有办法运行的；当 CFS 不跑的时候离线才能跑。BT 里面实现了 CFS 最基础的功能，比如 cgroup，还有其它的一些单核调度负载均衡功能。另外它

101、可以做到是绝对隔离。因为 BT 的调度类优先级比 CFS 低，所以可以达到绝对抢占的效果。然后是超线程干扰隔离，同一个 CPU 的超线程之间要共享一些核心计算资源。这种情况下，当在线和离线同时运行在一堆超线程上的时候，干扰是绝无法避免的。针对这个问题，社区其实没有一个完整的解决方案。这里在调度的一些关键节点，比如说在调入、调出的时候会做一些检查，可以避免离线和敏感的在线业务同时运行在一堆超线程上面，实现完美的隔离。最后一个特点是由于腾讯云对调度器做了完整、全面的改造，所以核心竞争力是具备完全的定制能力。因为混部场景非常复杂，不同场景下的需求可能是不一样的。所以腾讯云可以根据业务的场景去适配、改

102、造调度器，满足业务要求。一个实例是微信的一个业务上面的混合效果。因为微信业务对延迟非常敏感，整体的 CPU 利用率从原来的15%做到 60%均值。在一些对延迟不敏感的场景里面可以做到 90%。50腾讯云技术实践精选集RUE：内存 QoS在混部实践进入深水区的时候，内存的复用是最大瓶颈。这里面的关键痛点是没有办法保证在线业务分配内存的延迟。分配内存有很多条件，达到某个水线以后会进入不同的流程。其中最头疼的是一旦进入慢速度路径，它的延迟是完全不可控的，有可能是秒级的。这种情况下，对于高优的容器是完全没有 QoS 保障的。内存回收方面也有一个天然的问题。内存回收的时候时间也是不可控的，尤其是在标准的

103、 OOM 场景，OOM 要给进程发信号，发了信号以后依赖于接收信号进程的调度的上下文。它得到调度以后才自己去回收自己的内存。但是在混部的场景当中，离线的优先级比较低，当 CPU 压力比较大的时候要去回收它的内存，它根本得不到调度，这个时间是完全没办法控制的。在分配的路径上，现有内核里也是不感知优先级的，没有为高优容器做特别保障。RUE 在这提出一些关键的解决方案。第一个是优先级，第二个是不同的优先级可以对应不同的水线。在分配的路径上可以保障高优容器的水线更低，更少进入直接回收流程；低优水线更高，达到水线的时候更早做抑制。在回收流程上，RUE 也是完整感知优先级。回收流程主要包括 OOM、Rec

104、laim 和异步回收，在所有的回收路径里面都能感受到优先级。另外一个特性是加速内存回收的功能，意思是离线任务需要回收它的内存的时候，在给离线发信号的时候会做它的调度类判断，去加速。从调度层面，让内存回收的流程和调度模块紧密结合，在回收的时候去提升进程的优先级，保证在指定的时间内一定能得到调度。得到调度以后，它回收内存的时间其实是跟分配内存的时间一样的，就可以预期它什么时候能够回收回来。第四个特性是内存分配限速，RUE 做了一个通用功能，可以限制指定 pod 的内存分配速度，从而让回收的时间能够更可控。第五个特性是做了 Latency QoS 功能，可以设置指定 pod 的内存分配延迟，如果超过

105、指定的阈值，会启动快速回收的流程，通过回收低优容器的内存来保障高优容器的 QoS 质量。最终达到的效果是通过牺牲离线业务的内存的可用性来保障高优容器的内存分配的延迟。效果来看，第一个是加速内存回收，可以保证在毫秒级的延时情况下就能回收回来。第二个是内存分配的延迟，可以保证在线高优业务的内存分配延迟始终保持在一个非常稳定的水准。51腾讯云技术实践精选集从腾讯内部的混部规模来看，已经覆盖了超过千万级别的 CPU 核，提供了百万级别的离线算力。样板集群可以做到 65%的 CPU 均值。Tencent OS 内核是经过多年演进，整体针对于云原生场景重新设计的内核。未来演进 全面拥抱 cgroups v

106、2。在内核层面做更强的、更全方位的隔离。Kubernetes offload Kernel，希望将 K8s 需要的一些云原生能力下沉到内核当中实现，让内核提供最完 整最强大的云原生能力，再结合腾讯上层的 K8s，整体上最大程度释放云原生的潜力。Quality Monitor，可以基于更精细化的指标做更精细化的运营。52腾讯云技术实践精选集云原生业务改造是云原生普及道路上的一大难关。很多传统业务迁移上云时都会遇到很多陷阱，如何应对这些坑和挑战是研发人员非常关心的问题。在 2021 年 ArchSummit 全球架构师峰会【上海站】，腾讯云高级工程师宋翔做了主题为腾讯百万级容器规模的云原生平台设计

107、与实践的分享，讲述了腾讯云团队帮助很多业务进行云原生改造过程中遇到的难题与解决经验。腾讯百万级容器规模的云原生平台设计与实践宋翔 腾讯云高级工程师负责腾讯超大规模自研业务上云的容器平台 TKEx 研发设计。将 Docker、Kubernetes、Istio 等云原生技术内部落地；支持腾讯 QQ、在线教育、腾讯会议等海量业务的云原生容器化改造。实践53腾讯云技术实践精选集今天，云原生容器化领域的现状有几方面的特征：首先，随着产品规模逐渐增大，单个集群节点可能达到上千甚至上万个，造成了单个集群的管理难度；第二是集群的数量特别多，而同一个业务可能分散在上百个不同的集群里，这些集群如何协同管理是一个非

108、常大的挑战；第三点，业务部署是一个混布场景，既有在线业务也有离线业务，有些业务有波峰、波谷特征，有些则长期平稳，或者存在机器学习、训练任务。平台上跑着各种各样的程序，负载和稳定性都会有一定制约。无状态的服务处理起来比较简单，业务改造成本较低，但有状态服务在发布上就会面临很多挑战。例如疫情期间，线上会议、视频、直播业务的发展非常迅速，它们的云原生改造过程中就发现了很多问题，类似的还有一些中间件服务如 DB、还有一些定制化的需求，都是一种有状态的服务。RUE：内存 QoS腾讯云从几个方面来改善有状态服务的管理：升级方式、升级效率、升级稳定性、灰度配置和异常节点处理。可以归纳出一个有状态服务发布平台

109、需要具备的基础能力：自动分批更新能力，不一定按照固定数量分批升级，也可能按照递增的百分比数量升级；升级的过程一定要可以随时暂停，是可控的。如果遇到失败率大到一定程度的情况，要有自动触发回滚的机制；在有状态升级的过程中要有时间间隔，不能像传统的升级过程只能滚动升级，上一个升级完再去发布下一个；固定 IP 能力。容器化现状有状态服务管理54腾讯云技术实践精选集有了基础能力，就要有一些高级能力进一步提高效率。原地升级能力：例如，分批发布只能在 Pod 升级层面做性能优化，但如果有固定原地升级能力，只需每次重启对应的 Pod 里的 Container 就可以实现它的升级，这在一定程度上又会减少升级的发

110、布时间。ConfigMaps 也要支持灰度升级。K8s 1.12 版本之后允许魔改 Api-server 和 Kubelet 的参数，实现原地升级的能力。腾讯云内部的一个有状态服务的发现，叫做 StatefulsetPlus，通过一个 Operator 实现了原地升级的能力。55腾讯云技术实践精选集在原地升级过程中是有一定缺陷的。Pod 里的镜像版本升级之后，升级的过程外部是无感知的，但实际上镜像容器的停止启动过程是有损的，所以腾讯云利用了叫做 readiness gate 的能力做了无损发布。每次替换里面的镜像版本时，都会先对它的 Condition 打上一个叫做 False 的标签，让外部

111、感知到这个容器的 Pod 处在再升级的阶段。此时系统剔除掉对应的后端服务的 IP，在升级成功之后再加回，这时 readiness gate 的 Condition 就会设置为 True，完成优雅的升级过程。56腾讯云技术实践精选集关于灰度配置：腾讯云把 ConfigMap 的升级抽象成了一个工作负载的升级。实际上每一个版本都是一个新的 ConfigMap，所以对 ConfigMap 的升级抽象成了一个工作负载，它挂载了 ConfigMap 名称的变化。最后是一些进阶功能的支持：第一，允许升级的过程失败。有状态服务在创建的过程中不一定百分之百会成功，比如预热一些资源的时候可能就会失败。最好允许这

112、种场景的发生，比如失败在一定的百分比内可以允许继续升级；第二，maxSurge/maxUnavailble。这是 deployment 概念，但在一些场景下有必要提供支持，例如业务的工作负载使用的 CPU 或者内存已经到了 70-80%，这个时候去做销毁重建的操作会让底层的后端服务更加异常，甚至有可能出现一些中断场景。所以可以通过 maxSurge，在升级的过程中预加载新扩容一批的 Pod 去做流量分发；第三，要删除指定序号的 Pod。有状态的服务是递增序列，但使用的过程中，有些场景下某一个 Pod 关联的有状态服务是异常的，重启也无法解决问题。这样就只能把这个序号删除掉，等待人为把相关的有状

113、态的关联服务启动成功之后再加回 Pod。下一个问题是升级过程中有可能出现中断。升级过程中中断会出现视频卡顿现象，所以腾讯云对最底层的 Endpoint 做了一定变更，实现了优雅剔除的能力。57腾讯云技术实践精选集在 Pod 的升级过程中，首先 Pod 到 Terminating 状态，再启动一个新的 Pod，把它变成一个新的版本，这个时候是在 Pending 状态，最后达到 Running 状态。但在 Pod Terminating 的时候，原生的 Kubernetes Endpoint 里会把这个节点剔除掉。剔除掉之后，上层的四层负载或者 Ingress 就无法探测到刚才升级的那个 Pod，

114、会做一个解绑操作。做解绑操作就会导致流量直接中断。所以腾讯云在升级的过程中，会判断 Pod 是否由于升级而发生 Terminating。如果是由于升级发生 Terminating，会把它的一些信息保存在 Endpoint Not ready address 列表里。这个时候上层的负载均衡器监听到了它的一些变化，会直接把它的流量权重降为零。这样新的流量不能再进来，但是已建立的链接还可以实时处理。等会议或直播结束之后再去做最终的 Pod 删除操作。即使是这样的情况下，也不能百分之百保证 Pod 删除是正常的，一般情况下需要有一个第三方来判断，实现了删除保护。比如，请求一个中台系统确认这个 Pod

115、是不是要删除、重建的操作，这里会有一个 Delete Validating 的 Webhook，支持一些协议，探测第三方的 Webserver，确定后端的服务是真正可以销毁掉、可以重建的，这种场景下才会进行重启操作。上述逻辑能够一定程度上保证优雅升级，但效率较低，在此基础上又做了平滑升级的支持。比如会议要开58腾讯云技术实践精选集24 个小时，Pod 只能在 24 个小时之内删除、重建，变成最新。常见的一些视频流是基于 UDP 协议，允许短时间的流量暂停。比如重启一下，做一个几毫秒的断线操作，对于用户来说就是突然有一点点小卡顿，通过一些方式可以在这个卡顿期间就完成升级。具体来说是有一个 Pod

116、，里面有三个基础元素。第一个叫做 sidecar，用来监听这个 Pod 现在是否处于要升级的阶段，以及这个阶段是否正常。后面还有两个 container，第一个 container 是 Pod 实际运行的时候要对外服务的 container，里面是真实的镜像版本，还有一个空的镜像做短暂的占位作用。当触发一个真正的升级过程时，Statefulset Operator 会对空的镜像 Patch 一个最新版本，例如 V2，之后空的镜像会做一些有状态的预热操作，等到它自身认为预热已经完成，要启动的时候，会在下方的 EmptyDir 目录里写一个文件，声明自己现在是一个最新版本，要准备启动了。这个时候

117、sidecar 会监听到，知道当前是有两个版本，一个是 V1，一个是 V2版本，且 V2版本已经准备好发布。它就会把自己的容器状态置为 False，让上层的 StatefulsetPlus Operator 感知到。在毫秒级升级过程中，第一个版本会被变成空镜像。这个时候 V2版本知道自己是最新的，且现在没有在运行的其它服务跟自己冲突，它就会立刻启动。通过这种方式可以实现毫秒级切换，用户侧感知不到掉帧，是一个平滑的升级。59腾讯云技术实践精选集产品配额调度下一个话题是产品配额调度。业务在每个季度或者每年都会有一定的预算配额。一个两个集群无法满足预算要求时，就会出现多集群、多地域、多产品之间配额和

118、实际集群容量做调度的问题。集群规模很大的情况下，产品可以动态分布在各个集群里面。这样可以根据业务情况和产品情况做配额调度。在上图的动态调度架构中有一个中间层，是一个 TKE，基于开源的 TKE Stack 实现。它其实是一个多集群管理工具，有点像联邦集群概念。在这个联邦集群的层面上做了联邦级的一些 API 和联邦级的动态调度器，负责各个集群里面的产品调配。每个集群里也有一个动态调度器，负责在这个小集群里的各个产品细分的调度，以及动态数据的上报和汇总。它还有一个 Validating Webhook，禁止异常情况下超过负荷的动态扩容。60腾讯云技术实践精选集负载与稳定性底层运维层更关注的问题是集

119、群的负载和稳定性。为了满足集群的拓展和伸缩需求，人们倾向于把集群做得非常大，但集群做大之后存在一些问题，就是业务对自己的容量评估是不合理的。比如，产品可能要消耗 10核心的资源，但申请的时候会申请 15 核心的资源，这样会存在资源浪费的情况。这种场景下，腾讯云有一系列的手段应对，比如 Pod 资源压缩、Node 超卖，HPA 动态扩缩容。HPA 上还集成了一些第三方的监控系统数据，基于这些数据去做扩缩容。还有 HNA 节点扩缩容，整个集群的负载达到非常接近上限水平的时候，会横向做节点的扩缩容。下一个手段是 VPA。它在实践中操作难度比较大，因为程序运行的过程中资源不足可以扩充，但很难缩资源，尤

120、其是内存资源。所以这里需要人工介入，在产品侧观察是否适合降配操作。最后，腾讯云还会根据一些业务的特点做预测和画像。上述手段本质上是压缩，它会导致集群不够健壮稳定。为提升集群稳定性，主要依赖三个手段。第一个叫做 DeSchduler，重调度器。第二个是动态调度器，负责优化资源的调度。第三个是 NPD。重调度的概念很简单，就是动态发现节点上的资源是否分配合理。负载很高的节点可以触发调度策略，把它调度到其它的节点上。61腾讯云技术实践精选集动态调度器可以帮助 K8s 实现更细化的调度。它会基于一些加权指标，判断服务 Pod 是不是真正可以调度到这个节点上。这里还有一个问题是 K8s 原生是基于 Re

121、quest 做调度，可能比实际使用量高很多。所以这里会根据计算好的真实利用率去做动态调度。NPD 节点探测有几十条各种各样的检测指标。对于常见的一些指标会做自动修复和自愈工作，还有一些指标会做人工审核。另一种指标用作审计用途，会统计出来交给专门团队分析。这里还可以自定义插件，针对不同平台自定义探测和恢复策略。62腾讯云技术实践精选集展望腾讯云的集群原来是基于 Kubernetes，现在慢慢切到 EKS 集群。EKS 是无服务节点集群，运维层面看不到底层的 Node 节点，实际上底层是一个无限大的资源池，这样就没有了管理 Node 节点的概念。底层运行时，原来使用 dockerd，后来换用 co

122、ntainerd，还尝试用 Kata 运行时做更好的隔离。最后腾讯云还是结合了轻量级虚拟机 CXM，使用 EKS 产品，解决 containerd 中遇到的问题。它的隔离性、稳定性会比 dockerd 更强。而且自研优化让启动时间非常短。腾讯云后端的集群非常多，但希望业务层面做到无感知。所以腾讯云在通过 EKS with VK 的形式把一些传统的 Kubernetes 集群以 VK 节点的形式加入到 EKS 集群里，而对于运维层面、上一层接口调用层面来看，它就是一个很大的集群。腾讯云在 Operator 层面做了一些集群间的调度，对用户做到了无感知。腾讯云还在探索服务网格，做了一个全托管的服务

123、网格，独立于 K8s 集群。它可以从外部连接到各个 Kubernetes 集群，去做流量控制、自愈、故障注入等操作。但这个网格的旧服务迁移成本较高，性能也存在不足，所以腾讯云也在努力改进。63腾讯云技术实践精选集不同企业上云后，其成本节省程度是不一的。从 IT 资源成本节省量来看，低的企业不到 10%，高的企业可达 60%-70%。究竟为何会造成这么大的差异？又有什么组织管理手段和产品技术手段可以降低企业上云成本？在 2021 年 QCon 全球软件开发大会【北京站】中，腾讯云专家工程师于广游发表了1000+企业云原生改造成本优化总结的主题演讲，介绍了腾讯云云原生团队，通过大范围的客户调研和访

124、谈，解答了企业如何借助云原生进行更深层次的成本优化，以及腾讯内部和腾讯容器服务客户在容器化过程中进行成本优化的最佳实践。1000+企业云原生改造成本优化总结于广游 腾讯云专家工程师，腾讯云容器技术总监主导了腾讯云容器产品从 0 开始的设计、研发和运营工作，并在腾讯云海量 Kubernetes 集群的治理和落地过程中积累了大量的经验。腾讯自研业务全面云原生上云的主要参与者之一，在云原生领域有丰富的实践和思考。目前致力于 Kubernetes 在成本节省、Serverless、混合云等场景的探索。64腾讯云技术实践精选集企业 IT 资源成本优化的理想与现状“从我加入腾讯以来，主要做了两件事情：第一

125、件事情是主导了腾讯云容器产品从 0 开始的设计、研发和运营工作，第二件事情是把腾讯内部的全部自研业务上云。”在 2017 年时，我们经常跟客户讲容器和云原生的优势，客户会问它到底有什么好处，能降低多少成本？为此，我们与腾讯内外部的客户进行了多次访谈，最后通过数据分析，得出了云原生、容器跟资源利用率之间的关系。大家应该知道，把 IDC 中的设备和业务搬到云上，在架构不变的情况下，资源利用率肯定不会提升。事实上，我们的调研数据跟预期是一致的，将业务从 IDC 搬到公共云，它的资源利用率平均值一般还是低于 10%。在 TKE 中，70%客户的平均资源利用率低于 20%；40%客户的资源利用率只有不到

126、 10%。也就是说，把业务从 IDC 搬到云上，资源利用率没有提升；接着，把业务容器化以后，资源利用率竟然还是没有提升多少，这是一件非常奇怪的事情。因此，我们针对以下三类客户，进行了一次更深层次的分析：第一类：业务有波峰、波谷，但是波峰其实不高，波谷更低；第二类：全天的资源利用率都非常低，一直不到 10%；第三类：晚上会跑一些离线的计算业务，这类客户资源利用率稍微高一点，但平常也不高。65腾讯云技术实践精选集我们总结了资源利用率低的两大类原因：没有进行业务容器化的企业，这类型企业的业务没有应用的编排调度管理工具，资源以整机的形式交付，使得业务间无法进行有效隔离，只能被迫把设备交给业务。不同业务

127、独占资源池，资源碎片的现象会比较严重；企业已经将业务容器化了，但资源利用率依旧较低，这类企业本质原因是并没有云原生化，展开讲就是业务微服务改造不彻底，没有用云原生的方式运行业务；还有云原生的弹性伸缩能力本身不够成熟，导致业务架构无法弹性伸缩、扩容不及时，且云上资源存在售罄的可能性，因此业务需要提前冗余地占用较多资源量。举个例子，假设一家公司在云上共有 1 万核，资源利用率每提高 10%，每年就能省 100 万，如果能从 10%提升到 40%左右，企业一年其实能省几百万，想必没有企业会拒绝如此大的成本优化吧？为此，我们又进行了一个调研，总结出了企业资源利用率优化失败的典型模式，我们称它为四步失败

128、法。在第一阶段中，公司业务高速发展，老板告诉 IT 团队要全力保障业务发展，要多少机器给多少机器，业务就能够随便用，但是资源利用率非常低。第二阶段是公司业务发展没那么快，老板一声令下让 IT 团队优化成本，但由于业务下降，团队都在寻求新的增长点，所以依旧没有精力进行成本优化。在这种情况下，无论是业务还是平台，大家都开始在百忙之中建设资源运营平台、弹性平台，推动业务团队改造。到了第三阶段，某天业务突发了线上故障，企业内部就会组织一场复盘大会，业务团队复盘认为是 IT 团队推动成本优化，架构冗余减少，挤占研发人力造成的；而 IT 团队则认为是业务技术能力差，提出不合理接入需求、团队人力少所导致的。

129、最终在一次次的博弈中，成本优化就无疾而终了，进而走向了第四个阶段，业务与 IT 团队关系极度恶化，所有团队都觉得成本优化是件吃力不讨好的事情。企业 IT 资源成本优化关键路径根据上述提到的企业成本优化的失败路径，我们发现成本优化其实是由三对本质矛盾组成的，且这三对矛盾不可调和。1266腾讯云技术实践精选集第一对是业务稳定性跟资源利用率间的矛盾，很多业务没有人维护，其稳定性全靠冗余来支撑，而冗余天然跟资源利用率就是一个互斥的话题，没有冗余，业务的稳定性就会降低；第二对是业务投入与技术投入的矛盾，假设部门只有一个 hire count，到底应该去做业务，还是去把架构搞得可弹性，这其实也是一个不可调

130、和的矛盾；第三对是企业内不同角色/组织的矛盾，不同团队由于各自目标，最终演化成了业务团队与资源团队之间的矛盾。虽然这些矛盾是本质性的，无法完全解决，但企业可以通过技术手段和组织手段减少这些矛盾。组织手段可以分为两个方面：一方面可以通过奖励进行驱动，拿腾讯举例，只要能够观测到每个业务真实的成本和资源利用率，接下来也不需要强制做什么，只需要挂一个红黑榜，给资源利用率前十名的团队奖励，请排名后三位的团队回复邮件，解释说明资源利用率低的原因。另一方面，企业还可以设置一些增强手段建立成本文化，这是刚刚兴起的一个名词叫 FinOps，意思是代码设计之初就需要考虑冗余和架构，企业要监控性能、稳定性等数据的指

131、标。它让每个团队都可以像监控业务可用性一样监控业务成本，像优化业务可用性一样去持续优化成本。此外，组织手段虽然可以使不同团队目标对齐、促进协作，但关键难点还在于技术复杂度的处理，没有技术投入和技术实力，成本优化就是无休止的扯皮和甩锅。实际上，资源利用率提升的本质是消除浪费，一种方式是推动业务按需使用，即为弹性伸缩，用多少申请多少，不用就把它缩下去；第二种是业务不用动，平台方进行资源腾挪复用，即为在离线混部。这两种方式分别有不同适用的场景：1.弹性伸缩弹性伸缩是根据实际负载，对业务和资源进行横向和纵向的动态调整，它的核心是业务资源的按需使用，一般资源池大小是动态的。所以它有两个限制条件，一是纯

132、IDC 环境效果有限，缩容的资源依旧空闲；另外是业务方需要进行微服务化改造，无法无痛接入。目前，腾讯云已经在这方面做了一系列工作，并且主要围绕及时性、灵活性、可用性做了优化。其中，及时性支持基于预测的提前扩缩容，基于 Buff 的节点预扩容，基于配置扩容等等；灵活性是从业务层载体的扩缩容算法、支持多种指标扩缩容；可用性则能够动态感知资源售罄，智能调整扩容策略，提高扩容成功率；在大数据方面，腾讯云基于 Yarn Operator 和存算分离实现了大数据等业务的弹性扩缩容。67腾讯云技术实践精选集那弹性该怎么落地呢？腾讯内部推出了一个云原生弹性成熟度模型，用来监控业务组件在过去一周中是否发生过伸缩

133、。如果监测到从来没有发生过伸缩业务，就让它能够伸缩，有这个能力之后，再去推动弹性改造，最终，通过这种方式资源利用率提升了 30%-40%。2.在离线混部在离线混部的本质是将分配给应用，但应用实际未使用的资源，再动态分配给其他应用，其核心是资源的腾挪、再利用，一般资源池大小是固定的。它的优势非常明显，业务几乎不需要做过多的改造，且平台可后台对资源进行灵活腾挪和复用。但是它同样也是有限制的，首先，总资源池大小固定，无法应对流量突发的场景；其次，需要有离线业务能够填补在线低峰。在腾讯云的在离线混部实践中，提出了如意 RUE 的解决方案，它能够让机器分别部署高优业务和低优业务，当高优业务起来的一瞬间，

134、能够对低优业务进行绝对的压制，并且对在线业务零干扰。最终，能够使资源利用率提升 60%-70%。前面提到的两种方案都有各自的优缺点，所以最好的方式就是互补，在离线混部+弹性伸缩才是提升 IT 资源利用率的绝佳组合。68腾讯云技术实践精选集腾讯云原生内外客户成本优化实践在 2020 年时，有一个腾讯云的外部客户对整个在线业务进行了容器化改造，他们也是非常惊讶地发现，容器化改造之后，资源利用率的提升是有限的，所以就希望在 2021 年进一步提升。显而易见，这家公司内部已经将全部业务进行弹性化改造了，另外，他们业务的波峰、波谷非常明显，而且离线业务非常大，以至于离线业务跑起来的时候，在线业务的池子是

135、不够用的，所以腾讯云为他提供了混部+弹性的方案。客户的集群本身部署了在离线混部的特性，同时腾讯云又给他们提供了一个大数据的容器化方案，使其现有的大数据系统不用做任何改造，只需部署一个组件，就能够把大数据系统的 Job 任务运行在 K8s 集群中。客户进行了非常稳健的内部推广，前期只在业界把离线业务往在线业务平台上发布，但整个实施过程其实非常简单，因为绝对压制的 OS 内核能力，使其并没有用太多的调度能力。此外，TKE 可以在一个集群中插入虚拟的 Node，正常情况下插入一个真实的节点，用户需要创建一个容器。当创建虚拟动作时，最终会到腾讯云的资源大池中创建一个轻量的虚拟化 Pod。在这种情况下，

136、就完成了在线和离线的统一。最终，通过优化资源碎片、在离线混合部署、自动扩缩容，这家企业的整体计算成本下降了43%。69腾讯云技术实践精选集总结演讲最后，于广游对成本优化的关键点进行了总结，他提到，仅把设备搬到云上，资源利用率是无法提升的，企业会惊讶地发现他们把业务容器化以后，资源利用率的提升竟然也是有限的。当企业去实施成本优化方案时，对其自身企业的技术实力和管理能力，又是一个真正的大考核，但这个大考也是有答案的，那就是 TKE，云原生能够把握效率和成本的平衡点。最后再介绍下腾讯内部自研上云混部的实践，游戏、金融、社交等 6 个腾讯 BG，每一个业务的技术栈都是不一样的，所以进行混部优化的过程非

137、常艰难，但腾讯公司内部还是通过自上而下的支持，进行了全面云原生的改造，把全部的增量业务全部放在 TKE 进行，存量业务逐渐往 TKE 迁移，共用 TKE 这样的调度系统进行混部。最终，平均资源利用率达到了 46.5%，样板集群资源利用率达 65%。70腾讯云技术实践精选集K8s（Kubernetes）应用对运维所关注的弹性、稳定性和性能等方面都起到了很大的作用，对运维人员来说，它达到了降本增效的作用；但对 Node、Java 等后端开发人员来说，K8s 应用却给他们带来了诸多困扰。这个矛盾看似不可调和，但开发工作还是要做，代码也还是要写，能不能找到一套云原生的组合拳来解决开发人员所面临的困扰呢

138、？在2021年 QCon 全球软件开发大会【北京站】中，来自腾讯云 CODING 的研发总监王振威带来了主题为 破解 Kubernetes 应用开发低效之困：一键调试，实时热加载的演讲，分享了腾讯云在解决这一问题的思考和实践。破解 Kubernetes 应用开发低效之困：一键调试，实时热加载王振威 腾讯云 CODING 研发总监深耕开发者工具领域，CODING 代码托管、CI/CD 等产品的从 0 到1 的牵头人。云原生开发环境 Nocalhost 产品负责人。71腾讯云技术实践精选集K8s，运维之糖，开发之伤在演讲中，王振威总结了这样一句话：K8s，运维之糖，开发之伤。为什么这样说？在 CN

139、CF 2020 年的毕业项目以及进入孵化的项目中，没有一个是与开发效率、开发体验直接相关的，几乎全部是站在运维角度，从业务稳定性、资源调度、架构性能、流程规则等方面的；在 CNCF Sandbox 的众多项目中，也仅仅只有四款与开发过程有关。为了解决 K8s 给开发人员带来的困扰，首先要了解开发效率为什么会降低？这要从以前写代码与现在写 K8s 应用代码的对比来看。以前写代码非常简单，写完代码编译成一个程序，程序启动后变成一个进程，之后对这个进程进行一些输入操作，再看它的输出。这是最简单也是最原始的一个做法。72腾讯云技术实践精选集随着容器化浪潮的席卷，我们一步步地把这一过程进行封装、进行解耦

140、化、用松耦合系统做成封装套娃。第一层，为了解决运行时一致性问题和交付问题，在进程外，套了一些基础运行时（Runtime），变成了容器。比如，原来是个 jar 包，现在把 JVM 套进来之后就叫容器，但是容器也会挂掉，而且容器与容器之间有协作，所以又要把多个容器套到一个 Pod 里，再配上基础网络和存储。作为 K8s 的最小调度单元，光 Pod 还不够，多个 Pod 可以形成工作负载（Workload），可以用 HPA 来控制这些负载的横向扩缩容。但工作负载还是不够，工作负载之间的调用关系我们希望与业务容器解耦，因此又需要在工作负载内部的 Pod 里加入 Sidecar，尝试用 Sidecar

141、来解耦服务与服务之间的注册、发现流量调度等问题，这也是 Mesh 的一个核心能力。再往上，因为不同的服务可能有不同的版本、不同的作用域、不同的优先级，于是又把服务套成了 Service，最后多个 Service 套成了一个应用，形成了云原生的终极封装套娃。这一过程对开发人员来说是非常复杂的，因为开发人员关注的只有最核心的，容器最里面的Process（进程）。开发人员之困当然，封装套娃带来的优势是显而易见的，例如松耦合、容错性以及易于管理等等，但对开发人员的困扰也很大，主要体现在以下几个方面：首先是要学习的东西变多了，其次是根本没办法搭建出一套环境，像 CODING 团队中规模较大的应用有 20

142、0 个微服务，几乎没有人能够把这个环境搭建起来。如果要老手搭建起来，至少也需要两周的时间；173腾讯云技术实践精选集以前的代码是实时热加载的，只需要在 IDE 里点一下 Debug 或点一下 Rerun，就可以刷新页面了。但现在，整个写代码的过程就变成了：修改代码 推到仓库 触发 CI 编译 打包成镜像 镜像仓库 由 CD 系统或运维人员把它更新到集群中，当集群中的容器探针检查通过服务上线之后，再发一个请求调用看看，才知道结果。这时候如果发现少改了一个字母，这时就要再重来一遍，整个人都崩溃了。大多数团队整个过程至少要 10 分钟，有些团队自动化程度好一些，也要 5 分钟。即使能够把所有的配置和

143、镜像都准备好，本地电脑或者办公室的测试机也没有足够的资源把它运行起来，这也是需要面对的一个现实问题。因为我们知道，云的天然特性是它的资源可弹性提供，所以最好的解决方案就是把环境搬到云上，由云来提供最终的支持；即使能够把 200 个微服务的环境搭建起来，也有足够的资源来运行它，但如果要写一段代码并要看其运行的结果，你会发现这一过程慢得令人发指。因为不得不进行如下图所示的一套流程。23在代码和 Kubernetes 之间搭建一座桥梁要怎么做才能真正地提升开发过程中的编程效率呢？CODING 团队提出了这样的观点：在代码和 K8s 集群之间搭建一座桥梁，让代码直达 K8s 核心，而不经过一系列流程和

144、工具。首先，第一步必须要解决环境问题，因为很多团队对环境没有弹性的理解，都是由公司内部的不同团队来维护几套固定的环境。比如，测试环境一、测试环境二。但事实上，这些环境都是需要独占的，环境数量有限，当别人用的时候你就不能用。74腾讯云技术实践精选集而理想效果是不需要人去维护环境，只用代码把环境定义好。比如 K8s 的应用，用 Helm 或 Kustomize 把环境定义好，需要用的时候去部署一套，做成按需的。与在云上买一台虚拟机的道理一样，需要的时候买一台就可以了。开发环境和测试环境也一样，需要的时候直接云上部署出来即可。除此之外，如果开发环境、测试环境与正式环境使用了一致性的定义手段，在云上运

145、行时，就可以最大程度地减少在开发和测试阶段中，因环境问题带来的不可预期的影响。其次，我们能不能利用一种手段，把最核心的进程直接暴露给开发人员？在生产容器中，只有进程本身的 Binary 和进程的基础运行时。以 Java 为例，这个进程可能是一个 jar 包启动起来的，基础运行时就是一个 JVM 的解释器，但在这样的环境里开发其实不太容易，于是便有了一个这样的设想：在开发或调试阶段，就把生产容器变成开发模式。变成开发模式之后，容器里全套 SDK 的工具链，可以直接使用源码启动进程。以 Java 为例，可以在开发容器里装 Maven、JDK 以及各种抓包工具、curl 调试工具，甚至还可以将源代码

146、传输到这个容器里，就可以随时控制主进程的启停，最终实现与本地开发一样的效果。75腾讯云技术实践精选集通过这种方式，云原生的低效开发模式变成了一个极简的开发模式，改完代码之后，启动刷新页面看效果，不对再修改，对了就提交，这是开发人员非常想要的一种体验。想要达到这种效果，首先是环境必须到位，环境应该由云来提供，这样可以最大程度地减少开发人员和基础架构部门的负担。想象在一个场景中，测试人员测出了一个问题，但开发人员在他的环境里却很难重现。如果环境是按需的，测试人员测完之后直接可以把环境交给开发人员去调试，开发人员调查完毕，再把这个环境销毁掉。以前，我们仅仅用到了云的基础计算能力，如弹性能力、计算控制

147、、权限控制等等，那么能不能让云更进一步，把基础的监控、CI/CD、制品管理、源码管理、服务网格、日志管理、分布式追踪等能力都交给云？事实上，现在腾讯云的容器团队已经提供了比较完善的基础能力，包括日志管理、追踪等等，所以对腾讯内部的业务团队来讲，不需要太关注这些点，直接使用即可得到一个按需、规范的环境。CODING 团队开源的一款软件 Nocalhost，可以方便地调试远端进程中的代码，直接与本地打通。通过 Kubernetes、HELM、Nocalhost、Istio、Prometheus 等八个组件，让不同的人用不同的环境来做自己对应的工作，是开发人员就做开发，是测试人员就做测试，由云来提供

148、基础的监控、日志、跟踪等等。76腾讯云技术实践精选集CODING 团队的实践CODING 团队在云上用了一个巨大的集群来支持开发和测试的环境。在这个集群里，我们实现了所有人都可以拥有具备 200 个微服务的开发环境，而它又非常节省资源，并不是所有开发都在同时运行程序，所以有相当大的“腾挪空间”。同时，这个集群的资源利用率也有了很大的提升。对于企业内部来说，利用云的资源其实变相节省了公司内部的开发电脑，或是内部的服务器、IDC 机房等等，同时还解决了开发效率的问题，最终得到了一个降本增效的综合结果。目前，CODING 团队在云上稳定运行着大概 120 个不同类型的环境，并且这个环境是按需的，CO

149、DING 团队的理念和实践是测试人员可以在 CI 流程里随时构筑一个新环境，跑完自动化的测试后，再把环境销毁掉，开发人员可以为一个新需求快速构筑一个新环境，开发自测验证完毕后销毁掉。总结要解决 K8s 应用带给开发的困扰，需要做到以下几点：必须要用代码来定义环境，实现自动化部署，不是维护环境，而是要定义它；环境跟环境之间应该形成隔离，能够让不同的测试场景、开发不会相互干扰，他们可以沉浸式地在一个环境中去体验、去观察自己代码的运行效果；要合理地利用云提供的各种各样的基础设施，进而为团队赋能；环境准备好以后，必须能够支持所有人可进行便利化的调试和开发。123477腾讯云技术实践精选集随着云原生技术

150、的逐步推广，越来越多业务开始使用云原生容器化的方式构建自己的应用。Kubernetes 作为云原生容器调度平台成为了行业的一致选择，基于 Kubernetes 还衍生出了 Serverless、边缘计算、Mesh 平台等一系列云原生平台解决方案。在 2021 年 ArchSummit 全球架构师峰会【深圳站】上，腾讯云 TKE 稳定性负责人唐聪发表了题为腾讯大规模云原生平台稳定性实践的演讲，介绍腾讯在构建大规模云原生平台过程中提升 Kubernetes 集群稳定性的实践经验。腾讯大规模云原生平台稳定性实践唐聪 腾讯云 TKE 稳定性负责人腾讯云 TKE 稳定性负责人，腾讯云技术专家，极客时间专

151、栏etcd 实战课作者，业界首个 etcd 一站式治理平台开源项目 kstone 创始人及维护者，etcd 活跃贡献者，KubeCon、ArchSummit、Gopher 讲师，主要负责腾讯云大规模 etcd 平台、大规模kubernetes 集群的成本和可用性优化、有状态服务容器化等产品研发设计工作。78腾讯云技术实践精选集kubernetes 故障案例分析与最佳实践首先从典型故障案例说起，为什么 Kubernetes 稳定性不可忽视呢？下图给大家列举了三个典型场景的 Kubernetes 故障：master 核心组件组件，Kube-apiserver/etcd 组件因大量 List 等 e

152、xpensive request 导致集群雪崩，这类故障轻则无法发布，重则影响业务数据面；集群 addon 组件故障，如核心的 HPA 组件等。当面对突发流量时，如果 HPA 服务遭遇故障，无法及时扩容则也会导致严重的服务可用性故障；业务自行开发的 operator 引起的故障。各业务在云原生过程中，会结合业务领域知识、编写 operator 来适配自己的业务场景，而 operator 核心工作机制是根据实际状态与期望状态进行比较，并采取一致性协调动作使它们趋于一致。然而某业务 operator 依赖方变更，返回数据异常，operator 在快速进行一致性协调过程中，删除了某类 Kuberne

153、tes 资源，导致业务异常。79腾讯云技术实践精选集了解了 Kubernetes 稳定性的重要性之后，那我们又该如何保障 Kubernetes 的稳定性呢？从 Kubernetes 架构我们知道，master核心是 Kube-apiserver 和 etcd,因此可以从 Kube-apiserver 出发，结合 Kube-apiserver 原理和大规模实践，我将典型的故障场景总结下图中的六大类。针对这六大故障场景，我又从八大方面总结一系列故障预防和最佳实践手段，如下图所示，因时间有限，无法深入每条实践细讲，这里重点分享下为什么需要避免大量指定 label get 或 List 操作查询等。8

154、0腾讯云技术实践精选集Kube-apiserver 如何执行查询 get/list 等资源的请求Kube-apiserver在启动的时候会加载一系列处理链，收到请求之后，会通过鉴权模块判断用户身份是否合法，审计模块会记录用户的详细行为，限速模块对请求进行限速，通过授权模块判断用户是否有权限来操作对应的资源。Kube-apiserver 还通过准入机制，提供在访问资源前的动态扩展能力、拦截能力。通过一系列模块之后，请求会进入匹配资源的 handler 里，最后进入通用的 etcd 的存储模块。进行 List 查询时，如果查询的请求里指定了 meta.Name，就通过 etcd 单 key 查询返

155、回来，否则就是范围查询，根据 Lablel、FieldSelector 做过滤。关于 etcd 的存储格式，因为 etcd 是 KV 存储，所以它的存储格式是由对应的资源类型加 Namespace 再加对应的资源名组成的。在 etcd 中没有存储 Kubernetes Label、FieldSelector 这种字段 key，所以当通过标签查询的时候，最后都是在 Kube-apiserver 做过滤。Kube-apiserver 向 etcd 发起 Get 请求后，那 etcd 又是怎样工作的呢?81腾讯云技术实践精选集Kubernetes 如何从 etcd 查询数据 etcd gRPC kV

156、 Server 收到请求后，进入 KV 模块的 Range 接口。etcd 3.1 版本后线性读实现是 readIndex 机制，需要从 leader 获取最新已提交的日志索引号（commitedIndex）；等待本节点已经应用到状态机的最高索引号大于等于 leader 返回的 commitedindex 后才能允许读；从索引树中获取 key 对应的最新版本号；然后再优先从 cache 中获取，若未命中则从 boltdb 获取。etcd 常见故障也可以分为八大类：为发现潜在的 etcd 隐患，腾讯云引入了多维度的集群巡检，其核心目标就是尽早发现 etcd 集群隐患因素，比如针对大集群、大资源数

157、量、超多的 CRD 等对象数量、频繁读写 QPS、数据不一致等可能搞坏 etcd 集群的场景设计了对应的巡检策略。此外腾讯云还从架构设计、etcd 稳定性优化，etcd 性能优化、测试变更管理等角度做了全方位的优化。接下来就重点介绍腾讯云大规模 etcd 集群治理经验，还有腾讯云推出的业界首个 etcd 一站式治理平台开源项目 kstone(https:/ etcd 集群治理腾讯云对外提供的 TKE、EKS、Mesh 目前有上百万的开发者和企业用户使用，他们在腾讯云上产生了大量全托管的 kubernetes 集群。同时腾讯云也是国内第一家对外提供 etcd 产品化服务的，其对内支撑了腾讯数百个

158、业务。正是因为基于 Kubernetes 和非 Kubernetes 产品大量的业务诉求，腾讯云有超大规模的 etcd 集群需要治理。治理实践可以从运维和内核两个角度展开。运维角度，腾讯云需要一套全自动化的集群管理系统，能快速完成集群的增删改查。其次是一套非常强大的监控系统，覆盖线上数以万计的 etcd 集群。再次需要实现一套集群巡检系统来发现集群隐患，以提高整个集群的稳定性。然后 etcd 存储系统的数据的备份至关重要，需要一套分钟级的冷备和实时的跨城热备能力。最后作为云厂商，迁移永远是必备的能力，无论是从自建迁移到云上 etcd,还是 Kubernetes 资源数据拆分等业务场景，都依赖迁

159、移能力。内核角度，在使用 etcd 过程中你可能会遇到各类 etcd 故障，腾讯云团队在 etcd 内核方面，修复了 etcd 数据不一致、内存泄露、死锁、panic 等众多问题，提升了 etcd 在大规模数据场景下的启动、读性能等。除了这些社区已知的 bug 之外，腾讯云还需要从 0 到 1 开发基于 etcd QoS 的限速能力、基于跨城容灾的同步能力。为了满足我们以上治理诉求，腾讯云期望的 etcd 平台需要满足以下设计目标：扩展性。支持管理多种业务场景等 etcd 集群，支持多种迁移算法，支持多种调度策略，巡检策略可插件化；高可用。具备 etcd 高可用部署，etcd 垂直及水平扩容，

160、etcd 稳定性优化、跨城复制、qos 特性，etcd 混沌工程测试等；高效运维及自愈。支持一致性、健康度、大对象及异常 QPS 巡检，分级数据备份及恢复机制，etcd 节点故障自愈、自动扩容、数据迁移；可观测性。集群管理可视化、集群 SLO 可视化、集群迁移可视化、etcd 数据可视化。有了这些设计目标之后，腾讯云团队从开发效率、可观测性和可运维性出发来做方案选型。其中最看重的是83腾讯云技术实践精选集可运维性和自动化，这跟 Kubernetes 的扩展机制不谋而合。Kubernetes 提供了 operator 机制，可以非常方便地基于业务运维的领域知识去扩展开发。但 Kubernetes

161、 扩展机制又提供两种选项，一种是 CRD、一种是 Aggeregated API，对内腾讯云数据规模特别大使用了 Aggeregated API 机制，对外开源的 kstone，使用 CRD 来方便用户快速简单部署。上面是 kstone 的整体架构。核心组件有两个，第一个是 kstone-etcdcluster-controller，可以支持多种 cluster provider，还可以支持存量 etcd 集群可视化管理，我们内置了 kstone-etcd-operator 实现，基于它可实现 etcd 集群的高可用容器化部署。同时，kstone-etcdcluster-controller

162、还提供了一系列可扩展的特性支持，如巡检、监控、备份、迁移、智能诊断。第二个核心组件是 kstone-inspection-controller，它是巡检任务的真正执行者，目前实现了集群一致性、资源对象数、大 key、健康度、热点写请求、alarm 告警、备份是否成功等策略的巡检。整个 kstone 平台支持一键开启监控、备份等所有特性，用户还可通过可视化的 etcd 管理平台查看 84腾讯云技术实践精选集Kubernetes 中的数据在 etcd 中的存储格式。同时基于 operator 自动化集群管理，用户通过可视化平台可以轻松实现集群的创建、扩缩容、统一纳管等。与人工部署的旧方法相比效率是

163、提升百倍，同时大大减少犯错的几率。kstone 平台核心的 CRD 是 EtcdCluster，描述了整个集群的集群规格、大小、内存、SSD 等。正如前面缩描述的，kstone 支持多种 cluster provider。这个 EtcdCluster CRD 是平台型的，后端可以对接开源的 etcd operator，也可以对接内置的 Kstone operator。这个 CRD 也可以描述存量的 etcd 集群，把它导入整个平台。新建或者导入 etcd 集群之后，可以通过它的 Status 看到整个集群的状态信息，比如各个节点的端口、角色、状态、版本号、各个特性开关的开启状态等等。Kston

164、e 平台的第二个核心是 CRD EtcdInspection 巡检资源，每新增一个巡检特性就会生成对应的巡检CRD。当开启巡检后，用户就可以巡检视图面板，看到集群里各个巡检特性生成的 metrics 等内容，方便定位问题。85腾讯云技术实践精选集Kstone 平台的迁移任务实现是通过 EtcdMigration CRD 来实现的。此 CRD 描述了迁移的源集群、目的集群信息，同时实现了支持多种算法的 Provider，最重要的是它还支持多种数据一致性的检测策略。通过多维度数据一致性，应用层和 etcd 层会做 double check 来保证数据的万无一失。最后，针对 Kubernetes 场

165、景迁移 etcd 导致的 client list-watch hang 住问题（迁移后的 etcd 版本号 Kube-apiserver resource version 小于原有 etcd)，我们修改了 Kubernetes 版本源码，增加 watch 操作的 timeout 机制。Kstone 备份方面分为冷备和热备。冷备方面，kstone平台基于社区开源的 etcd-backup operator 扩展开发，支持分钟级的备份到 COS 等对象存储。热备有几种方案，比如可以基于 etcd 本身的跨城部署。它的缺点非常明显，当几个节点在不同城市，任何读写请求都需要涉及到两城网络访问，所以读写

166、性能会非常差，但优点就是部署运维都非常简单。另一个方案是社区提供的 make-mirror，核心原理就是同步服务。它在启动的时候会从原 etcd 把所有数据从 get 接口读出来，再获取版本号，通过 Watch 指定对应的版本号，并监听源集群后续新增的事件，如果有新的事件就会同步给目的集群。它核心的最大缺陷是无法保证数据一致性，还缺少数据性一致性检测、日志、Metrics 等一系列特性，不具备生产环节可用的标准。第三个方案是 etcd 自带的 learner，优点也是部署非常简单，无需维护额外的组件。它也可以同步任意类型数据。它最大的缺点是当主机故障之后，没法快速将 learner 马上提升成

167、独立可写 etcd 集群，同时它依赖高版本的 etcd。方案四和方案五腾讯云自研的。方案四是 mirror-plus 版本，针对 make-mirror 做了一系列特性加强，比86腾讯云技术实践精选集如支持断点续存、全量同步，这样不用再担忧专线、公网抖动。最重要的是它自带了多种一致性检测，像存量检测、快照检测，可以实时看到哪些数据可能是不一致的。有了这一系列机制之后，即便原集群出现了中断，也可以通过监控系统看到当前差异量多大，能否做多活切换等等。方案五的原理和 learner 类似。etcd 同步服务会伪装成 learner 的角色加入原集群，解析 Raft 日志条目，从 Raft 日志条目解

168、析对应的读写请求，再转发给目的集群。方案五缺点就是需要一定的开发时间。也需要对 etcd 有足够的了解。为提升稳定性，腾讯云 etcd 还实现了一个核心的特性是 etcd QoS。它主要由两大模块组成，一个是 qos class，描述整个集群有哪些限速器，比如它支持 TokenBucketFilter，也支持 LeakyBucketFilter。用户可以通过简单命令加限速器名称，指定对应的限速器类型。第二个是 QoSRule。这个模块可以指定限速对象、请求的 key、请求的操作类型、db 使用率、请求扫描的 key 数等，在 Kubernetes event 等场景可以显著提升集群稳定性。Ku

169、bernetes master 组件治理介绍完腾讯云 etcd 实践后，再从整体介绍下腾讯云 Kubernetes master 组件治理实践。腾讯云有两种集群管理模式，一种是托管集群，它的 Kube-apiserver、etcd 组件全都是部署在腾讯云自己87腾讯云技术实践精选集的 VPC 下，不需要用户管理，适合于中小型客户。第二种是独立集群，Kube-apiserver、etcd 都在用户自己的 VPC 下。Kubernetes master 组件治理有三类难点：如何通过一套系统来管理数万集群的创建问题；如何实现按需扩缩容，实现成本与高可用的平衡；如何简化运维复杂度，高效运维。针对大规模

170、集群组件的管理问题，腾讯云借鉴了 Kubernetes 本身的思想。既然 Kubernetes 提供了完善发布、自动扩收容和监控能力，完全可以用 Kubernetes 自己来管理 Kubernetes 组件。腾讯云利用 Kubernetes CRD 编写了 master-operator 组件，创建对应的 Kube-apiserver、控制器、调度器，通过声明式 API 帮助解决了一致性的问题。在这种场景中，控制面集群叫 MetaCluster，它会占用一个 namespace。这里有三个核心的控制面主线，第一是 master-operator，负责几个控制面组件的创建；第二个是 tke-op

171、erator，负责一系列 add-on 组件创建；第三个是 autopilot-operator，负责集群的自动扩缩容、节点安全下线等自动化运维操作。这里每个集群都会占一个 namespace，用户集群的 kube-apiserver 控制器都会以 deployment 形式部署在里面。针对高可用和成本优化问题，腾讯云做了画像服务，它的架构如上图所示。它主要有两个组件，第一个88腾讯云技术实践精选集是 workload-controller，负责 deployment、statefulset 等负载类型的画像 CRD 生成。第二个组件是 workload-recommender，基于 VPA

172、扩展开发，它支持多种推荐算法，并且各个 workload 可以支持使用指定的算法。有了它就可以获取各个组件的真实使用率情况。除了画像服务，腾讯云还实现了上图中的 autopilot 组件，通过它和画像服务来实现集群各个组件的弹性扩缩容和节点安全下线（VPA+HPA+节点下线）。autopilot 的核心 CRD 资源是 ClusterScaler，它描述了各个集群里组件的扩缩容参数、比例，扩缩容触发的事件源等。同时它支持多种 Scaler，如 CPU、内存、OOM 事件、集群大小等。其次它支持多种资源预估，一方面可以按照集群数大小来预估规格，另一方面可以按照推荐组件返回的资源大小来做预估，还可

173、以按照 OOM，集群配置等预估，最终会选取最大的给组件部署。最后，autopilot 还支持根因分析，通过根因分析模块可以正确区分用户的场景是否是合理的行为，如果是非合理的的行为，这时候是不可以进行扩容的。在节点缩容下线场景，腾讯云支持多种策略来获取待缩容节点，比如低资源利用率、按标签、按禁止调度，或者是指定的低版本的 Kubelet，这些都是可插件化的。另外 Pod Eviction Provider 也支持多种方式，如 Descheduler、Evict API、指定运维人工来操作等。最重要的是它支持 dry run 和限速，让下线流程更加可控。用户可以下发 CRD 看到当前这个策略会导致

174、哪些节点被缩容，会影响哪些 Pod。如果在缩容过程中发现这个 Pod 可用性会受影响，就会触发一些扩容操作，实现安全稳定的缩容节点。89腾讯云技术实践精选集保障稳定性经验总结1.注意细节。墨菲定律意味着再小概率的事情都会发生，严重的事故往往有一小串被忽视的 bug 组成，无论是 etcd 还是 kube-apiserver 都需要一套巡检机制去主动发现隐患、消灭故障的苗头；2.注意数据安全和备份，同时需要机制去检查备份是否成功、备份文件是否有效，一旦发生宕机等故障导致数据毁坏，备份是我们快速恢复业务的唯一希望；3.在设计系统的时候一定要考虑可扩展性，以及未来一些潜在的变化需求点。良好的扩展性可

175、以帮助显著提高开发效率和集群的稳定性。更多内容可参考演讲的 pdf 资料（https:/ kstone(https:/ star、fork,一起加入进来，提升 kstone 的各方面特性。在变更场景方面，腾讯云是基于 GitOps 来管理多产品、多地域、多环境、多版本、多种类型的组件。通过它可以实现一键开区、高效部署支撑集群和组件，可以大大减少人为的操作失误。90腾讯云技术实践精选集在 2021 年 ArchSummit 全球架构师峰会【深圳站】，腾讯云 CODING Nocalhost 研发负责人王炜带来了Kubernetes 环境下极致开发体验：实时热加载和一键调试的主题分享，介绍如何使用

176、开源工具 Nocalhost 简化 Kubernetes 环境下的应用开发，实现应用热加载和一键 Debug，获得秒级的编码/调试/测试循环。Kubernetes 环境下极致开发体验实时热加载和一键调试王炜 腾讯云 CODING Nocalhost 研发负责人CODING DevOps 高级架构师，CNCF 大使，KubeCon 评审委员会成员，开源的云原生开发环境 Nocalhost 研发负责人，著有 Spinnaker 实战：云原生多云环境的持续部署方案、Istio Handbook（作者之一），中国电子技术标准化研究院木兰开源社区导师。91腾讯云技术实践精选集K8s 环境开发困局与主流云

177、原生开发方式单体应用越来越大，会对组织架构以及协作形成挑战，所以大部分团队会采用微服务架构来拆分单体应用。微服务变多了之后，随之而来又出现微服务环境差异、迁移等问题，这时候 Docker 为我们提供了很好的解决方案，有了很多 Docker 镜像之后，这些镜像在运行的时候还需要编排的能力，K8s 的出现为我们提供了完善的编排解决方案，目前已经几乎成为了容器编排的事实标准。但 K8s 这套系统主要是面向运维提供能力，对于开发人员来说很容易造成困惑。同时它在开发和调试应用时会变得很困难，不可能像本地开发一样能够使用自己的 id 很方便地调试、打断点。除此之外，云原生的技术体系远比普通开发人员想象的要

178、大很多。云原生项目数以百计，完全不是原来传统单体应用开发的知识架构和体系。虽然 CNCF 在云原生开发工具上有社区实践，但事实上，目前社区还没有很好地解决云原生环境下大部分场景的开发问题的实践，这也导致每一家公司可能采用的技术栈或者开发方式差异巨大。目前主流的云原生开发方式有四种：第一种是全手动的方式。在本地编码之后，本地执行 Docker Build、Docker Tag、Docker Push，然后再执行 Kubectl 编辑更新工作负载的镜像版本。这个流程是最慢的，每一次查看编码效果大概需要十分钟左右，一天可能有一半的时间在等待构建的过程。第二种是全自动化的流程，引入 CICD 流水线。

179、不过它仍然改变不了每一次编码之后都需要重新构建镜像的问题。第三种是借助网络打通工具来打通本地和远端集群的网络，从而在本地运行源码。一款较流行的工具叫 Telepresence，但它还是不能全盘解决问题。第四种和第三种差不多，是用云上的 K8s 集群结合 Telepresence 这款工具来做开发。92腾讯云技术实践精选集Telepresence 背后基于网络打通的开发方式局限性是非常明显的，主要有三点：环境差异：工作负载声明了 env、configmap、secret、volume 等，很难在本地复制出完全一致的环境；跨平台差异：即便能够将远端的 env、configmap 挂载到本地，也难以

180、屏蔽跨平台之间的差异；网络限制：全量代理会使网络拓扑产生变化，导致内网、公网访问无法达到预期。要在 K8s 环境下获得像本地开发一样的体验，主要需要解决两个问题：本地编码实时生效以及复用集群网络。它们总结为一项技术，叫容器的应用热加载，也就是腾讯云 Nocalhost 这款产品所实现的目标。容器应用热加载原理在 Dockerfile 里会声明 CMD 或者是 ENTRYPOINT 来告诉容器启动的时候要执行什么命令。声明后启动容器，会发现声明的进程在容器里就是 PID=1 的进程。如果能把 Dockerfile 里 PID=1 的进程替换成用源码的方式运行，就可以实现容器的应用热加载。构建镜像

181、的时候，原来它是二进制的可执行文件，但是在真正需要开发的时候把它替换成以源码的方式运行，源码又可以编辑，就相当于实现了在容器里随时启停、更新业务进程。93腾讯云技术实践精选集不过在真正实现我们的思路时还缺两个条件。首先，Dockerfile 里只会复制二进制文件，大部分情况下，对于编译型的语言来说是没有源码的。第二，编译环境在常规的业务镜像里是不会有的。因为业务镜像会有一系列安全、大小要求，会要求不安装这些，在生产上没有必要运行的工具。要解决源码来源的问题，可以从本地同步源码到远端容器里。解决编译环境的问题，则可以把正常的业务镜像替换为开发镜像，用来提供语言的编译环境。解决这两个问题之后，最终

182、便能够实现本地编码后容器内实时同步，在容器内以新的代码启动业务，即实现了容器应用热加载。Nocalhost 是开源产品，实现的核心原理就是本地和容器的代码同步以及替换业务镜像为开发镜像。Nocalhost 由两个端组成：Server 端：面向管理者，可选组件。高度集中管理的开发环境、开发者、应用、开发集群等开发资源，例如实现开发者间环境隔离；IDE 插件：面向一线开发人员。开发过程无需重构镜像，本地编码实时生效，缩短开发-调试-测试的循环反馈，提高开发和调试效率。Nocalhost Server 提供了整体的环境管理解决方案。它主要有两个能力，第一个是可以隔离所有开发者的开发环境。它是基于 K

183、8s Namespace 来实现的，可以为团队里面的开发者分配 Namespace 来进行环境隔离。第二个是统一管理所有的开发资源，比如集群、应用等等。Nocalhost IDE 插件主要为一线开发人员提供编码的实时热加载以及一键调试功能，支持 VScode 和 Jetbrains 全系列，几乎覆盖了所有 IDE 编辑器类型。Nocalhost 开发和调试演示以一套图书管理系统为例，它是由五种不同语言编写的微服务组成的。不同区域是由不同的微服务输出的内容。94腾讯云技术实践精选集假设现在有个需求，需要改 Bookinfo Authors 里的作者信息。这里有个细节，虽然访问的是 127，但事实

184、上访问的是远端集群，因为后面已经做了自动端口转发。Details、Reviews、Authors 这些服务都是由不同的微服务输出的。假设要改 Authors 服务里面的作者信息，对于传统的修改方法来说，要打开源码，找到源码地址，修改这段代码，使用 Docker Build、Docker Tag 等一系列命令重新构建镜像，并且使用 Kubectl 修改工作负载的镜像版本，等待调度，最终才能看到编码效果。在 Nocalhost 中可以直接找到 Authors 服务，右击直接进入开发模式。进入开发模式之前需要选择源码来源，例如打开本地目录，或者是从 Git 仓库克隆，然后就正式进入开发模式了。进入开

185、发模式之后，Nocalhost 会自动替换工作负载镜像为开发镜像，然后打通网络并且执行文件同步，同时自动用 IDE 打开源码。进入开发模式之后，页面下方会直接得到 Terminal。它是容器的 Terminal，不是本地的 Terminal，方便直接对容器的进行操作。接下来，只需要像本地开发一样去修改代码就可以了，这里我们以修改作者信息为例，修改完成之后，本地修改已经同步到容器内，现在只需在容器里启动业务代码(go build app.go)，再返回浏览器刷新页面，会发现编码已经实时生效了。95腾讯云技术实践精选集对于编译型语言，只需要在本地修改代码之后，在容器里重新启动进程就可以。对于像 P

186、ython 或者 PHP 这种脚本型的语言，甚至不需要重启进程，本地编码便可以实时生效。此外对于编译型的语言，Nocalhost 还提供了热加载功能，它和语言以及框架无关。仍然以 Authors 服务为例，右击该服务并选择 Remote Run 之后，Nocalhost 会自动在容器里运行业务，具体的运行命令是可以定制的。接下来只需像本地修改本地编码一样修改这段代码，然后保存。保存之后会看到 Nocalhost 会自动地在容器里重启这个业务进程，这一切都不需要开发人员干预，再返回浏览器查看，代码修改已经生效。对于 Nocalhost 的一键调试功能，仍然以 Authors 服务为例。开发人员选

187、择 Remote Debug 时，Nocalhost 将自动在容器里以调试模式启动业务进程，调试命令也是可以定制的，Nocalhost 会自动打通远端和本地的调试端口，以及控制 IDE 自动 Attach 到集群里需要开发的服务上的调试器上。接下来只需要在 IDE 里面正常打个断点，返回浏览器刷新，可以看到断点信息已经过来了。Nocalhost 右侧菜单还提供了很多跟 K8s 相关的内容。这里就有个好处，开发同学人员使用 Nocalhost 时不需要学习很多 K8s 方面的基础知识，因为右侧的快捷菜单已经提供了查看日志、端口转发以及打开服务终端等等一系列功能。从原理来讲，Nocalhost 把

188、业务镜像替换成开发镜像。在容器里面以源码的方式运行业务，可以直接继承原来声明的 Configmap、ENV 或者是挂载卷的。此外还会替换容器里的 PID=1 的进程为阻塞进程，防止容器因停止业务进程后 Crash。第二步是增加文件同步的 Sidecar，它和开发镜像是解耦的，开发镜像可以自己定制。第三步是在 IDE 里自动获得远端容器的 Terminal，这意味着所有的编码操作、K8s 操作都可以在整个 IDE 里面形成闭环。对于管理人员来说，如果要在云原生的大背景下统一管理开发环境，Nocalhost Server 就可以很好地满足这样的管理诉求。它可以在 Server 端统一管理所有的用户

189、、集群和定义 K8s 应用。除此之外，开发空间是基于 K8s Namespace 隔离的，不需要单独帮开发者去操作 K8s 集群里的这些内容。96腾讯云技术实践精选集Nocalhost 的开源共建与展望Nocalhost 是一款开源产品，也是免费产品。目前它在 GitHub 上有 1000 多个 Star，也是 CNCF Sandbox 项目，已经捐赠给社区了。展望未来，Nocalhost 对于开发环境来说会增加非常好的能力，叫休眠模式。系统可以自动识别用户当前是不是在活跃，如果不活跃能自动进入休眠，把集群的 Nocalhost 或者开发空间里的工作负载的副本数调为零，让它不占用任何计算资源。

190、这里还会增加自动唤醒功能，也就是在上班的时候可以自动地唤醒它，让它重新具备开发空间的能力。第二个会增加的能力是 VCluster 虚拟集群，可以把它理解为是 K8s 的虚拟化，可以在 K8s 集群之上再新建集群出来。这对于某些集群的应用场景是非常有用的。因为有些应用在集群里面只能部署一套，而不同的开发人员来用的时候可能需要多套集群，这个时候资源消耗量很大，所以用 VCluster 可以解决。最后关于实践建议，K8s 是声明式的系统，所以如果能够非常好地定义 K8s Manifest，就意味着有能力把开发环境定义出来。但事实上很多客户在实践的过程中是采用维护环境的方式，维护固定的几套环境给开发人

191、员共用，有什么问题概不负责。而这种维护环境的方式目前来看不是很好的实践。所以腾讯云推荐的实践方式是定义环境，而不是维护环境。97腾讯云技术实践精选集数据库与存储技术PART 0298腾讯云技术实践精选集2019 年，Gartner 在一份报告中将 Serverless 选为最有潜力的云计算技术发展方向，称其为云原生时代的必然发展趋势之一。Serverless 从底层开始变革计算资源的形态，为软件架构设计与应用服务部署带来了新的设计思路。在各类 Serverless 应用中，数据库的 Serverless 化被认为是颇具挑战性的一大类别。曾几何时，业内只有亚马逊 AWS 发布了较为成功的 Ser

192、verless 数据库产品。2020 年 4 月，腾讯云发布了国内第一款 Serverless 数据库，填补了国内这一领域的市场空白，在数据库市场获得了大量关注与期待。为了让更多 IT 从业者更深入了解腾讯云 Serverless 数据库。在 2021 年 QCon 全球软件开发大会【上海站】中，腾讯云数据库高级工程师巫旭东发表了云原生 Serverless 数据库的设计与实践的主题演讲，分享了腾讯云 Serverless 数据库的诞生背景、设计理念与落地实践。云原生 Serverless 数据库的设计与实践巫旭东 腾讯云数据库高级工程师10 年互联网研发经验，2018 年加入腾讯后开始负责腾

193、讯云原生数据库 TDSQL-C MySQL 及 Serverless 数据库的探索和研发。99腾讯云技术实践精选集传统数据库常见问题与解决方案在 IT 行业，新概念的诞生与崛起往往是为了解决现有方案长期存在的问题和挑战，Serverless 数据库亦是如此。随着行业快速向云原生架构转型，传统数据库的一系列缺陷变得愈加突出，逐渐成为系统架构中不可忽视的瓶颈环节：1.业务系统转向微服务架构后，由于每个微服务需要单独搭配数据库，当微服务比较多时，轻量化数据库的数量也随之增加，开发环境预发布与线上微服务的相乘结果将呈爆发式增长，其成本很容易陷入失控状态；2.很多新服务上线时，很难准确预估其计算资源需求

194、，传统的云端预付费模式容易导致资源购买过量和浪费；部分数据库呈现平时低频，短时高频的访问特征，传统模式不仅会造成浪费，还很难及时完成资源扩容，带来业务损失；3.传统数据库的存储与计算在同一台服务器上完成，当用户存储与计算需求不匹配时，传统购买模式会大幅增加扩容成本；4.服务数据库容量可能超过单机上限。当业务早期没有准备好分布式能力，或需要开发分布式事务时，传统数据库的这一瓶颈会对业务产生较大冲击。之所以传统数据库会遇到上述问题，最主要原因在于其计算层与存储层耦合于同一台服务器上，很难灵活分配资源。传统数据库缺乏自治能力，用户尚不清楚数据库服务负载时就要先购买固定的计算与存储能力；当服务器负载升

195、高时，数据库无法自行感知资源不足情况并进行应对。与此同时，数据库主机的计算与存储资源比例固定，售卖时只能遵循这一固定比例，多余成本需要用户买单。另外，传统数据库的扩容依赖人工响应，跨机迁移速度非常缓慢。最后，单机存储上限大大限制了传统数据库的水平扩展能力。针对上述问题，行业提出了一些针对性的设计理念。例如成本问题可以通过按量计费模式解决，资源预估问题和低频服务需求可以通过自治能力、自动扩缩容来处理。存储池化概念能够突破单机存储能力瓶颈，实现动态扩缩容。100腾讯云技术实践精选集Serverless 数据库架构与设计理念腾讯云Serverless数据库就是基于上述理念打造而成的新一代云原生数据库

196、。这款数据库的架构基石就是“存算分离”，所有计算节点共享同一份存储层数据。对于用户来说，不管在集群里购买多少计算节点，都只需要一份存储资源。计算与存储分离在不同机器上，就需要网络 IO 来交换数据。若使用传统的网络 IO 技术，数据库的计算与存储节点交互的日志会非常庞大，且延迟很明显。所以腾讯云自研了 Txstore 分布式存储内核，将所有日志统一到了 redolog 的功能上。TXstore 会接收发送过来的 redolog，这样既能把计算与存储剥离开，又可以达到最高性能。在 Serverless 数据库的自动驾驶架构中，分为五个层次用户、管控、数据流、计算和存储。用户层就是控制台的一些模块

197、。管控模块分为两个部分，其一负责管控计算模块的分配、回收、暂停操作。其二是副驾驶决策模块，负责实时采集计算模块的当前负载，根据实时负载及之前分配的计算节点资源来做评估；如果当前分配的资源不足以处理当前的负载，该模块会向管控模块发起扩容请求；如果计算节点负载较低，分配的资源有冗余，决策模块会发起收容请求。极端情况下某些计算节点可能完全没有负载。例如共享充电宝一般放在商场里面，商场晚上 10 点后就关门了，这时充电宝不会发来请求。如果数据库还在运行，资源就会浪费一整夜。此时系统发现数据库超过十分钟没有任何新连接，就会回收计算资源。但存储资源是有状态的，不会回收。到早上 10 点商场开门了，用户进来

198、扫充电宝，其客户端就会向集群的 proxy 发出连接请求。此时 proxy 发现计算节点不在，就会向管综合来看，新一代数据库需要做到：第一，计算与存储分离，不再受限于某一台服务器的计算与存储资源；第二，实现服务自治，能够自动计算服务器负载，实现资源动态扩缩容。综合来看，新一代数据库需要做到：第一，计算与存储分离，不再受限于某一台服务器的计算与存储资源；第二，实现服务自治，能够自动计算服务器负载，实现资源动态扩缩容。101腾讯云技术实践精选集腾讯云 Serverless 数据库的存储池化架构是核心要素之一。传统架构使用的是母机概念。上图中的三个母机，蓝色部分是计算资源，绿色加红色是存储模块，其中

199、红色是已经使用的模块。母机是格式化分配，必须要对计算与存储做相应比例的分配。绿色的模块没有使用，但用户也要付费；没有使用的空间都是预付费的能力，必须提前付费。且传统架构中增加计算资源时，用户必须要重新购买完整的计算与存储母机，就可能为多余的存储成本买单。在存算分离架构中 Master 跟 Slave 共享同一份存储，存储是按照 shard 分片这一最小单元做分配，每个分片固定为 2G。如果数据库只用到 10G 的数据就只需要为 10G 付费，用到 11G 就只需为 12G 空间买单。并且因为存储是分布式，容量不受单机存储限制，最大可达 128T。存储池化涉及路由表的概念。存储池的实际物理存储单

200、元 page 为 16K，每个 page 有自己的编号。一批 page 的集合就是 shard，其地址都会存在 DBMaster 模块里。读写请求需要找到 page 时，系统找到 page 后计算得到分片号，基于分片号通过路由表找到物理位置；再计算 page 在 shard 上的偏移量，有了物理地址和偏移量可以做 page 寻址，完成一次读写请求的数据查找。下面是关于计算自治部分，首先是扩缩容场景。控模块发起请求，请它唤醒计算节点。管控模块会重新拉起计算节点，并通过路由表来关联存储节点。之后 proxy 发现计算节点已经拉起，会把连接重新打给计算节点。这就是数据库具备的，从启动到暂停再到启动的

201、完整自动驾驶能力。102腾讯云技术实践精选集数据库启动时，首先需要用户主动填写期望的数据库最小与最大规格。因为有些用户对成本比较敏感，不希望数据库无限扩容，希望到一定的阶段就停止；还有用户希望数据库启动时最小规格保持在较高水平。为此腾讯云提供了一些规格列表供选择。扩缩容时，CPU 容量不限于数据库当前使用的数量，数据库启动时可以使用的 CPU 上限是规格最大的上限。因为如果系统限制用户的 CPU 数量，那么超过限制值时性能就会下降；但扩容本身有一定延迟，在 30 秒左右，也就是说决策模块发现业务使用的 CPU 数量超过当前的规格限制 30 秒之后才会扩容。所以腾讯云决定 CPU 数量不受当前使

202、用数量限制，并承担 30 秒以内的多余成本，因此用户侧是无感知的。与 CPU 相比，内存是有参数限制的。数据库的内存使用上涨后不会自动缩容，必须有参数动态限制数据库的内存。另一方面，当用户实际使用的 CPU 超过了当前计费值 30 秒后，系统就会向下一个规格扩容，例如从 0.25 扩容到 0.5、1 核，从而实现服务灵活自治，实际性能不受计费规格限制，且超出部分由厂商买单。但这样一来单台服务器可能扩容到超过主机资源上限，出现母机资源超载问题。解决母机超载问题就需要跨机迁移。这里的算法假设母机的所有计算资源总量是 S，当前母机上所有实例规格总规格是 M，扩容后规格计做 N。当 M 加 N 大于等

203、于 S，意味着一台母机的计算资源不够用了。这时存储是足够的，只需迁移计算节点，需要新找一台机器拉起计算节点，初始化表结构。此过程可以在两秒内完成，相比传统架构的迁移耗时（可达数十小时）有巨大飞跃。关于计算节点的暂停与冷启动方面，当某个实例连续十分钟没有连接时，系统算法会将其回收，进入“暂停中”103腾讯云技术实践精选集状态。客户端再发起连接请求时不会直接打到实例上，而是会打到 proxy 上。后者发现数据库暂停，就会发起唤醒请求到管控模块，管控模块拉起 Serverless 的计算节点。从 proxy 发起唤醒到计算节点被拉起的时间就是冷启动时间。传统数据库的冷启动必须要加载所有存储数据，时间

204、非常漫长。但 Serverless 数据库只需要处理计算节点，只需加载路由表，所以启动速度非常快，可以优化到 1.6 秒到 2 秒。冷启动完成后，proxy 会正常向 Serverless 数据库发起连接请求，成功连接客户端并进行正常的读写操作。上图是 Serverless 数据库按量计费方案，其计算计费单位是 CCU。系统每秒钟在母机上采集 CPU 当前值和五秒前的值，做减法除以 5 就得到每一秒平均 CPU；内存与存储的使用量每秒上报。这样 Serverless 的指标可以做到秒级采集。最终计费的单元是 CCU 和存储，这两个指标按小时上报扣费系统，给用户看到按照小时计费的帐单。Serve

205、rless 数据库落地场景腾讯云 Serverless 数据库已上线 10 月左右，用户量累计较多。其中较典型的应用场景是同腾讯云开发的深度合作。很多小程序开发者的云服务托管在腾讯云开发上，后者与 Serverless 数据库做了深入耦合。一些云开发用户对成本和业务性能非常敏感，过去他们会报告数据库成本非常高，现在得到了明显的成本下降效果。腾讯云函数也是 Serverless 数据库比较早的实践者。云函数将代码托管到容器里，当用户使用时拉起容器，不使用的时候把容器关掉，以提供无服务化的产品。过去计算节点在不提供服务时也会收费，而 Serverless 数据库就填补了这块拼图。104腾讯云技术实

206、践精选集上图是实际使用中的效果展示。可以看到左上角的CPU使用核数与右上角的CCU呈现比较完整的耦合状态，CPU 用量增加，CCU 也跟着涨了上来；10点16分 CPU 降下来的时候，CCU也会按照预期一半一半往下缩。监控管理方面，腾讯云 Serverless 数据库与智能管家做了一些深度合作的监控管理，可以从不同的维度监控数据库。其中包括一些 SQL 预防操作，系统感知风险后会给用户提供操作建议。性能分析模块发现数据库的 CPU 或者内存出现瓶颈，会建议把最大规格再调大一点。数据库的告警机制也比较完善，可以支持 70多个监控指标的告警。此外还有问题快速定位，可以给用户提出一些比较好的处理建议

207、、分析复盘和优化建议。105腾讯云技术实践精选集总结 回顾历史，可以看到数据库技术经历了四个时代。最早是自建时代，开发者在购买服务器自建数据库。这个时代的数据库和硬件生命周期完全绑定，且运维方式比较原始。第二个是 paas 租用数据库的时代，出现了一些运维层面的改进，且节省了硬件购买成本，但因为存算一体化所以资源弹性比较差。接下来是云原生数据库时代，做到了存算分离，所以资源弹性有大幅改善，可以高效扩缩容。但这一代数据库没有自治能力，所以腾讯云在云原生数据库的基础上进一步设计了第四代 Serverless 数据库，完美利用了存算分离特性。第四代数据库可以进一步提升资源弹性，可以做到纯粹按量计费，

208、且服务更加自治，有了秒级扩缩容，服务更加稳定。106腾讯云技术实践精选集TDSQL 是腾讯云旗下金融级分布式数据库产品，具备强一致高可用、全球部署架构、分布式水平扩展、高性能、HTAP 双引擎、Oracle 兼容、企业级安全、便捷易运维等特性，目前金融核心系统客户已超过 20 家，尤其在银行传统核心系统领域，位居国内第一阵营。客户涵盖多家国有大行，及平安银行、张家港银行、昆山农商行等头部银行及广泛金融行业机构。本期为大家带来腾讯云数据库专家工程师唐彦主题为 企业级分布式数据库 TDSQL 元数据管控与集群调度的分享。以下是分享实录：企业级分布式数据库 TDSQL 元数据管控 与集群调度唐彦 腾

209、讯云数据库专家工程师唐彦博士的研究领域主要集中于分布式存储、大规模数据密集型系统的关键技术。他以第一作者的身份在领域 Top 类期刊和会议上发表多篇论文。目前在腾讯主要负责分布式数据库 TDSQL 的元数据管理与集群管控调度的相关工作。107腾讯云技术实践精选集TDSQL 架构介绍TDSQL 的全称为 TencentDatabaseSQL。下图是 TDSQL 的最新技术架构，它描绘了一个计算/存储分离、数据面/管控面分离的高可用的原生分布式架构的关系型数据库。TDSQL 分为三层：绿色部分是计算层，称之为 SQLEngine；紫色部分是管控层，简称为 MC，负责整个集群的管控调度工作；蓝色部分

210、是存储层，称为 TDStore。TDSQL 架构三个重要的特性：全分布式，无论在计算层还是管控层，每一层都是分布式的架构；计算与存储分离；可实现动态可扩展功能特性。TDSQL 的四个主要功能特点分别是：高度兼容 MySQL。TDSQL 对单机迁移过来的业务，兼容度高达 100%，能够实现无感知迁移。高可扩展性。在存储层和计算层，用户只需手动在管理界面上添加一个存储节点或计算节点，后续内部的管控机制会自洽地完成整个流程。支持原生 Online DDL，可多写架构下以原生方式实现 Online DDL。全局读一致性。TDMetaCluster 统一分配全局唯一递增事务时间戳，实现金融级场景下的数据

211、强一致。108腾讯云技术实践精选集分布式架构主要分为计算层、存储层和管控层。首先是计算层。TDSQL 计算层最大的特点是多主架构，每个节点都支持读写，完全相互独立；每个计算节点为无状态，具备扩容优势，可实现 MySQL 的高度兼容，具备无状态化的弹性扩容的架构特性。其次是存储层。它是我们自研的 KV 存储引擎。在存储层和计算层的交互中，存储层承担事务协调者的角色。我们以一定方式将数据打散到每个存储节点上，每个数据分片称为 Region。存储层对所有数据的状态自身无感知，只负责数据的读写，所有数据的调度都由它与 MC 的交互来进行。109腾讯云技术实践精选集最后是管控层。它是一个分布式的集群，以

212、 N 倍的方式去部署。在整个集群中，它要同时承担管控层面和数据层面的工作。比如在数据层面，MC 负责一个全局、一个中心的严格递增，是唯一的分配者角色，且同时负责管理所有的计算节点、存储节点的元数据、MDL 锁。以下是数据库中常见的主功能流程：分布式事务。数据库的访问是天然的分布式事务。整体流程为：从 MySQL 客户端发送请求，通过计算层对存储层进行读写，读写过程中，存储层和计算层都会去和 MC 交互，获取时间戳，最终确定每个事务之间的偏序关系，完成整个流程。110腾讯云技术实践精选集无感知扩缩容。当存储空间不够时就需要扩容。在扩容过程中，必然会涉及到数据的搬迁。如下图例子所示，整个集群中只有

213、一个存储节点，当需要扩容时，可以在界面上点击多购买一个存储节点。此时存储节点上数据的分裂搬迁、计算层对最终数据路由的感知、计算层感知路由的变化后完成的重试等过程可以完全自洽地包含在整个数据库体系中，实现业务层无感知。Online DDL。TDSQL 的分布式体系架构采用多写架构。为达到更好的并发性能，需要在多写的架构下，实现 Online DDL。相较同类产品，当业务尝试在运行过程中加一列、加一个索引时，需要借助外部的工具，及堵塞业务来完成 DDL 的操作。为了更好的用户体验，降低对业务的影响，通过 TDSQL 可以把多写架构下的 DDL 以原生方式去完成。111腾讯云技术实践精选集TDSQL

214、 在分布式场景下的挑战TDSQL 架构的三大功能特性：原生分布式，全部都是分布式，没有中心节点管控。存算分离，计算跟存储完全分离，不在一个服务器上。数据跟管控完全分离，数据层面完全不参与数据管理。首先是高性能方面的挑战。在架构上，要做到分布式的完全存算分离的架构，MC 作 为 集 群 内 唯一一个中心的管控模块，必须承担全局授时源角色。这些特性直接、简单，却在工程落地时遇到诸多挑战，主要是高性能、高可用、复杂调度三个方面。下面将着重分享我们在高性能、复杂调度方面遇到的挑战。112腾讯云技术实践精选集在复杂调度层面。我们设计成数据和管控完全分离的架构，数据完全存储在TDStore上，只负责数据流

215、的读写。其他工作完全交由管控层去进行，MC 只需要监控整个集群的状态做出关于存储资源的决策。在分布式事务的整体架构图中，可以了解到 MC 在事务过程中需要和存储层做网络交互，提供时间戳，这是关键路径。同时 TDSQL 的计算层和存储层都可以灵活扩缩容。存算分离、高扩展的两个特性也意味着 MC必须要具有非常高的性能。113腾讯云技术实践精选集TDSQL 在集群管控的探索与实践高性能方面的探索与实践在高性能方面，我们采用非常经典的三段式协程架构，即一个协程收、处理、最后再发。这种架构在我们突破 60 万时就达到性能瓶颈。通过性能分析，我们意识到性能瓶颈集中在第二个协程里。于是我们将出现瓶颈的地方并

216、行化。但第二个协程增加到一定时，下个瓶颈又出现，因为协程 1 是单管道模式，新的瓶颈点集中在协程 1。我们在下个版本里做了一个略微复杂的 N 对 N 架构，也是多协程架构。基于此我们发现性能可以提升但 CPU 的消耗非常大。我们的设计目标是 MC 在性能方面有较强的表现，其性能数据能到达 500 万。但当时尽管达到 75 核，数据还是停留在 320 万。我们对此进行 perf 分析，发现问题主要来自 RPC 解析，因为 MC 主要网络框架的实现是基于 GRPC 的网络通讯，会有比较大的头部序列化和反序列化的性能开销。114腾讯云技术实践精选集已知性能阻碍存在于网络框架，我们优化的目标就成为摆脱

217、网络框架带来的性能限制。对此我们给时间戳的获取开发了 TCP ROW Socket 通道。因为时间戳数据结构有一个天然优势，即请求无状态、无依赖，只包含两三个整型字段。这时在网络上发来的任何请求，MC 只需要收到一个，回答一个，可以去定制化完成请求。在弃用该框架后，性能提升飞快，在比较低的 CPU 开端的情况下，可以将性能提升到 450 万。但在后续过程中，我们发现瓶颈出现在请求进队列还有请求出队列的过程中。我们使用 Go Channel 作为消息的进出队列载体，Channel 虽然好用且轻量，但底层依旧带锁实现，push/pull 操作存在着百纳秒级别的开销。对此我们计划实现无锁队列，需要实

218、现单生产者、单消费者模式的场景。基于这种场景，我们实现一个简单的信号量，作为两者之间的唤醒机制。使用该优化方案后，资源的消耗明显降低且达到更高的性能，峰值吞吐突破 750 万。115腾讯云技术实践精选集最初 500 万的目标虽已完成，但我们团队仍认为性能数据还可以更好。以下为经典的 CPU 缓存的 MESI 状态转换图。一行 CPU 的 Cache Line 可以容纳 64 个字节，在我们的数据结构中，将其中多个 8 字节的变量放在同一个缓存，如果一个更新非常多，另一个更新的少，就会影响另一个原子变量的读写。从图片右边可知，在这里把变量的 8 字节对齐后，就解决 CPU 缓存行的问题，性能数据

219、也从 750 万上升至 920 万。此时我们的目标是实现单中心的千万级别的性能数据。为了进一步实现单中心的千万级别的性能数据，我们从业务场景进一步深挖。在整个集群中，MC 在时间戳方面是单一的提供者，而集群中众多的计算节点和存储节点会产生源源不断的请求，因此在分析生产者和消费者速度时，我们发现生产者速度远远跟不上消费者速度。为此我们进行了简单的改造，即来一批请求再消费一批时间戳，以批量请求方式去唤醒消费者。为了适应业务场景，我们还对该优化做了开关，运维人员可以根据业务场景的需求进行调节。执行批量化操作后，整体峰值已经提升至两千万，许多数据库实例的业务场景都无法到达这种高压力。116腾讯云技术实

220、践精选集下图为 TDSQL 原生数据库下，我们通过一系列优化手段达到 2000 万性能数据的过程。复杂调度方面的探索与实践由于实现数据面与管控面的分离，MC 要负责整个集群所有跟资源相关的管控。如图所示，图中画有 MC 的主要功能。MC 需要负责时间戳的提供，管理全局的唯一 ID 的分配、DDL 的协调、计算层管控层资源的元数据以及数据分片的管理。在管控层的不同层面，所有跟管理调度相关的工作都集中在 MC。117腾讯云技术实践精选集为了实现复杂调度，我们首先划分资源层级，制定可用的具有可扩展性的基础框架，将 MC 模块从管理任务中释放。将每个资源层级必须划分清楚，使得数据路径上的所有模块只需要

221、被动执行，不需要更新状态。我们从集群层面、复制组层面和副本层面进行划分，划分出许多子状态及子步骤。比如在扩容过程中，有一个数据分片，副本分布在 123 三个存储节点中，如果要进行数据迁移使得一主两备变为 1234 分布，任意时刻这四个节点都知道自己要做的原子子步骤，整个迁移过程实现零感知。迁移过程包含五个原子子步骤：先在节点 4 上创建新部分，再将新部分加入到原本的数据复制同步组中，去掉的副本的状态设置为 offline，最后再把该副本删除。在分布式数据库中随时可能有节点挂掉，但通过步骤划分，无论是 MC 挂掉还是 TDStore 挂掉，节点拉起来后都知道要如何操作。通过这样的机制，存储层对每

222、个任务的推进或回滚完全无感知，全部由 MC 来做协调。118腾讯云技术实践精选集该机制主要有以下三方面的效果：首先是性能。该机制对性能提升的促进非常显著，在集群比较大时可以轻松支持 EB 级存储。比如在 500 万数据分片的量级下，MC 用 20 个核就能完全支持。通过数据状态与调度状态的分离，大大降低了 MC 负载。性能上的收益还体现在存储层上。在任意时刻它只需要接收到一个原子步骤即可。因此在代码层面，存储层不需要任何关注数据资源状态的代码，更有利于进行性能优化。其次是健壮性。每个任务都是有限的状态机，任意一个参与者，如管控或存储，出现交互中断，都能够以确定方式进行任务的回滚或恢复。最后是可

223、扩展性。每个管控任务分为多个原子步骤进行，有利于以插件式方式去定义其他更多更复杂的任务。整个过程中只需要将原子步骤拼装组合，MC 就可以实现复杂调度。119腾讯云技术实践精选集数据分布方面的探索与实践原始版本中，MC 对数据分布管理只有物理位置概念，基于扩展引擎和分布式协议打造的 KV 存储引擎，数据分片在整个分布式存储集群中按照主键从空到正无穷的字符序来进行分布。比如创建表或二级索引时，如果要表达成 KV 形式，主键和二级索引都有对应的 ID。存储层中以 Key 区间代表一个数据分片，如 01-02数据分片，落在存储节点 1 上，02-03 数据分片，落到存储节点 2 上。这种情况下，同一张

224、表的数据的主键和二级索引会落在不同的 TDStore 上，这就会造成很大的负面影响。举个例子，有一张表，每天有大量不同的流水写入，有三亿行数据，业务为方便查询，做了 20 个索引。在最坏的情况下，20 个索引分别落在不同的 Region，又落在了不同的 TDStore。数据库使用者从操作上更新了一行，但可能会发展成 20 个涉及到 60 个参与者的分布式事务，带来 60 次同步的性能损耗。在这种情况下，我们针对经常出现的业务场景对两阶段提交进行优化，让更多的提交变成一阶段提交。我们设立表内数据的概念，每个数据在物理层面都可以知道每个 Key 落在哪个 TDStore，但无法感知到它们属于哪个二

225、级索引。对此我们需要建立关系去创建表，使得在创建表和索引时，MC 可以感知到每个 Key 在物理意义上属于哪个 TDStore，逻辑意义上属于哪些表的分区、属于哪些表的二级索引。我们还引入了复制组的概念。在原始版本中，每个数据分片是一个复制组，现在则是将多个 Region 归属于一个复制组，通过管控体系架构的改变，将表数据和二级索引放在同一复制组里。这种做法的好处有两方面：一方面，业务中常常按照分区键来划分事务，一次性修改的数据非常大，可能只落在同一复制组里，这时需要进行多次网络交互才能完成一个分布式事务，优化后只需要一次落盘即可完成；另一方面的好处是计算下120腾讯云技术实践精选集推，由于计

226、算层可以感知到要写的主键、二级索引都在同一 TDStore 的同一复制组内，就可以提前将逻辑下推到存储层中完成。接下来解决的问题是表与表之间的亲和性。在部分系统中，以一定规则如哈希去分区的表结构中，在更新表1 分区时，也会去访问表 2 的 1 分区。这就要求管控层必须理解表与表之间的概念。如果能感知到它们是在同一组事务里被操作的单位，就可以更好地改善事务的两阶段提交。对此我们提供了一个扩展语法。假如用户有需求，可以去指定他所倾向的数据分布策略，为该策略命名，允许在该分布策略里再指定分区策略。如下图所示，当下面第三行创建表时，如果有两个表在业务场景中经常被访问，就可以将它们关联到同一 DP 组里

227、，MC 会在后台创建表。所有的分布策略都会通过 MC 进行，MC 可以在后台将这些关联的表做背后的调度优化。这就为更多跨表之间的操作提供较多的可能性。121腾讯云技术实践精选集Risk&Opportunity未来我们仍有许多挑战需要克服。首先是全局事务时间戳，目前 MC 承担许多的管控操作，后续我们计划将其设计成多进程模式，全局事务时间戳独占一个进程。其次是Lieutenant 分流，我们计划增加副队长角色，分流部分网络。最后是数据亲和调度的利用也是我们未来会去重点攻坚的领域。122腾讯云技术实践精选集拥有二十余年历史的 PostgreSQL 是世界上历史最悠久、功能最强大的开源关系型数据库之

228、一。随着行业步入云原生时代，PostgreSQL 也随之焕发了新的生机。PostgreSQL 与云原生架构的结合带来了许多新的机遇与能力，是数据库从业者非常关注的技术主题。在 2021年 QCon 全球软件开发大会【上海站】中，来自腾讯云的数据库高级工程师唐阳做了题为 TDSQL-C PostgreSQL 在云原生架构下的新活力的演讲，分享了 PostgreSQL 在云原生架构下的设计思路、方法与实现细节和亮点，以及这两者的结合在实践中具备的特性优势。TDSQL-C PostgreSQL 在云原生架构下的新活力唐阳 腾讯云数据库高级工程师拥有 8 年丰富的数据库运维管理经验，主要负责腾讯云数据

229、库 PostgreSQL 系列产品规划与设计。123腾讯云技术实践精选集传统数据库架构常见问题在实践中，传统数据库架构经常面临一些受制于技术特性难以解决的问题：首先是数据库选型。某在线业务包含了用户订单、结算、交易等核心系统，但业务团队人数有限，人员储备不足，而对未来流量的预估规模较大，且规划有分析类业务。面对这样复杂而苛刻的要求，数据库选型就成为了一大难题。第二个问题是备份。线上业务使用的数据库数据量计 20TB。运维每次发版本需要备份，但每次备份都需要两三天时间，导致运维痛苦不堪。第三个问题是扩容。某次运营活动效果绝佳，流量峰值超过预测峰值，需要紧急扩容，但传统模式下，短时间无法完成大数据

230、量搬迁，错过了活动高峰期带来巨大损失。进一步分析上述问题可知：数据库选型既要满足现有在线业务，又要提供实时交易分析能力；数据量较大时需要分库分表，进行分布式改造；数据库要具备快速扩容能力；要具备快速备份/恢复能力。传统数据库架构存在的主要瓶颈是缺乏足够弹性，因而性能大大受限，上述问题很难得到根本解决。云原生时代数据库演进之路云原生时代，行业开始探索基于云原生的设计来实现云原生数据库，解决传统数据库面临的诸多问题。云计算的核心目标是解决弹性效率扩展与成本问题。传统的云 PaaS 服务将线下的数据库搬到了云上，基于124腾讯云技术实践精选集原有的架构能力，将相关的运维操作做成了一系列功能供用户直接

231、使用，但无法解决上述问题。随着行业发展，新一代云原生数据库开始充分利用云端优势，基于云端来做核心定义与特性：计算节点可以任意调度，对数据库的读写操作能立刻完成，无需先调整配置参数；任意调度，数据库的状态核心是数据，需要保证数据的一致性、可靠性。为了实现任意调度需要做到状态分离，令计算节点只需少量状态，甚至没有状态，随用随取；保证数据不丢失、数据完整、数据一致。状态分离后需要使用日志提供保障，因此需要基于日志做持久化；保证扩容效率。通过数据分片大幅提升数据搬迁效率；通过存储多副本保障数据可靠性；应用分离理念后，数据相关操作集中到数据存储层本身，将备份与恢复相关的逻辑下沉到存储层实现，提升效率与性

232、能的同时对用户无感；数据库相关操作都通过 API 控制；数据库服务具备高可用性。为了实现上述目标，云原生数据库实现了存算分离这项核心设计变革。存算分离概念有多种实践方法，例如，数据库部署在一台服务器上，用另一台服务器挂存储协议过去也算是存算分离，但这种方法却没有分离状态。真正的存算分离需要将重状态的动作放在下层，对用户无感，而上层实现需要对接数据库实际需求，为此抛弃脏块向磁盘刷新的动作，将查询处理、事务管理与缓存相关功能放在计算层实现；在存储层实现日志持久化、日志回放、备份恢复、数据页校验等动作就自然成为理想存算分离的一种实现方案。实现上述能力后，多个计算节点可以共享数据。为了在分离和不刷新脏

233、块之后保证数据一致性，就需要稳定的日志系统。日志即数据库理念是贯穿于整个云原生数据库的设计核心。写入数据时，传统数据库内核的常规模式是对变更数据事务生成一条记录写在日志中，再通过日志的写进程写入磁盘，之后向计算层报告写入成功可以提交，事务就完成了。同时用户更改了内存中的数据，使内存中的脏块把变更动作写入磁盘中，最终完成了整个数据库的更新。云原生数据库取消了刷盘动作。写入数据的第一步，计算机发起动作把日志交给存储层，告诉后者现在发起了变更要记录下来。因为底层是分布式存储，所以至少需要两个存储节点写日志落盘成功。内存里的相应数据块也会被写入，并通过刚刚写入到存储中的日志使数据块形成更新链，用户读取

234、时完成写入操作。全部操125腾讯云技术实践精选集当某个存储节点或者多个存储节点达到了设置的存储阈值时，监控系统会自动看到磁盘不足的状况，将有空闲的服务器加入到存储集群。加入成功后，系统会自动将其他冗余节点中的数据拷贝到新服务器中，这就是整个存储层的扩容逻辑。上述逻辑的核心是存储层将用户数据按照逻辑结构分成多个池，每个池按照实际情况分为多个段。所有的操作都是基于段来进行的，这样可以避免超大文件复制缓慢的问题。迁移、复制等动作对用户无感，读取数据时是从节点读取，会自动跳过正在复制的数据节点，从而将 IO 打散，避免 IO 争抢等问题。得益于存算分离的架构，计算节点很容易添加。传统架构扩容时会拉起从

235、库，数据迁移完成后通过路由将流量重新打到新库上，将其直接启动为主库，就完成了迁移动作。存算分离架构下也是同理，没有任何区别的。但由于无需搬迁数据，主从切换过程对于用户没有感知，具备更高的可用性。备份恢复看似是数据库的周边功能，但确实是最重要的功能之一，并且在数据量较大的场景中是最不好做的。备份恢复分为逻辑备份与物理备份，逻辑备份是将数据的定义语句和插入语句全部提取出来生成文件，成本作都在存储层执行，实现存算分离。这样做的目的是减少 IO 操作。之前既要写日志，又要写数据；现在只写日志，速度能够大幅提升。数据读取时与传统模式区别不大，完成存算分离的设计后，存储层是通过分布式存储实现的。分布式存储

236、是基于用户态的存储能力。存储层的隔离通过用户态实现，一个数据库实例对应一个池，每一个池至少会被分成 3 份，不同的节点存储数据。每个存储节点通过 Raft 协议进行数据的复制。126腾讯云技术实践精选集较大，所以一般场景下会做物理备份。物理备份操作需要读取线上正在运行的库，所以通常使用从库备份，避免影响主库。但备份速度受制于存储大小，存储越大，备份的速度越慢。为解决这个问题，分布式存储引入多个副本，其中备份副本是可以读取的数据。如前所述，底层存储不会从内存中把数据块写到数据文件，而是从日志来恢复，恢复时也是同样的机制，无需再转换一次，直接将文件复制走即可。但数据一直变化的情况下，就要保证数据的

237、一致性。正常情况下，备份副本与其它数据副本是一样的，需要发起备份操作时就停止日志恢复，这时数据一定是一致的，直接把备份副本文件复制走即可。这样就不需要寻找数据文件的一致性点，同时复制备份副本的过程就是备份所需的全部过程。完成备份操作之后，日志恢复操作重新启动，这里备份副本不是存储层数据可靠性的核心依赖点，下一次备份操作发起时重复前述过程即可，由此一来，备份速度得到了数量级提升。恢复操作更简单，只需将备份文件复制回来放回去即可。这是云原生存算分离架构的最大优势之一，备份恢复操作可以轻松完成。最后一点，存储层的粒度 Segment 很小，可以根据具体的业务或整体服务器的负载情况来灵活调整复制粒度，

238、避免实际业务访问时出现峰值问题，相关动作还可以通过管控系统自动调配、自动地合理均衡。127腾讯云技术实践精选集新活力在何处？PG 数据库是全球最强大的开源数据库，堪称数据库中的瑞士军刀，PG 是一专多用的全栈式数据库，有丰富的插件支持，几乎能够完成一切业务需求。PG 数据库与云原生数据库结合后，诞生了很多新的优势与活力。云原生数据库的设计通过架构，打破了传统数据库的一些壁垒限制，解决了弹性、备份、高可用相关的很多问题，将数据库的能力真正意义上地释放了出来。例如，PG 的存储能力之前受制于服务器的规格，但与云原生结合后 PG 可以处理更大的数据量。同时 PG 是多进程架构，可以充分利用有大量 C

239、PU 核心的服务器，充分利用云端具备的计算资源。分布式存储场景下可以实现分级存储能力，可以根据数据冷热特性，将不同类型的数据存储在不同速度和成本的物理介质上，取得性能与成本的平衡。由于云原生架构的高弹性优势，计算资源能够灵活实时配合业务需求，业务有需求时迅速拉起计算节点，需求减少后就按需关闭，这样就能充分利用计算资源。进一步来说，以高弹性为基础，Serverless 数据库就可以完美落地。云原生概念的诞生就是为了解决实际应用中的许多问题，基于云原生理念设计的数据库，为用户提供了更多选择和能力，打开了更多可能性。128腾讯云技术实践精选集目前，大多数应用程序都需要使用缓存对数据访问进行加速，所以

240、“缓存+存储”就成了一种常见的存储架构。但引入缓存后，对业务开发、数据运维以及数据一致性等方面提供了新一轮的挑战。企业该如何通过调整存储结构满足“缓存+存储”的场景需求？又该如何基于低延迟、高吞吐、Redis 持久化等方面进行优化？在 2021 年 QCon 全球软件开发大会【上海站】中，腾讯云数据库专家工程师伍旭飞发表了“缓存+存储”架构下 Redis 持久化的探索与实践主题演讲，并为大家分享了 Tendis 在高性能、低延迟、持久化方面的实践经验。“缓存+存储”架构下Redis 持久化的探索与实践伍旭飞 腾讯云数据库专家工程师10 余年互联网开发经验，2018 年加入腾讯云数据库团队，负责

241、 NOSQL 数据开发以及新硬件在 NOSQL 数据库应用的探索。129腾讯云技术实践精选集传统缓存架构的挑战移动互联网时代高速发展，拓展了海量的用户数，而用户数的暴增也给业务带来了高并发、低延迟以及非结构化数据呈指数级增长等难题。因此，高并发、大存储、低延时就成为了亟需解决的问题。业务的竞争越来越大以后，就开始引入缓存，主要目的则是为了提高并发、降低延迟、解决热点以及降低成本，但在传统的缓存架构中，还会出现一致性问题、击穿问题，雪崩问题以及大 key 问题。在传统缓存架构中，也历经了如下几个阶段：首先判断能否命中，如果无法命中就读取存储，再更新缓存，最后返回数据；如果命中就直接返回数据。但在

242、这种情况下，击穿问题仍旧比较明显，比如在游戏开服时，由于都是新用户，缓存无法命中一定会击穿数据库。此外，在并行更新时还会存在一致性问题以及大 Key 更新加载慢的问题。其次，演进到先更新/删除缓存的架构，但在并行更新的场景下，依然会存在脏数据；随后，又发展到了延迟双删的架构，先删除缓存，延迟 N 秒后再次删除缓存。但这个方案对于一致性的要求比较高，还是容易出问题：一方面，删除失败会导致脏数据，另一方面，双删会给存储带来额外的压力。为此，又延伸出了第四种方案，即当删除失败后放入队列中重试，但这个方案同样存在问题，比如，大 hash/list/zset 从存储加载到缓存的过程依然很慢，并且只能保证

243、最终一致性，无法保证强一致性。伍旭飞还在演讲中提到，因为涉及成本问题，不可能把所有的缓存全部攒在内存里，所以一定要把缓存淘汰。130腾讯云技术实践精选集业界的一次努力尝试基于传统缓存架构遇到的挑战，腾讯云做了 Tendis 混存版，用以尝试解决上述遇到的问题：它是利用改进版的 Redis 做缓存，然后用 Sink 组件部署在不同的机器上，同步在一个持久化的存储 Tendis 上。具体来说，有两个淘汰策略：第一个方案是 TTL 淘汰，即超过 TTL 指定的时间戳以后就过期淘汰，但这里存在的问题是，如果 TTL 设置不当会导致雪崩；第二个方案是缓存打满被动淘汰 LRU/LFU，但依赖缓存打满被动淘

244、汰，会导致性能变得很差，还会导致延迟抖动。但这个思路也存在几个问题：Redis 缓存所有 Key 成本太高；异步情况下，一致性问题未解决；异步落冷导致性能抖动。所以，对于云数据库来说，想用一个方案来满足不同场景以及不同用户的需求，其实是非常难的，很难做到一个比较完美的状态。经过上一次的问题之后，我们也在思考次世代的数据库应该怎么做？像 Mysql 这样的数据库，它主要适配以前的传统硬件，但在今天这个时代，随机读写依然比顺序读写慢，但是差距已经大幅缩小。拿 NVME SSD 测试，4K 读写延迟低于 100 微秒，4K 随机读写大于 10w+。AEP/BPS 新硬件的速度提升131腾讯云技术实践

245、精选集了一个数量级，读写延迟在350纳秒左右，4K 随机读的速度在600w左右，4K随机写的速度在200W左右。那么如何能在这样的硬件设备下将其发挥出最大的优势，我们也在想怎么在存储引擎方面，给行业注入一些新鲜的血液。传统的存储引擎 RocksDB 是基于机械硬盘优化的，读写放大更明显，适合多读写少的场景。因为它读的时间不可控，Complication 抖动无法避免；SST 文件内的热点数据无法聚合；而 Innodb 则适合基于 Range 的查询，针对 Key 读写，IO 路径长；另外，缓存是基于 Page 的，KV 缓存命中的效果不可控。那我们该如何使用 Redis 的存储引擎？基于 IO

246、 访问，我们具有读多写少、单 Key 查找为主、随机访问多的特点，并且极少数 range 查询采用的是 b+tree，都可以用 AEP/BPS 来加速持久化。其次，还应该具备热点动态聚合的能力，比如一个游戏注册用户有两千万、活跃用户五万，如果没有热聚合能力，热点数据可能在磁盘上每一页都有，为了加一个 key，就会把所有的页都加进来。但具备热聚合能力以后，就可以自适应地把这些数据聚合在更加热的页面里。它的好处也很明显，能够增大缓存的命中率、提升 IO 读写的访问时间。除此以外，我们还希望冷数据可以下沉，一方面可以降低成本，冷的数据下去以后，热的数据自然就能浮上来。另一方面，将 DRAM/AEP

247、提供给热数据还能够提升性能。降冷算法主要包含 LRU 主动降冷、LFU 主动降冷以及驱逐被动降冷三部分。因为引入了降冷流程，那就需要提供给更多的场景来适用，通过 DRAM、AEP、SSD 多节点存储，可以满足各种个性化场景配置，比如，多级存储灵活配置、提速场景、降成本场景以及归档场景等等。革命成果KeewiDB在腾讯云即将发布的 KeewiDB 中，解决了一致性问题、击穿问题以及雪崩问题。针对一致性问题，KeewiDB 通过内聚的三级缓存机制(dram+persist memeory+ssd)，利用持久内存的持132腾讯云技术实践精选集久化能力，大大降低了 IO 的负载，提升了并发性能，对外部

248、客户而言，天然地解决了持久化能力。针对击穿问题，KeewiDB 通过内聚的三级缓存机制(dram+persist memeory+ssd)，提供了智能的热聚合作用，热数据将大量缓存在持久内存中，缓解击穿问题。此外，缓存并不能彻底避免冷数据读取，KeewiDB 专门为 Redis 数据结构打造了合适的存储模型，大大降低了 IO 路径长度，再加上优先缓存 Index 等措施，即便是全冷数据，也能达到非常高的 qps 和低延迟。针对雪崩问题，通过三级缓存热聚合能力，可以大大减少冷数据访问，通过优先缓存索引机制，将冷数据的 IO 访问路径降低到极致，从而保证了即使有冷数据，性能和延迟也能满足要求，避免

249、上层业务大量失败，疯狂重试最终打爆业务。最后在易用性方面，通过一系列技术上的精心设计并把新硬件特性打包在一起，KeewiDB 试图解放开发人员的负担，使其能够更加聚焦业务，取得成功。133腾讯云技术实践精选集在数据量持续爆增、数据日益多样化的今天，传统数据库的迭代速度已经追不上数据的增速，且企业对数据库计算和存储能力的要求越来越高。面对当前的挑战和机遇，国产数据库厂商的研发创新速度不断加快，可以说云计算时代的到来，扭转了国外商业数据库一家独大的局面。目前，国产数据库领域正处于百花齐放的状态，已经有越来越多的行业巨头参与到了数据库的建设中，腾讯云便是其中之一。为了更深入地了解腾讯云数据库的发展历

250、程，从而进一步透视国产数据库的发展方向，InfoQ 和腾讯云数据库专家工程师窦贤明聊了聊云数据库的发展、前景与挑战。云原生数据库的“能与不能”窦贤明 腾讯云数据库专家工程师云原生 MySQL、云原生 PGSQL、TencentDB For PGSQL 等云数据库产品负责人；十余年工作经验，7+年云产品研发经验，从 0 到 1 研发多款云数据库产品，致力于提供易用、稳定、安全的云数据库服务，专注于数据库内核研发、云数据库产品研发等技术方向。134腾讯云技术实践精选集单一数据库不能解决所有问题进入基础软件领域已有十余年光景，窦贤明亲历了云数据库从零到一的建设过程，作为整个浪潮的参与者和见证者，他对

251、技术、产品以及市场都有着更加深刻的认识。据他介绍，当开发人员在部署一个传统数据库时，需要涉及购买硬件、部署机房、建立网络、部署实例、规划资源等等一系列操作；在维护传统数据库时，还需要进行扩容、监控、告警、日志、参数设置等等操作，而云数据库的出现便能够更加轻松、简单地实现上述工作。开发人员可以直接在云数据库控制台完成数据库的申请和创建，几分钟内便能准备就绪、投入使用，通过云数据库提供的控制台，还可以对所有实例进行统一管理。云数据库还支持物理备份、逻辑备份、备份恢复及秒级回档等功能，以此来保障数据的安全性。此外，传统数据库的价格高昂，动辄就需要投入数十万元的成本采购设备，而云数据库则能够按需付费，

252、用多少付多少。尽管相较于传统数据库，云数据库已经能够帮助企业解决大部分问题，但窦贤明告诉 InfoQ：“单一数据库不可能解决所有问题，云数据库在存储成本、HA 切换、网络瓶颈方面依然存在优化的空间。”如下图所示，Master 和 RO 虽然对应的是同一份数据，但在存储上实际有六份数据；而每多加一个 RO 节点就会多出三份数据，也使得整个集群的存储副本数近一步放大；高吞吐的数量会使网络问题成为瓶颈，在共享存储侧也有大量网络浪费。135腾讯云技术实践精选集云原生数据库应运而生目前，窦贤明与他团队研发的云原生 MySQL（TDSQL-C MySQL）、云原生 PostgreSQL（TDSQL-C P

253、ostgreSQL）便能够很好地解决存储成本、弹性扩容等问题。作为新一代企业级云原生分布式数据库，它的初衷是为了让运维人员更省心，让数据库的运维变得简单，具体来说，TDSQL-C 有以下产品特点：全面兼容：100%兼容开源数据库引擎 MySQL 5.7 和 8.0 以及 PostgreSQL 10。几乎无需改动代码，即可完成现有数据库的查询、应用和工具平滑迁移。高性能：具有商用数据库的强劲性能，最高性能是 MySQL 数据库八倍、PostgreSQL 数据库的四倍。海量存储：最高 128TB 的海量存储，无服务器 Serverless 架构，自动扩缩容，轻松应对业务数据量动态变化和持续增长。快

254、速恢复：计算节点实现无状态，支持本地和跨设备的秒级故障切换和恢复；支持基于快照的秒级备份和回档。数据高可靠：集群支持安全组和 VPC 网络隔离。自动维护数据和备份的多个副本，保障数据安全可靠，可靠性达 99.9999999%。弹性扩展：计算节点可根据业务需要快速升降配，秒级完成扩容，结合弹性存储，实现计算资源的成本最优。TDSQL-C MySQL/PostgreSQL 基于共享存储实现了存算分离架构，Master 和 RO 是基于一份数据放在共享存储中，RO 只从共享存储中读取所需的 page，不需要写入存储，并且 RO 可以从主库接收 WAL 在缓存中重放，以此保持缓存中 Page 持续更新

255、。这样一来，云原生数据库便解决了业务容量和计算节点的扩容的问题。TDSQL-C 还能够自动判断计算层面的资源，实现计算关停和热启动，且启动时间大概在 3s 以内即可完成。136腾讯云技术实践精选集在 11 月 4 日的腾讯数字生态大会 Techo Day 上，腾讯云副总裁李纲还宣布了云原生数据库 TDSQL-C 的全新升级：吞吐率提升 50%、将 IO 延迟降低 80%，整体性能提升 85%；带来全新形态 Serverless，通过全局工作流预测以及动态扩缩资源，进一步降低成本，做到真正的按需计费。在腾讯云发布的 Q3 财报中，也首次提到数据库对企业服务的贡献，财报显示：“我们的 PaaS 解

256、决方案TDSQL 数据库已经被 3000 多个来自金融、公共服务和电信垂直行业的客户采用。我们为中国十大银行中的六家提供服务，并在不同金融机构的核心系统中不断增加渗透，展示了我们在数据安全、可靠性和一致性方面的能力”。李纲表示，国产数据库即将进入规模化阶段，未来五年，腾讯云数据库即将助力 1000 家金融机构实现核心系统数据库国产化。攻克最严苛的领域在窦贤明看来，现阶段云数据库能够解决企业怎样的问题想必已经没有分歧，但对于一些传统企业来说，毕竟要将自己所有的业务数据迁移到公有云上，安全性成了他们最大的顾虑。关于这一点，他表示：“扭转行业内的固有认知是当下的一大挑战，云是一门信任的生意，需要长期

257、积累的过程才能扭转这样的局面。”那么，对于腾讯云数据库来说，怎么做才能加速对行业的渗透？“只要攻克了最为严苛的领域，就能证明我们可以满足绝大多数企业的需求。”窦贤明给出了这样的答案。而由于金融领域本身的业务特点，使其在数据一致性、高可用，性能成本以及水平伸缩等方面都有非常严苛的要求，也因此，金融领域成为腾讯云数据库势必要攻克的一块高地。腾讯云副总裁李纲也曾公开表示：“国产数据库的发展一般会经过互联网企业、民生政务、传统行业应用、金融核心业务这几个阶段的打磨，其中金融行业对数据库要求最为苛刻，不仅数据容错度低，而且还要符合信息安全等级规范。”作为国产分布式数据库的重磅产品，TDSQL 在背后支撑

258、了全国第七次人口普查、防疫健康码、张家港农商行核心系统的落地应用等等，且服务了国内前 10 大银行中的 6 家；在政务、电信运营商等领域，也已经服务了超过 3000 家金融政企客户。此外，在保险行业，TDSQL 正在帮助太平洋保险集团实现全面数据库国产化。在这些金融及政务项目中，TDSQL 的 Oracle 兼容性得到了充分验证，兼容度高达 98%以上，这能帮助业务在极短时间内，极小业务改动量的情况下，快速完成测试验证和上线。137腾讯云技术实践精选集在采访过程中，窦贤明还为我们介绍了一个“微服务+国产分布式数据库”的架构案例：昆山农商行将新核心系统划分成公共服务微服务集群、账务微服务集群和历

259、史微服务集群，并把这三个微服务集群运行在一套 TDSQL 集群中。由于 TDSQL 保障了微服务间一致性读的问题，使得企业在应用微服务组织结构的同时，也能解决存储分布式扩容的问题。持续迭代数据库的五个基本能力纵观腾讯云数据库产品家族，包含了关系型数据库、非关系型数据库以及数据库迁移、智能运维、可视化平台等相关应用。除了兼容主流的 MySQL、MariaDB、Redis、Mongo 等开源技术，腾讯云数据库也有内部自研的产品分布式数据库 TDSQL 和云原生数据库 TDSQL-C，基于这样多点开花的局面，也让我们不禁产生了一个疑问：面向未来，腾讯云数据库重点突围的方向会是什么？“稳定、安全、易用

260、，高效、成本低”窦贤明这样告诉 InfoQ，由于基础软件与应用软件在迭代速度上有着很大的不同，所以它不可能一天一个新概念。在他看来，做数据库要学会坐冷板凳，需要朝以上五个基本能力持续演进、迭代并逐步做到极致。窦贤明介绍说：“当前我们已经做到了 99.95%，未来需要朝 99.99%，甚至更高的目标去努力。”因为当云数据库没有了稳定性、可靠性、安全性等最基本的东西，一切都将成为空谈，也势必会被市场所抛弃。“在接下来的 510 年里，国内数据库行业将会出现一个很大的变化，相信过不了多久，大家会认可国产数据库是更好的数据库。”而这句话背后，不仅仅代表了腾讯云数据库的信心，更体现出了国产数据库从业者的

261、底气与实力。138腾讯云技术实践精选集随着云服务基础设施建设的发展，存算分离架构逐渐成为业内趋势，也成为腾讯云主要对外推进的方向。腾讯云基于对象存储 COS 的数据湖数据底座，打造了腾讯云原生的数据湖三层加速方案。在 2021 年 QCon 全球软件开发大会【上海站】，腾讯云技术专家程力带来了题为腾讯云存储数据湖三层加速的演讲，重点介绍腾讯云对象存储 COS 的三层加速方案中的 GooseFS 产品，通过实际案例和架构分析等方面，透视腾讯云的整体数据湖技术发展和演进方向，结合大数据、AI、训练等核心场景，展望未来腾讯云的数据湖整体计划。腾讯云存储数据湖三层加速程力 腾讯云技术专家主要负责腾讯云

262、对象存储数据湖方向，主要负责三层加速和 GooseFS 设计和研发，同时是开源社区 Apache Hadoop Committer 和 Apache Ozone PMC。139腾讯云技术实践精选集云原生生态下的存算分离从大数据到 AI，各种应用场景都出现了存算一体和存算分离两种不同的思路。HDFS 等方案将计算节点和存储节点部署在一起，好处是获得了数据本地性，数据存储比较稳定，而缺陷在于：运维压力比较大，无法做到弹性化。因此，随着数据存储的进一步发展出现了存算分离部署的思路，计算节点会大面积地运用所有业务机器上的资源来做计算业务，把数据分离到远端的云存储上。今天的各大云厂商都是在走存储计算分离

263、的路线。最近几年，云厂商又开始发力数据湖整体架构，将格式化和非格式化数据都存储到同一个存储方案中，也就是一种处理结构化和非结构化数据的方式，继续发展下去，计算和存储则都开始走向云原生化。腾讯云的对象存储 COS 始于 2014 年，很早就发展到了亿级数据量，并支持腾讯内部的各种上云业务。对象存储在可靠性和弹性方面有天然优势，还具备协议兼容、接口兼容、数据安全全链路保障等特性。时至今日，随着用户数据规模迅速扩大，HDFS 等传统存算一体方案的弊端凸显，具备性能、成本、高可用和可靠性优势的对象存储方案成为了数据湖数据底座的首选。在开始做数据湖存储之前，腾讯云已经有了像 COSN 这样的 Hadoo

264、p Compatible File System 实现。腾讯云想利用这个 COSN 的文件系统接口进入 Hadoop 的生态系统，把很多大数据业务接到腾讯云上。但在对接上 Spark、Flink 等服务后，腾讯云发现对用户来说，COSN 这样简单的文件系统实现并不能满足很多极端的业务场景需求，例如 COSN 的 OLAP 实时查询能力、批流一体能力都存在一些效率缺陷。同时，对象存储本身针对随机读、随机写等场景，需要花费大量读放大来满足对应的带宽需求。此外，大数据业务的峰值不是一直维持在很稳定的状态，而是会有毛刺现象、长尾效应。为了避免这些问题，云厂商存储服务团队可能需要提前准备很多容量满足带宽

265、需求。在这样的背景下，基于提升用户体验、降低成本的考虑，腾讯云开始发展数据湖生态系统。140腾讯云技术实践精选集云原生数据湖三层加速2021 年，腾讯云提出了数据湖的三层加速方案。该方案分为计算端的 GooseFS、数据端的元数据加速与存储端的 COS 加速器三个层次。GooseFS 是一个缓存层的文件系统实现。这个缓存系统主要是为了给客户提供存储计算分离架构缺失的数据本地性，并增加了 Hive Table 缓存等特性；元数据加速器主要解决 List 和 Rename 的性能瓶颈。List 和 Rename 优化是大数据存储领域的重点问题，元数据加速器就是要解决 B 端客户使用 Hive、Sp

266、ark 时遇到的此类痛点；存储端的 COS 加速器就是数据加速器。近年来，客户普遍希望跨层、跨区、跨 AZ 建设数据中心，于是会出现各个区的数据都服务同一个周期性任务的情况。此时 COS 加速器可以将数据缓存到离计算端最近的数据中心甚至机柜上，完成网络互通，从而降低成本。141腾讯云技术实践精选集具体而言，数据湖三层加速架构可以完成以下任务：GooseFS 缓存加速的一个重要特性是支持针对 Hive Table 做 Table 级缓存。例如，客户某个任务是以周单位做 Hive 查询来编制报表，于是每周的数据都会不断进入缓存，但缓存系统的容量有限，所以 GooseFS 支持 Hive Table

267、 Level 缓存，能够感知到 Hive Table 的元信息。当客户数据按照时间分割成不同 partition，缓存系统会在启停任务时将最近一周的数据提前缓存在缓存介质里，这样任务只会读到缓存里的热数据。针对企业级用户，一些客户极端场景可能会通过上述特性节省 25%-30%的计算资源。因为计算资源在跨节点远端读数据的过程中会阻塞很多计算线程，也就是说，缓存系统不仅仅释放存储压力，更重要的是让计算资源更快地将作业进去下去。GooseFS 下一步会提供 Hudi 和 Iceberg Table Level 预热支持。在很多批流一体场景中，流式数据延迟的情况是比较频繁出现的，上述特性可以降低此类场

268、景中的成本负担。数据端加速器针对 AZ 提供了数据本地化支持。用户只需要知道一个新的 Endpoint 就可以方便地使用。如果出现 miss cache，加速器就会从 COS 回源。142腾讯云技术实践精选集元数据一致性是大数据领域的一大痛点。例如，List 不成功往往会导致 Hive 任务卡死，rename 不成功会导致 Spark 任务在前期做的所有 MapReduce 进程都要全部重试。如果 rename 都失败，可能会有一些节点挂掉，整个集群都需要重启。所以 list 和 rename 是存储计算分离架构中导致效率低下的主要原因。腾讯云的元数据加速器将 Metadata Store 改

269、成了树形结构，新加入了文件系统级别的管理，旨在降低诸如新建目录等操作的成本。未来元数据加速器还会提供文件桶，其自带降冷备、生命周期管理操作、以及很多对象存储所需的增值特性，满足大数据、AI 等场景的客户需求。下面分别介绍 GooseFS 的一些独有特性。GooseFS Namespace 的逻辑类似 Hadoop Namespace，可以挂载到底层存储空间或私有化存储上。一套 GooseFS 缓存可以将公有云数据和私有化数据同时藏在缓存文件系统之后。假设业务场景需要公有云数据和私有化数据同时服务一些作业，GooseFS Namespace 就可以起到比较方便的作用。目前 GooseFS 后台支

270、持普通的 COS、云上 CHDFS 服务、CSP、TStore 等私有化服务。GooseFS 还支持数据湖结构化，客户执行 ETR 任务，用 Flink 将数据导入到缓存的同时，GooseFS 可以实时从 CheckPoint 之间更新的增量中提取一些特征服务一些查询作业。同时 GooseFS 也支持云原生部署和使用，利用开源 Fluid 组件，K8s 服务可以将 GooseFS 缓存 Pod 和计算 Pod 部署在同一个宿主机上，Pod 的生命周期也可以保持一致，GooseFS 本身也支持 CSI 挂载模式，大大简化了 K8s PV 挂载和销毁操作。因为 GooseFS 支持云原生，所以在部

271、署形态上支持 EMR，可以用 Yarn 来调度它的 Master 和 Worker。GooseFS 还支持 TKE（腾讯的 K8s 服务），整体思路与 EMR 类似。大数据与 AI 下的数据湖架构案例以某实时训练平台为例，类似场景中在机器执行 TensorFlow 任务时，内存消耗量往往并不大，但服务器为了支撑 GPU 资源却分配了很多内存，所以 GooseFS 缓存系统能够充分利用客户已购买的机器上剩余的内存资源提供数据端加速，从而提升训练效率。143腾讯云技术实践精选集GooseFS Table 在大数据场景应用较多。该特性基于 Hive Table 和 Table partition 级

272、别进行缓存，主要针对离线周期性作业和数据量比较大的资源。某 OCR 搜索框架实例利用了 GooseFS 提供的分布式缓存框架，充分利用了闲置内存来降低任务时延。在没有分布式缓存框架支持时，由于每个特征库分配的搜索场景各有不同，所以会存在数据倾斜问题，而 GooseFS 能够更好地利用剩余内存资源，解决数据倾斜问题，提升跨节点搜索效率。在自动驾驶场景中，经常出现的问题是小图片文件特别多，因而解析过程很长、碎片文件极多，且海量小文件的加速特别消耗内存资源，甚至会挤占计算作业的内存分配。为此，腾讯云先做了一项前期的优化，将很多内部有关联的小文件拼起来合并进一个 tfrecord。第二项优化利用了 G

273、ooseFS 本身的缓存，利用 GooseFS 加上小文件合并的优化之后，系统效率可以达到理论上限的 95.6%。这里的经验是很多机器学习场景中大量数据是只读不删的，使用缓存能够抵消很多反复读取的开销。最后，腾讯云还通过 GooseFS 为有混合云需求的客户统一了公有云和私有云的服务，提供完整的混合云体验。通过这种方案，客户就可以将敏感数据保存在私有云中，并在执行训练作业时调用公有云的非敏感数据与私有云的敏感数据，同时避免敏感数据泄露的风险。144腾讯云技术实践精选集前端业务架构PART 03145腾讯云技术实践精选集腾讯实时音视频（Tencent Real-Time Communicatio

274、n，TRTC）是腾讯云基于 QQ 在音视频通话技术上的积累，它还结合了腾讯浏览服务 TBS WebRTC 能力与腾讯实时音视频 SDK，为用户提供多平台互通、高品质、可定制化的实时音视频互通服务解决方案。目前腾讯云团队正在开发 TRTC Web SDK 新架构。在 2021 年GMTC 全球大前端技术大会【深圳站】中，来自腾讯云的高级工程师，音视频 Web SDK 开发李宇翔，重点分享了新架构中运用了哪些设计思想和技巧，来提高程序的性能和代码的可维护性。TRTC Web SDK 新架构设计解析李宇翔 腾讯云高级工程师&音视频 Web SDK 开发目前在腾讯云从事 TRTC 的 Web 端技术研

275、发工作。80 后老程序员，热爱技术，乐于分享，2006 年毕业后就进入视频会议行业，有多年音视频领域的技术积累，先后在苏宁、vivo 从事前端架构和管理工作。著有开源软件 Monibuca、Jessibuca 等。146腾讯云技术实践精选集背景介绍腾讯云的 TRTC 产品主要提供了音视频领域的一些基础功能，并通过 SDK 供用户使用，用户可以使用 TRTC 提供的底层能力构建自己的产品。TRTC 提供的能力主要分为终端和云端两个部分：云端部分均基于腾讯云，而终端部分覆盖了主流的 Windows、macOS、iOS、Android 等原生端，以及小程序等 Web 端。WebRTC 是 TRTC

276、SDK 使用的开源解决方案。WebRTC 本质上是前端可以调用的中间算法与模块，对前端工程师而言，相当于一个封装到浏览器内部的黑盒。WebRTC 方案有自己的优势和劣势，优势包括无需插件即可运行、前端开发难度低、开源免费、自带 P2P 功能等。而 WebRTC 方案的劣势也比较明显：1.编解码器是封装好的，无法自定义；2.传输方式固定，无法自定义；3.服务端需要适配 WebRTC，即便云端有很多自制功能，接入了自有体系，依旧需要通过WebRTC 实现沟通；4.WebRTC 无法运行在 Worker 中，只能运行在主线程上。为了解决上述问题，腾讯云团队自行开发了一套 WebRTC 的替代方案：该

277、替代方案主要分为算法层和传输层两部分：传输层的选择更加灵活，支持现有和未来出现的各种 Web 传输方案，如 DataChannel、WebSocket、WebTransport 等；算法层面支持 WebRTC 的所有模块，通过 Webassembly 的方式在浏览器运行，从而支持自定义编解码。该方案要求 M94 版本以上的浏览器环境，考虑到目前 M94 刚刚发布不久，就已经有 40%的占有率，这个方案的兼容性是比较乐观的。新老架构对比从下图中可以明显发现，新旧方案 SDK 使用的主要技术是有一些差异的：147腾讯云技术实践精选集从架构层面来看，WebRTC SDK 的架构如下图所示：可以看到

278、Client、LocalStream、RemoteStream 是对外暴露的部分，为了实现平稳迭代升级，如下图所示，新方案的第一个版本整体架构没有变化。在改造过程中，团队还对原有的开源代码做了优化。以 Client 类为例，原始代码多达 3500 行，现在经过分层优化实现了大幅瘦身。老方案的代码以 JavaScript 为主，很容易出错，所以新方案转向了 TypeScript。TypeScript的强类型检查、148腾讯云技术实践精选集如何解决性能问题向新方案第一次迁移的过程中，团队就遇到了性能问题，其原因在于主线程的压力过大。典型的前端脚本执行机制如下图所示：引用跳转、类型约束等特性可以明显

279、提升开发效率。与此同时，TypeScript 可以支持渐进式迁移，项目无需一次性全部转换到 TS，迁移成本非常低。149腾讯云技术实践精选集一般情况下，浏览器以 60hz 的速度渲染页面，每 16ms 渲染一次 UI 并执行脚本，16ms 中剩余的时间 CPU 会空闲，但由于界面特别复杂，渲染耗时过长，脚本执行时间就会不足，导致脚本无法正常执行：第二种情况，JS 代码中包含了 wasm 执行部分，导致脚本执行时间过长，留给渲染的时间减少，就会导致渲染卡顿的现象。为此，新方案选择用 Worker 分工方式来降低 CPU 占用。主线程主要做渲染与采集，其它工作尽可能放到 Worker 中执行。Wo

280、rker 中有定时器可以做到精确执行，不受 UI 线程渲染影响。加入 Worker 后整体架构如下图所示：150腾讯云技术实践精选集其中 Worker 线程负责与后端网络通讯，后端先同 Worker 通讯，Worker 再把一部分数据传给主线程。这里的设计原则是尽量减少线程间通讯，避免主线程与 Worker 之间通讯过于频繁增大开销。为此，Worker 端需要更为复杂的设计，包含了大部分耦合度较高的主要逻辑：151腾讯云技术实践精选集优雅管理生命周期生命周期是指一件事情从开始到终结的完整周期，例如进房到退房、发布到取消发布、订阅到结束订阅等。其中，能够被用户感知到的周期（如进房到退房）称为宏观

281、生命周期。在开发环境中，一些复杂页面可能并没有明显的开始与结束的区分。如果程序开发中出现大量生命周期，其中存在众多异常情况，程序就要在每一种生命周期出现异常时做判断。如何以更好的模式，优雅地管理这些生命周期，是新 SDK 架构面临的挑战。除宏观生命周期外还有微观生命周期。以一场分享活动举例，活动开始到结束的过程相当于程序启动到退出的过程。每一位参会者都有自己独立的生命周期，就像程序中每一个生成的对象都有自己的生命周期。正常情况下，分享活动会按照流程有序推进直到结束，但有时遇到天气、灾害等不可抗力的因素时，活动就需要立刻结束，这就相当于程序中的突发事件导致生命周期发生了变化。为了更好地处理微观生

282、命周期，团队引入了 ReactiveX 响应式编程技术。响应式编程其实就是发布订阅者模式。上图左边的观察者与右边的订阅者形成了一个宏观生命周期。左边开始订阅，生命周期开始；左边的发布者发布结束，生命周期就完成。中途出现异常或者取消订阅，生命周期也会终结。152腾讯云技术实践精选集从上图的代码视角来看，左侧程序主要采集生命周期，用来采集音视频数据，右边代码负责编码。这两者形成了一个生命周期，先采集数据然后编码，两者互相依赖，出现异常时，例如编码生命周期突然结束，就需要通知采集周期同样结束，反之亦然。使用 ReactiveX 可以清晰地撰写上述生命周期相关的代码，这种编程方式与常见的事件驱动编程模

283、型是有很大不同的。在事件驱动模型中涉及大量回调，程序开发的视角类似于一场活动的主办方视角。主办方要事无巨细地关注活动中的所有细节，开发者也需要对每一个事件的所有逻辑做好处理，这样才能保证程序正常运行。而发布订阅模式可以称为参与者视角。每一位参与者只关心最终的调遣，比如通知演讲人演讲即将开始，演讲人不用关心之前发生了哪些事件，只要在通知自己开始的时候上台演讲即可。演讲结束亦是如此。这种参与者视角不直接处理回调，而是将原来的回调转化为一个信号，各个信号再自由组合成需要的信号。组合完成后的信号就是最后要处理逻辑的事件。在 ReactiveX 三极管模型中，有一个主信号不断发出数据，还有控制信号用来终

284、止主信号和响应逻辑。主信号、响应逻辑和控制信号等都有自己的微观生命周期，它们整体形成宏观生命周期。宏观生命周期结束时，就可以通知所有微观生命周期自动结束。宏观生命周期可以通过控制信号控制，而所有的控制信号也是信号，可以被其他控制信号所控制。各种控制信号的组合最终可以实现级联控制：153腾讯云技术实践精选集为了让整个过程更加优雅无痛，团队引入了 Go 语言中的 Context 模型，它是一个可以取消的轻量对象，可以携带少量数据、级联结束，还可以被传递和持有。例如进房之后，首先创建 roomCtx，推拉流都依赖于 roomCtx，推拉流操作都可能中途启动或停止，但如果 roomCtx 退房就要结束

285、所有周期。传统代码要在退房代码中写很多判断，比如退的时候判断是否正在推流，如果是就停止推流，等等。改用新方式实现会优雅许多，在退房的回调函数里只写一行代码取消 Context，它取消会触发子级 Context 全部取消，自动将其他微观生命周期全部终止。这样就无需关心其它生命周期的状态，只需关心 Context 是否结束即可，就实现了更优雅的生命周期管理，有效减轻了开发过程中的心智负担。目前这套 SDK 新方案还在开发之中，预计在性能、稳定性等指标上会有明显提升。154腾讯云技术实践精选集云剪辑是腾讯云创多媒体引擎产品矩阵中的剪辑产品。在云剪辑服务中，实时渲染引擎是关键的底层技术。在探索与落地在

286、线剪辑工具的过程中遇到了不少挑战：如何设计高效的实时渲染架构？如何实现复杂的视频效果？如何保证页面性能与导出质量？在 2021 年GMTC 全球大前端技术大会【深圳站】中，来自腾讯云的高级工程师，云创多媒体引擎剪辑模块负责人成锐林，分享了云剪辑实时渲染引擎的设计理念与技术细节。云剪辑实时渲染引擎设计成锐林 腾讯云高级工程师&云创多媒体引擎剪辑模块负责人当前在腾讯云音视频从事视频剪辑工具开发工作，在前端编辑工具领域有一定积累，目前较多关注前端多媒体技术及相关行业应用。155腾讯云技术实践精选集云创多媒体实时渲染引擎云创多媒体引擎的产品矩阵包含协同审片、在线剪辑、云直播等产品。本场分享主要介绍视频

287、剪辑相关内容。视频剪辑主要有在线视频剪辑、小程序视频剪辑和模板视频剪辑几个业务场景，用户可以在浏览器、微信小程序里剪辑视频，也可以通过视频模版快速批量生产视频。云剪辑有三大技术特点：第一，要求实时预览，对画面的调整能够实时展现给用户，这对渲染引擎的设计有一定要求；第二，交互比较复杂，主要是媒体资源操作、时间轴操作以及视频画面元素操作，保证操作的流畅性和数据的稳定性都是重要的内容，这对前端页面逻辑的设计有一定要求；第三，多端渲染、Web 渲染、小程序渲染和服务端渲染需要保证效果一致性。实时渲染引擎由轨道数据和时间驱动渲染，通过上述架构设计来保证渲染准确性和实时性。通过游戏的架构，为后续各种素材、

288、特效的补充提供了很大的拓展性，能够支撑各种复杂的业务需求，父子关系分层树设计也是一个关键点。156腾讯云技术实践精选集帧画面的更新分为播放行为与用户操作行为，每一帧更新前会做一些渲染准备工作，找到时间轴上当前应该被渲染的元素、不应该被渲染的元素以及根据预测即将被渲染的元素，均称为 Clip。首先由 Preloader 进行元素关键内容的预加载，并放入缓存中心，其次找出所有当前时刻应该被渲染的 Clip 进行画面更新。Clip 的生命周期主要有载入、更新和销毁，Clip 的底层由 BaseClip 进行基础属性和操作行为的支撑，例如元素宽高、位置等基础属性的设置，拖拽、缩放和旋转等基础操作，以及

289、提供资源加载等必要逻辑。该引擎大量使用 WebGL Shader 实现视频效果的添加，如特效、转场、蒙版、出入场动画等。157腾讯云技术实践精选集设计好渲染引擎的 ShaderController 模块后，会对基类 uniform 进行一个严格的约束，编写的时候需要使用约定的 uniforms，在程序中可以使用各种通用方法，例如计算比例、计算位置、计算取色、计算进度、计算缩放等等，在传入 WebGL 程序时，把这部分的代码与编写的渲染主逻辑代码进行合并封WebGL 绘制流程有如图所示步骤。WebGL 本质上是基于光栅化的 API，光栅化是把顶点数据转换为片元的过程，片元中的每个元素对应帧缓冲区

290、的一个像素点颜色，WebGL 只关注投影矩阵的坐标和颜色两个方面的内容，有两种着色器，顶点着色器可以提供投影矩阵的坐标，片元着色器可以提供投影矩阵的颜色。主要代码逻辑会聚焦在片元着色器上，也就是计算每一个像素点应该呈现什么颜色，下面通过一个常见的转场效果来让大家了解到背后发生的事情。158腾讯云技术实践精选集编辑器包括素材管理、剪辑轨道和预览器三大模块。在素材选型环节，我们引入的每一种素材都经过了仔细地调研和思考，不允许使用有特定环境依赖的内容，例如浏览器环境的 DOM 元素，这样的约束让渲染引擎能有更多场景应用的可能性。剪辑轨道部分通过大量的性能调优工作来保障用户体验。此外，编辑器还支持自定

291、义素材，可以与行业工具结合，将后者生成的素材导入编辑器进行视频创作。该剪辑项目前端基于 Vue 构建，所以离不开 Vuex 的使用，其中的 EventBus 负责组件间的通信，降低模块耦合度，设计要求是所有子组件不可以直接触达 Vuex 以保持组件的高内聚。装，降低编写 Shader 复杂度。渲染引擎不是一个独立的存在，它需要配合轨道数据才有意义，拼装轨道数据就离不开编辑器的部分了。159腾讯云技术实践精选集时间轴模块就是上述 Vuex+EventBus 设计模式的一个经典应用。视图数据提交到视图中控形成主体，所有轨道元素通过 Vuex 计算，用户行为触发后进行元素更新，这种设计模式可以明显提

292、高剪辑流畅度，同时这种高内聚设计使得时间轴模块可以在直播剪辑、AI 剪辑等页面得到很好地复用。有了操作逻辑自然离不开所操作的对象，在媒体元素导入这部分也有一些有趣的设计。市面上 Web 剪辑工具的资源管理有两种模式，一种是纯云端模式，另一种是纯本地模式。纯本地模式的问题是可能出现轨道的丢失，需要用户重新找回资源。但纯云端模式也有问题，需要等待文件上传、转码完成后才能使用素材，影响用户体验。于是项目引入了本地云端双模式来支撑剪辑工作流，一个文件导入后可以先截取封面、雪碧图，用户可以无需等待立即开始剪辑，待文件全部上传完成后再使用云端资源更新轨道数据，从而增强用户体验。用户可能需要添加一些商业化的

293、特效、素材，可以通过素材制作工具制作团队素材，用户在自己的专属平台上添加素材后，所有团队成员都可以使用这些素材，并且可以分发到小程序上使用，视频模板也可以在多端使用。在视频导出环节，以 OpenGL 作为基座，通过 WebGL 胶水层实现渲染逻辑的复用。160腾讯云技术实践精选集在这个架构中，一个渲染进程驱动程序运行，封装编解码拓展、共享内存拓展。得益于渲染引擎分层架构的设计，渲染部分的逻辑可以得到很好的复用。共享内存拓展用于音视频帧数据的传递，编解码拓展被渲染主进程所调度。得益于渲染引擎的帧精确设计，在所有端都能实现精确的渲染效果。引擎会判断哪些帧应该被什么逻辑调度（编码/缩放/转场/叠加等

294、），根据复杂程度进行不同的渲染调度以确保效率。离线调度框架会完成所有片段的封装和转封装工作，进而完成视频的生产流程。161腾讯云技术实践精选集技术展望WebCodecs 是 Web 端新一代的高效编解码技术，它的出现让浏览器音视频业务有了无限的想象空间。为了确保发布的质量，引擎的每一个基础功能（视频拼接、转场、裁剪、特效等）都通过轨道数据生成基础用例，这个基础用例就是该轨道数据产生视频帧雪碧图，截取频率是一秒一张。在构建环节根据轨道数据生成新的视频帧雪碧图与用例雪碧图进行图片相似度比对，来确保新的迭代内容没有影响到原来的所有功能。但用户行为可能会非常复杂，可以在轨道上叠加无数元素，叠加出来的效

295、果可能是意想不到的，所以增加了影子旁路环节，在迭代的预发布阶段启动影子系统，通过真实环境产生的雪碧图和影子任务产生的雪碧图进行比对，来发现新版本是否存在渲染问题，这个流程能够很好地保障渲染引擎的发布质量。用户可以通过以下几种方式接入云渲染能力：剪辑 PaaS：IFrame 接：快速整合剪辑页面所有能力，并支持多种定制化配置媒体资源互通：可与客户媒体资源高效互通组件化 SDK：模块化：轨道元素与剪辑能力模块化封装，用户可自行设计前端交互进行轨道数据的组装实时预览：播放器 SDK 实时预览组装的轨道数据服务端 API：协议导出：提供 API 底层能力供自主组装轨道协议进行视频导出模板导出：在模板轨

296、道数据基础上进行资源的替换，批量生产视频程序插件：模板互通：通过在 Web 页面制作通用素材、模板，小程序端使用与分发导出互通：小程序支持本地导出，也可通过云端导出实现更高的效率与更优画质162腾讯云技术实践精选集上图是纯浏览器端无 wasm 依赖的视频制作流程。输入一个媒体文件，对其解封装，解析出来视频轨和音频轨，提取 samples 为 WebCodecs 提供 encodedChunk 数据，之后数据通过 VideoDecoder 进行解码工作，解码后会在它的回调函数 output 中返回 VideoFrame 对象，VideoFrame 和 AudioData 都只是轻量级的 Java

297、Script 对象，但它们持有对更重内存的引用例。如实际的像素数据或 GPU 缓冲区，所以要注意释放的时机。拿到解码后的视频帧数据就可以为其添加各种视频效果了，处理后的结果再封装成 VideoFrame 交给 VideoEncoder，在编码器回调函数 output 中得到 encodedChunk，就可以进行视频的封装工作了，这就是 WebCodecs 与视频制作的整体流程。但目前 WebCodecs 也不是很完善，例如 WebCodecs 音频编码还仅支持 opus。因此，要封装出来被主流播放器所支持的 MP4 文件，还需要通过例如 ffmpeg wasm 对音轨需要多一步转码过程，aac

298、 编码已经在 WebCodecs 的工作计划中了，未来可期。对 WebCodecs 未来发展还是有不少展望的，例如加入编码缓冲区配置、帧对齐解码、HDR/HEVC 支持等。我们会做好技术储备，与视频工作流整合为客户创造更好的体验。163腾讯云技术实践精选集跨平台开发架构是前端开发的热点主题。腾讯云团队在积极探索 Flutter 等跨平台开发框架，并将其应用在了音视频处理 SDK 的开发中，使用户可以利用跨平台 SDK 快速开发多端音视频处理应用。在 2021 年GMTC 全球大前端技术大会【深圳站】中，来自腾讯云的高级工程师，音视频跨端负责人牛赞分享了利用跨终端框架如何进行实时音视频渲染，并深

299、入底层优化视频渲染的性能。音视频跨平台应用与元宇宙未来畅想牛赞 腾讯云高级工程师&音视频跨端负责人2015 年加入腾讯，先后负责过王者荣耀、英雄联盟竞猜、QQ 会员等业务，目前负责腾讯云音视频 TRTC 跨终端框架 SDK的业务研发工作。164腾讯云技术实践精选集跨平台技术演进当前，跨平台开发框架是前端开发行业非常流行的开发技术。跨平台框架为开发工作带来了诸多优势：一次开发、多端运行；组件复用、提升效率；节省公司人力成本；节省开发者学习成本等等。在 Hybrid App 阶段，其依托于前端环境，开发迭代速度非常快，但它受限于 WebView，性能比较差。2015 年 ReactNative 诞

300、生，核心改变是抛弃了低效的 webview 渲染，而是转成 Native 控件，交由系统进行绘制，这样既保留了前端这套开发体系，又最大限度的保证了渲染的性能。2018 年谷歌推出了 Flutter 框架，一套代码可以构建多平台应用，支持热更新，方便开发者快速开发调试。它的底层基于 dart 语言，可以同时支持 JIT 和 AOT 编译，其自渲染引擎可以让跨平台应用性能达到原生水平。从业界指标来看，今天 Flutter 的热度趋势已经超过了 ReactNative，是目前最被看好的跨平台方案。需要强调的是，Flutter 开发与 Web 开发存在一些差异。例如下图所示：右图给一个 DIV 元素块

301、定义一些居中属性，可以定义一些 CSS 样式。但 Flutter 有所不同。在 Flutter 的世界里，所有的底层组件是一个个小部件，比如一个居中属性、一种字体颜色，或者一个布局属性等。例如要写一个居中样式，可能就要把 Text 的文本块包裹在 Center 下，因此 Flutter 的设计机制要求开发者在组织代码语言时，尽量把 UI 组件拆分得足够细。因为它没有样式与分离的概念，写代码很容易嵌套。165腾讯云技术实践精选集Flutter 视频渲染及 SDK 接入提效TRTC Flutter SDK 基于原生 Android 和 iOS SDK 进行封装，音视频底层的音视频采集、编码、解码能

302、力可以被 Flutter 直接复用。另外考虑到 Flutter 后续可能支持更多的平台，我们将实现层设计的更加具有扩展性。为了方便开发者使用我们 API，我们将美颜/设备/音效相关的 API 都聚合在一起，更加易用，视频渲染部分也做了很多优化，GPU 性能基本能达到原生 SDK 的水平。接下来，从 SDK 视频渲染性能和 SDK 接入效率两个方面，来介绍下我们面临的挑战和解决方案。第一个挑战点是视频在 Flutter 里如何渲染？如果我们要用 Flutter 定义的消息通道机制来实现这个功能，就需要将摄像头采集的每一帧画面数据从原生传递到 Flutter 中，这样做代价将会非常大，将图像帧数据

303、通过消息通道实时传输，必然会引起 CPU 和 GPU 的巨大消耗。为此 Flutter 提供了两种机制实现这一功能。第一种方案是外接纹理，它可以将原生端 opengl 图像数据共享给 Flutter 进行渲染，需要原生 SDK 提供视频帧图像数据回调接口，实现较为复杂；第二种方案是 PlatformView，主要适用于 Flutter 中不太容易实现的组件，如 WebView、视频播放器、地图等，给 Flutter 提供了嵌入Android 和 iOS 平台原生 view 的能力。166腾讯云技术实践精选集底层 Android SDK 提供了一个视频渲染的组件，视频渲染的画面会画到这个 vie

304、w 上，我们要做的就是利用 PlatformView 的能力把安卓的 view 嵌入到 Flutter 去。PlatformView 对应于安卓其实是 AndroidView，AndroidView 组件的第一个参数用于和 Android 的 view 建立关联，在 view 创建好后，通信层会把这个 viewId 回调出来，Flutter 根据 viewId 找到对应的 view 并渲染出来。按照 PlatfromView 实现的官方文档操作和设置之后，视频画面就能显示出来。但用一部低端设备测试时发现，房间有 6 个用户的时候，第二屏画面会出现异常情况。利用 perfdog 性能狗工具进行性

305、能分析后，发现 GPU 占用非常高，影响了视频画面的绘制。于是，我们先从视频列表进行优化。ListView 默认不支持懒加载，这里通过 ListView.builder 支持懒加载，并去掉默认的预加载支持，更进一步优化对非可视区域视频进行回收，比如访问到第二屏的时候，停止对第一屏视频的渲染，优化之后视频画面得以正常显示。第一阶段性能优化之后分析发现，Flutter 的 CPU、内存占用与 Android 原生占用接近，但 GPU 差距比较明显。同时渲染四个画面，Flutter 占用比原生 SDK 差了约 15%。于是团队从 PlatformView 的底层实现原理入手开始优化。对于 Andro

306、id 来说，在虚拟显示模式下，它的底层也是用外接纹理来渲染的，中间多了一层附加的图形缓冲区，它会将原生 SDK 视频 view 的每个像素都流经中间图形缓冲区，渲染成纹理图像数据，然后输出到 SurfaceTexture，这里的 SurfaceTexture 相当于一个画板，会浪费显存和绘图性能。优化思路是将视频的帧数据直接输出到 SurfaceTexture 上，这需要原生 SDK 把采集好的音视频数据不直接绘制到原生 view 上，而把视频的纹理数据一帧帧回调出来。这样就能通过 opengl 将视频帧数据直接输出到画板上，绕过缓冲区。167腾讯云技术实践精选集比如，有远端用户进房，本机通过

307、云服务收到进房信号，调用 Flutter SDK 发出开始拉流指令，SDK 进而会调用原生 SDK，原生 SDK 把视频 view 一帧帧的视频画面回调出来，最终输出到 SurfaceTexture 上，Flutter 最终拿到通信层返回的一个 textureId，这个 textureId 是在原生侧绘图数据对应的 ID，通过 ID 可以直接在 GPU 中找到相应的绘图数据并使用，最后绘制由 Flutter 的渲染引擎完成。上述优化完成后，GPU 性能提升了约 10 个百分点，基本接近 Android 原生 SDK 的性能水平。168腾讯云技术实践精选集第二个挑战点是客户接入如何提效的问题，原

308、始的 SDK 有很多 API，学习理解这些 API 的成本是非常高的。客户之前要接入业务通常都需要比较久的耗时，基本上都需要两三个月的时间。为了加速客户的接入流程，团队建设了一系列场景化方案，让客户可以参考这些场景化方案实现来提升接入效率。音视频场景包括了音视频通话、多人会议、在线教育、互动直播、语音聊天室、狼人杀、在线医疗、在线 K 歌等等。设计场景方案的过程中我们采用了 UI+场景 SDK 分离的设计模式，用户可直接参考我们的 UI 界面开发，如果想自己设计 UI，可使用封装好的场景 SDK 组件开发。以一个在线教育的场景为例，该 SDK 是针对在线教育场景中，使用实时音视频 TRTC 和

309、即时通信 IM 能力的二次封装，在封装基本的音视频聊天、屏幕分享能力的同时，针对在线教育场景封装了老师开始问答、学生举手、老师邀请学生上台回答、结束回答等相关能力。这里定义的接口不超过30个，而且更加场景语义化，客户对接起来门槛就会比较低。目前已经有越来越多的公司在新项目中尝试使用 Flutter，有做互动直播场景的日本直播平台 yell live、币安、腾讯游戏青少年直播；有做教育的潭州教育、力拓飞远；还有做音视频通话的智联招聘等等。如果新业务有音视频方面的需求，那 Flutter 是一个非常不错的选择。目前 Flutter 主要应用在 Android 和 iOS 移动端双端，但 Flutt

310、er 的愿景是成为一个多端运行的 UI 框架，不仅支持移动端，还包括 Web 和桌面端。目前，腾讯团队也已经对 Web 端和桌面端做了支持，实现了基础的音视频通话功能。随着未来 Flutter 对 Web 端和桌面端的支持越来越完善，Flutter 将能够帮助开发者用一套代码打通移动端、桌面端和 Web 端。音视频与元宇宙未来畅想元宇宙的概念起源于科幻小说，描述了人们以虚拟形象在虚拟三维空间中与各种软件交互的世界。比如电影黑客帝国头号玩家都是对元宇宙畅想的实现。也因为疫情的原因，线上会议、在线教育得到迅速普及，人们在虚拟空间的停留时间也越来越长。169腾讯云技术实践精选集未来，企业视频会议体验

311、将是以沉浸感、低延迟和拟真感为特征的，可以想象这样的办公场景：人们在元宇宙的世界中可以随时召集同事面对面讨论，可以在任何地方、任何时间建立一个虚拟的会议室，所有人都能借助 AR、VR 的设备以一个虚拟的身份进入房间，彻底告别上下班通勤和面对面社交，完全在虚拟的世界中办公、开会和协作。这样的场景该如何实现呢？这里就要提一下 Unity 跨平台的游戏引擎。Unity 在元宇宙相关的概念上早有布局，它在 2020 年提供了 MARS 工具帮助开发者快速开发 AR 应用程序，再结合腾讯云提供的音视频 Unity SDK，可以帮助开发者快速实现在游戏中的音视频通话，拉近游戏内每一位玩家的距离，增加游戏互

312、动体验，带来更好的沉浸感。随着科技的发展，音视频通信的延迟会越来越低，元宇宙的生态建设也会越来越完善，以前电影里的设想场景也会慢慢实现。170腾讯云技术实践精选集近年来，Serverless 概念的兴起有效提升了软件开发的生产效率，也让它在 web 开发领域越来越被重视。虽然 Serverless 解决了 Web 开发的后端服务逻辑和运维面临的许多问题，但没有覆盖前端和具体的应用开发领域。而对于前端和通用的应用问题，基于云原生的低代码平台可以更进一步，抽象前端 UI/交互逻辑并结合 Serverless 服务，在很多场景中帮助开发者摆脱重复交互逻辑和胶水代码的困境，让开发者能够迅速实现想法、应

313、对海量流量，实现快速产品化迭代。在 2021 年 ArchSummit 全球架构师峰会【上海站】，腾讯云云开发前端负责人朱展介绍了腾讯云云开发低代码平台的架构和实践，并说明了解决前后端应用中更高阶抽象问题的思路和方法。朱展 腾讯云云开发前端负责人主导设计开发了腾讯云云开发平台。对前端组件化、海量服务等有多年经验。目前专注于云开发低码产品的构建，致力为开发者提供稳定易用的技术产品。Serverless 时代的低代码实践171腾讯云技术实践精选集背景介绍：为什么软件开发需要低码平台根据咨询机构Gartner报告，2023 年全球超过 50%的大中企业会将低代码应用平台作为主要战略应用平台之一，至

314、2024 年，低代码开发的应用程序将占应用程序开发总量的 65%以上。由此可见，低代码开发已经成为了软件开发产业的未来趋势之一。开发领域有个很有意思的观点：开发可靠安全应用的最佳方式就是不写代码。在软件开发著作人月神话中提到，所有软件活动都包含两个任务，分别是主要任务与次要任务：主要任务就是打造由抽象软件实体构成的复杂抽象概念。次要任务则是使用编程语言表达这些抽象实体，在空间和时间限制内将它们映射成机器语言。172腾讯云技术实践精选集通俗来讲，主要任务是产品业务逻辑的定义，次要任务是实现业务逻辑的各种技术手段。拿一个电商小程序举例，主要任务是定义应用中各个概念的逻辑，比如商品、订单、用户这些概

315、念的定义，它们具备哪些属性，商品上架流程要怎样流转，用户购买商品的流程要怎样流转，这些定义了产品的最核心逻辑。而次要任务是实现产品核心逻辑的方式和手段，比如服务端我们是要用 Node.js 还是 PHP、Java，应用框架要用 koa 还是 Express、NEST；单测怎么写，文档怎么生成等等这些都是为产品目标服务的。具体到研发过程中，从代码到用户可用产品的过程分为两大步骤：第一个步骤是把代码变成产品，需要经过测试、发布等流程；第二个步骤是将产品与线上系统进行集成，与其它产品做好沟通协作工作。整个周期中需要涉及很多角色和细分步骤，比如产品需要做需求分析，设计需要做交互和视觉，研发需要做编码、

316、调试等，测试进行功能测试，运维需要进行线上服务的运维保障。经过众多角色和步骤的配合会带来额外的成本以及效率的损失，而我们面对众多需求是需要有更高效率的开发方式。低代码技术在很多场景能有效提供这种高效的开发，一般来说低代码平台会带来几个好处：封装研发任务 复杂度隔离 提供应用范式 降低开发门槛很多研发和运维的复杂任务如服务器扩缩容、安全加固等，会由平台提供封装后的服务，同时平台一般也会提供众多行业和领域的相关模板帮助应用的快速创建。整体来说，低代码平台本意是希望研发能专注于产品的主要任务。需要注意的是，低代码不像无代码那样只能专注于某一些封装程度很高的领域，无代码一般缺乏足够的灵活性，而低代码平

317、台则一般具备足够的灵活性来满足多变的需求。173腾讯云技术实践精选集低代码实践：产品研发中的封装在具体的研发工作中，开发人员一般分为前端和后端。在端侧，我们面对的问题通常是研发人力不足，很多企业都需要有自己的前端应用，但却缺乏配套的研发人力。为了解决这一问题，业内出现了很多跨平台方法来实现一次编写、处处运行的效果，例如 Web 应用、小程序等。另一个手段是组件驱动开发，组件驱动开发的思想就是把整个应用从下到上拆分成原子、分子、区块以及模板、页面。应用里最小的原子组件是不可分割的，类似标题、按钮、图片、视频等，它们必须组成分子组件才会有一定交互功能。区块组织就是一些分子组件加上一些业务数据的聚合

318、体，例如，一个表单是分子组件，加上用户权限就可以形成一个登录区块。区块组织是一个真正的功能组件，能独立承载具体的业务能力。这些功能抽象成一个模板，模板再复制成多个页面，甚至跨应用复制到其它应用里，这就是端侧组件化的基本思想。在服务端，应用部署为一个服务时，往往需要关注服务器负载、流量扩缩容、容灾、备份等能力。而这些事项是典型的次要任务，与产品逻辑之间没有必然联系，产品研发真正关注的是自身的业务逻辑。有了 Serverless 后，研发人员就不用关注底层资源的情况了。腾讯云开发 Serverless 的能力可以归纳为微信生态、弹性/隔离、扩展能力和降本增效四部分。首先，它和微信生态结合比较紧密，

319、能够复用微信的一些能力，比如免流量、安全、高性能等。它的弹性扩缩容能力会利用腾讯云某一个云服务的海量资源，按用户使用率和流量自动扩缩容。最终，Serverless 低代码平台的价值就体现在分离主要任务和次要任务，让产品研发、业务人员专注于主要任务，把研发运维的部分打包起来交给平台的专业人员来处理。174腾讯云技术实践精选集腾讯云微搭低码平台的架构设计与实践从 2020 年开始，腾讯云自研了名为微搭的 Serverless 低代码平台。腾讯云微搭低码平台的主要能力可以分为四个层级：1.多端能力，通过可视化编辑做出来的产品能够发布到小程序、Web 端上；2.扩展体系，微搭能够针对前端和后端进行自定

320、义逻辑的定义来满足各类扩展的需求；3.应用构建逻辑层包含表单引擎、数据源等，可以根据可视化配置生成相应的流程接口以及权限控制类的服务能力，直接提供给 UI、前端使用；4.承载服务的是 Serverless 云原生架构，包含云存储、云函数、云托管等。这一架构能够随意扩缩容，不使用时成本为零。最终，Serverless 低代码平台的价值就体现在分离主要任务和次要任务，让产品研发、业务人员专注于主要任务，把研发运维的部分打包起来交给平台的专业人员来处理。175腾讯云技术实践精选集微搭低码平台主要是从应用的描述和声明、动态表单、应用动态发布流程几个视角出发来设计平台架构的。所谓描述应用，在前端就是将交

321、互和视觉呈现给用户，服务端则要负责承载产品逻辑。前端要有样式和页面，页面下有组件，组件要有属性以及事件。服务端需要一些接口定义、登录设置以及数据同步给前端组件的设计。微搭用常见的 JSON 和 JSON Schema 来描述应用，即应用 DSL。在微搭里每一个应用都是一个结构化的 JSON 数据，包含上述所有前端内容。同时开发人员可以自己写一些代码来满足扩展性的自定义诉求。自定义代码可以是客户端也可以是服务端代码。服务端代码会直接部署到数据源云函数中。应用发布时会将应用 DSL 声明发布成线上服务运行的代码。微搭使用了开源工具 Cloudbase Framework 来进行应用部署，它可以声明

322、端侧逻辑代码的部署位置、服务端函数定义、函数配置、需求资源数量等等，使用这个工具可以把低代码平台预设好的前端页面以及数据接口定义，一键发布到云开发的环境上。动态表单也是低代码领域使用非常广泛的特性。一般来说，一个表单除了包含字段的信息之外，在低代码场景里还需要描述组件 UI 的信息。定义一个表单字段时，首先要声明它的字段类型，然后进一步声明它的格式和细分类型。定义好之后才能够去做组件选择以及 Ul 展示。比如说一个枚举类型可以用下拉列表和平铺单选的形式来呈现。在产品细化交互时需要通过一些声明式配置来实现这类需求。176腾讯云技术实践精选集总结下来，微搭低代码发布应用的流程分为如下步骤：关于微搭

323、低代码平台的应用运行时方面，它的数据流是从前端开始，对应的小程序、Web 等，后面是服务端都是 Serverless 运行环境，包含接入层、逻辑服务和资源层。用户从端发送一个请求，它会先经过云开发 Serverless 接入层，这里会判断用户是否有访问权限等。逻辑层承载在云函数上，负责整体的逻辑控制，管理接口、权限等内容。逻辑层下面是资源层，包含数据库、静态托管以及存储、权限等服务。平台还提供扩展能力，允许用户自己编写客户端和服务端代码，对接第三方服务。177腾讯云技术实践精选集微搭低码平台的演进方向与规划微搭发布还不到一年，是比较年轻的低码平台，现在也处于比较早期的阶段。微搭当前专注于 C

324、端的小程序端和 Web 端的低代码开发服务。未来除了 C 端之外，还会有配套的 B 端运营管理系统。用户能够用低代码的方式在管理系统中生成相应的管理功能。这里还会有一些 BI 分析、用户增长等统计信息。微搭团队还希望将来能够做到多云部署。因为 Serverless 目前与厂商绑定比较严重，所以将来要设法将云开发的产品部署到其它厂商的平台上去。微搭的另一个发展方向是用可视化的方式声明流程以及一些代码级别的任务。用户可以不用代码，用线框图来描述比较宏观的流程，在每个节点绑定表单和对应的用户权限等内容，进而翻译成代码做成产品和工作流。最后的主题则是平台解锁，云开发的端上内容并没有平台锁定的问题，用户

325、本来可以部署到任意一个静态托管上。唯一有问题的是平台锁定的点，涉及云开发 Serverless 的一些特殊接口，包括用户登录、函数、存储，以及数据库等四类接口。如果能在本地适配云开发在云端的一些行为，比如，云开发里的 Code Function 也能够在本地，实现类似的能力，就可以很好地开展低代码平台后端的多云适配工作，最终完成平台解锁的目标。178腾讯云技术实践精选集架构设计PART 04179腾讯云技术实践精选集随着近年来 Node.js 以及其相关生态的成熟，业界各大前端团队也逐步将 Node.js 落地到实际业务中，但要将 Node.js 服务做好并不容易：性能优化、应对峰值大流量、高

326、可用保障等等都需要长期的建设与打磨，业界相关的经验也较少。腾讯云 CloudBase 团队从创立之初就选用了 Node 相关技术栈来开发核心数据流服务，目前每天承载十亿以上的流量，服务了下游多个公有云产品。在 2021 年GMTC 全球大前端技术大会【深圳站】中，腾讯云 CloudBase 前端负责人王伟嘉发表了题为十亿级 Node.js 网关的架构设计与工程实践的演讲，以 CloudBase 核心网关为出发点，讲述海量 Node.js 服务的整体架构设计思路，以及如何进行性能优化以及高可用保障。十亿级 Node.js 网关的架构设计与工程实践王伟嘉 腾讯云 CloudBase 前端负责人毕业

327、于复旦大学，现任腾讯云 CloudBase 前端负责人，Node.js Core Collaborator，腾讯 TC39 代表。目前在腾讯云 CloudBase 团队负责小程序云开发、Webify 等公有云产品的核心设计和研发，服务了下游数十万开发者和用户，对 Node.js 服务架构、全栈开发、云原生开发、Serverless 有较丰富的经验，先后在阿里 D2、GMTC、腾讯 TWeb 等大会上发表过技术演讲。180腾讯云技术实践精选集网关快速入门CloudBase 网关介绍网关这个词到处都在用，它可以工作在硬件层，也可以工作在网络层，还可以工作在应用层。本文主要讨论工作在七层的网关。它主

328、要做的事情包括：作为公有云服务的入口，可以把公有云过来的请求定向到用户的资源上；对接后端资源。云开发有很多内部资源，它可以把请求对接到这样的云资源上；做身份鉴权。云开发有自己的一套身份鉴权体系。请求过来如果是带有身份的，网关会对身份进行鉴权。实践中，网关还要考虑基础框架、性能优化、日志、监控、高可用、DevOps 等一系列需求。腾讯云开发 CloudBase 是一个云端开发的底层架构，承载了多种云开发业务。CloudBase 网关内部是基于 Nest.js 来做的，它的内部架构分成了两层：一层是 Controller，主要控制各种资源的逻辑，底层是 Service，这一层非常厚，分成了几大部分

329、：第一大块是逻辑模块，主要处理内部服务模块的很多内容，最上面一层主要处理跟资源相关的请求逻辑，中间一层做内部集群的逻辑，最下面一层会有各种 Client；第二大块是旁路的功能性模块，包括打日志、本地缓存管理、本地配置管理 DNS 等旁路服务。整体设计思路就是高内聚低耦合，业务逻辑和 IO 解耦，保证可测试性。181腾讯云技术实践精选集以上是 CloudBase 网关的整体链路架构，最上层是分布在边缘的 CDN 节点，在 CDN 节点会回源到部署在各个地方的集群，这些集群又可以访问后面不同区域的资源，因为公有云的资源也是按区域来划分的。这里引出了网关的两个核心要求：首先，作为网关肯定要求速度很快

330、，延迟很低。其次，要稳定，要扛住海量的客户端请求，需要极高的可用性，快和稳分别对应性能优化和可用性提升。网关性能优化网关是网络组件，大部分时间都消耗在 IO，而不是它本身的计算上，重 IO 轻计算组件的请求模式是比较固定的，客户发送过来的请求实际上就是那么几种，很少有客户的请求是完全随机生成的请求。所以可以针对这种情况做缓存设计，整体优化方向就是减少 IO 消耗，并把整条核心链路优化好。核心服务性能优化核心服务优化的业务逻辑很多，可以把业务逻辑做异步化，让它后台运行。比如，校验的逻辑会放到后台异步进行，而不是每次请求来了实时校验。182腾讯云技术实践精选集第二个优化点是请求体流式传输，Node

331、 提供的原生的客户端里，Body 已经是 Stream 对象了，但大部分人都会默认引用 Body Parser，把 Stream 转成 Javascript 对象再处理。实际上，对于网关来说这一层是没有意义的，所以这一部分的消耗可以直接去掉，去掉 Body Parser 这一步。第三点是请求后端的时候，Nginx 这样的组件通常都是短连接模式，但实际上有些业务情况比较特殊，是大租户模式，相当于所有用户共用同一套 Nginx，再启用短连接模式就会有 TIME_WAIT 的问题，所以这里会启用长连接。当然长连接也会带来进一步的问题，又要去修复长连接的问题。最后一点就是因为请求模式比较固定，可以设计

332、比较合理的缓存机制。启用长连接机制之所以短连接会有问题，是因为请求用户资源的时候，自己的网关所在的服务是在资源上云的平面，就是自己的内部服务。但是用户的公有云资源实际上是在另一个网络平面，在公有云的 VPC 上面，这两个网络平面之间的穿透是需要走网关的。这个网关可以理解为一台虚拟设备，是四层转发的 Nginx，单实例可以承载6.5 万的 TCP 连接数。TCP 连接断开之后会进入 TIME_WAIT 的阶段，在 Linux 内核里会等待两倍的时间，默认是 60 秒，120 秒之后才会释放连接，也就是在 120 秒内，它的端口都处于被占用的状态，很容易就能算出来，单个穿透网关能够承载的最大额定

333、QPS 不到 600，肯定不能满足用户需求。解决这样问题有几种方法，一种是改它的 TCP 传输层的内核参数，启用重用、快速回收这些机制，但这需要腾讯网络侧的同事定制系统内核，成本会非常高；第二种是腾讯云 CLB 的方法，CLB 内部也是类似 Nginx 的组件，它们直接扩 VM 的数量，但这样做业务成本是扛不住的，所以也放弃了；最后一种就是改成长连接机制，单个穿透网关可以最大承载 6.5 万个连接数，相当于几乎 6.5 万个并发。对于同 IP PORT，它可以直接复用连接，所以穿透网关的连接数限制就不再是瓶颈。但长连接会导致竞态的问题，首先客户端跟服务端成功建立了长连接，之后可能有一段时间静默，没有HTTP 请求。这个连接保持但是没有请求，服务端会主动把 TCP 连接关闭掉，发送关闭的包到客户端，但客户端在收到关闭信息之前，客户端可能正好发送了新的 HTTP，请求包体出去。这时服务端的连接