1、1腾讯云技术实践精选集 20222腾讯云技术实践精选集 2022【版权声明】【参与编写单位及人员】（按拼音首字母）本报告版权属于腾讯云计算（北京）有限责任公司和 InfoQ 极客传媒，并受法律保护。转载、摘编或利用其它方式使用本报告文字或者观点的，应注明“来源：腾讯云计算（北京）有限责任公司和 InfoQ 极客传媒”。违反上述声明者，将追究其相关法律责任。作者内容编辑蔡芳芳付秋伟陈煜东 董峤术 郭志宏 胡锦前 韩硕江国龙 贾瓅园 林沐 李向辉 吕祥坤潘怡飞 孙勇福 陶松桥 童子龙 王鲁俊王涛 王福维 许文强 于华丽 杨鹏程于善游 杨珏吉 杨亚洲 赵军 张倩曾毅内容指导徐樱丹内容策划谷春雨 刘亚
2、琼 李文芳 熊艳云 赵琪3腾讯云技术实践精选集 2022卷首语2022 年，数字化转型成为了全行业关注的焦点，数字经济的价值进一步凸显。云计算作为数字时代的关键要素之一，正从单一云向多云、混合云战略过渡；分布式云服务也进入了高速发展的黄金期；随着 Docker、K8s 等容器技术的流行，云原生正成为云计算的新赛场，也成为企业数字化转型发展的“默认选项”、新底座；除此之外，人工智能、边缘计算等技术的普及进一步加速了云计算技术的变革。无论是数字原生行业还是非数字原生行业，云计算在行业数字化解决方案、产业链数据流转、资源动态配置、业务创新等方面正产生着难以估量的价值。对于腾讯的技术团队来讲，2022
3、 年也是一个重要的技术里程碑之年。历经三年，包括 QQ、微信、王者荣耀、腾讯会议等亿级用户规模的腾讯自研业务已全面上云，集群规模突破 5000 万核，累计节省成本超 30 亿，这使得腾讯打造出国内最大规模的云原生实践。如何把这些亿级业务全部搬到云上并实现云原生改造？腾讯云做了大量的技术优化和革新：比如在容器调度领域，通过混部技术将资源利用率提升到 65%；在数据库领域，通过存算分离技术，打造了国内第一款云原生 Serverless 数据库；在安全领域，借助云原生技术本身的可观测性手段，创新地与安全结合，打造了更贴合云原生技术的专业安全防护能力等等。为此也沉淀了一份 6 万多字的腾讯大规模云原生
4、技术实践案例集，包括 10 多个国民级应用的上云实践，可扫描封底二维码下载阅读。除了赋能自研业务外，腾讯云还将上述诸多产品或服务以及配套的基础软件、底层技术等开放给百万级的外部客户，全部基于公有云模式开发运营，赋能千行百业，也造就了一大批金融、游戏、企业服务、智能制造、教育等场景下的最佳实践。4腾讯云技术实践精选集 2022此外，为了解决客户上云、用云的成本之忧，腾讯云基于内外云原生成本管理最佳实践，并结合行业优秀案例，提出了一套体系化的云原生上云成本优化方法论和最佳实践路径，发布了两个业界“标准”：云原生最佳实践路线图和降本之源 云原生成本管理白皮书，旨在帮助企业改善用云成本，充分发挥云原生
5、的效能和价值。2022 年，是不平凡的一年，感恩来自行业、伙伴、团队的力量推动着我们勇往直前。在今年，我们参与了 DIVE 2022 北京站、ArchSummit 2022 深圳站、QCon 2022 广州站、ArchSummit 2022 北京站、ArchSummit 2022 杭州站等多场大会，与 1000+位技术人邂逅并分享心得。此外，这也是腾讯云连续两年推出腾讯云技术实践精选集，去年 2021 版精选集共 4 万多字，全网带来 7000 多次下载。2022 版的精选集总字数近 10 万，尤其首次收录了“腾讯自研业务大规模云原生实践”系列内容，全面解密腾讯如何锤炼腾讯云。每一次相遇，都难
6、能可贵，每一场交流，都价值满满，遂整理成文，共享丰沃。展望 2023，愿与诸君携手同行，共攀技术新峰！5腾讯云技术实践精选集 2022目录CONTENTS腾讯自研业务大规模云原生实践大数据与云数据库技术探索及实践 01 02如何管理超千万核资源的容器规模50W+小程序开发者背后的数据库降本增效实践拥抱云原生，数十万规模 GPU 卡的利用率极致优化之路TDSQL-PG 数据库在微信支付的应用实践将云原生进行到底：腾讯百万级别容器云平台实践揭秘云原生安全可观测性探索与实践大规模代码中引入供应链漏洞的分析技术前瞻腾讯云大数据 TBDS 在私有化场景万节点集群的实践PB 级数据秒级分析，腾讯云原生湖仓
7、 DLC 架构揭秘CDW PG 大规模在线数仓技术构架分享云原生数据库管控探索和实践1.2.3.4.5.6.7.1.2.3.4.080566573806腾讯云技术实践精选集 2022云成本优化与研发提效 03企业上云，云上资源整体成本优化管理如何做？企业如何利用云厂商能力构建自己的分布式云？从混部到 Serverless 化，腾讯自研业务的稳定性及云原生成本优化实践Serverless 时代下，企业微服务的降本思考与实践腾讯课堂面向协作的 DevOps 流程设计与实践1.2.3.4.5.511126中间件与基础设施 04Kafk
8、a Stream 的进化探索：流式 Serverless 计算JVMTI Agent 在中间件领域的应用区块链如何支撑 Web 3.0腾讯操作系统的创新之路腾讯明眸媒体处理实践1.2.3.4.5.0201腾讯云原生数据库 TDSQL-C 架构探索和实践金融级分布式数据库 TDSQL 升级版引擎架构和关键技术介绍国产金融级分布式数据库在金融核心场景的探索实践腾讯云 MongoDB 智能诊断及性能优化实践腾讯云数据库云上 SaaS 生态演进5.6.7.8.9.7腾讯云技术实践精选集 2022腾讯自研业务大规模云原生实践018腾讯云技术实践精选集 2022仅用三年时间，基于腾讯
9、云 TKE 底座，腾讯自研业务容器化规模已达到千万核级别的 CPU 资源规模。面对如此海量的异构资源和复杂多样的业务场景，腾讯是如何做到资源利用率 65%的？在调度编排、弹性伸缩、应用管理、稳定性保障等方面，腾讯又有哪些秘籍？在 ArchSummit 2022 全球架构师峰会（深圳站）上，腾讯云自研上云容器平台负责人王涛发表了题为如何管理超千万核资源的容器规模的演讲，为大家逐一揭秘。腾讯自研业务容器化上云历程腾讯自研业务容器化上云的技术路线经历了多个阶段。最开始是一个虚拟机只调度一个容器的上云实验阶段，我们叫胖容器阶段；再到富容器，一个节点多个 Pod，Pod 中有多进程的阶段；然后是单 Po
10、d 单进程的微如何管理超千万核资源的容器规模王涛 腾讯云自研上云容器平台负责人腾讯云 TKEx 容器平台负责人，8 年 K8s 生产经验，从 0 到 1 建设 TKEx 平台，全程支持腾讯海量自研业务容器化上云。9腾讯云技术实践精选集 2022服务容器阶段；现在在腾讯内部也有大规模的容器使用 TKE Serverless，再往后为业务提供 FaaS 的能力。整个阶段都在夯实混部技术，包括离线混部、在线业务混部。Service Mesh 也得到了一定规模的实践。上图是自研上云涉及的相关产品的简单架构。最底层是 IaaS 腾讯云计算网络存储，往上层的基础服务主要是 Kubernetes、ETCD、
11、Helm，再往上是腾讯云的产品化服务，包括腾讯 TKE 产品、TKE Serverless、Edge、TKE-STACK。TKEx 容器平台服务腾讯内部业务，内部入口可以直接是容器平台或者研效平台。经过三四年的大规模自研业务上云过程，我们已经在各个技术领域沉淀了很多最佳实践和技术方案组件，诸如容器调度、弹性伸缩、有状态服务、容器化、资源管理、稳定性提升、业务运维效率提升等都是我们沉淀或重点关注的技术。上云阶段不止是把业务容器化上云，更重要的是怎样衡量上云上得好不好。这里我们有腾讯云原生的成熟度规则来考核腾讯自研业务以及对应的容器平台做得好不好，主要从四个维度考核，最大的权重维度是资源利用率，指
12、业务容器利用率、平台资源利用率。还有弹性伸缩能力、容器可调度能力，以及申请的 Pod 资源是不是小核心的资源。从规模与成熟度曲线可以看出，最近两年时间我们实现了非常大的规模增长，云原生成熟度得分也逼近 90 分。10腾讯云技术实践精选集 2022各种混部场景下利用率提升方案在线离线混部集群在线离线混部集群是公司面临的主要混部场景。之所以要做在离线混部，是因为在线业务都会面临利用率较低、利用率有潮汐分布状态的状况。而离线作业很多是碎片型资源，可以容忍一定失败率，执行时间较短。我们的在离线混部是面向 K8s，设计原则包括通用性，方便未来开放到社区和外部客户；符合云原生方式；降低对应用依赖；兼容 K
13、8s 和 Hadoop 生态。而我们的目标包括保证在线业务的 SLO，离线作业要在负载利用率高峰期快速上下线，离线作业成功率也有一定保障，保证服务质量前提下尽可能提升资源利用率。腾讯内部在离线混部的技术方案名为 Caelus。它面向业务提供基于业务优先级的定义，接下来就当节点或集群出现负载或者干扰时，可以根据优先级来 驱逐 或抑制，对于不可压缩资源只能驱逐到负载较低的集群。高优的离线作业不会直接 Kill，而是降低容器的配置。方案最核心的是节点上 Caelus 的组件，主要做干扰检测数据的采集、分析，再决策做离线抑制还是调度。Caelus 的主要流程包括：数据指标的采集，包括来自于业务监控系统
14、的业务自定指标。采集到的指标统一存储在对应的 Store 组件，再从 Store 拉取指标做在线资源的业务预测、离线业务的健康检测。如果出现资源超发或高负载情况会做对应的抑制或者驱逐。11腾讯云技术实践精选集 2022 这里提供本地预测和中心式预测两种方式，中心预测主要通过 descheduler 的方式，先采集分析得到全维度的应用负载，做驱逐时考虑工作负载是不是做了多副本、对应的服务是否做了动态路由接入等，重调度时去衡量这些工作负载的配置，确保业务的服务质量。更重要的是本地干扰检测和快速驱逐的能力，因为这里只关注节点本身的资源使用情况，能做出更快的离线业务的驱逐避让。干扰检测的指标一部分来自
15、于应用注册的业务自定义指标，还有一部分来自平台自身获取的操作系统、节点提供的指标。处理的方式一种是直接把离线的 Kill 掉，一种是直接做限流操作。驱逐时一定要考虑业务的优先级以及业务有没有做多副本、高可用，考虑是不是已做过容灾措施。根据监控数据，我们的在离线混部的集群节点负载已经到了将近 70%的资源利用率。在线混部集群腾讯也有一些集群只能部署在线业务。这种集群要提升资源利用率会涉及不一样的技术挑战。全部是在线业务，意味着无法定义每个任务或者业务的优先级，每个业务的优先级都是一样的。那么首先要做超卖、动态 Pod 的资源压缩。在线业务混部意味着集群的负载、节点的负载可能出现分布不均匀的情况，
16、所以要解决集群节点负载均衡的问题。高负载时要及时、快速扩容资源，所以要提供极速的集群伸缩能力。12腾讯云技术实践精选集 2022还有一个关键动作是，平台或者容器的资源总是有限的，一定要有面向应用的业务配额动态管理。弹性伸缩这一层，我们自己做的方案叫做二级弹性资源池能力。第一层，平台会把各地域闲置的 CVM 放在闲置紧急 Buffer 资源池里，可以秒级地从节点把 CVM 加入集群里，实现集群秒级扩容。这里的关键是节点所有初始化流程、标准化建设都已经准备就绪，可以轻松应对集群负载突发情况。第二层就是去腾讯云申请 CVM，CVM 要做初始化流程，这一层弹性能力是分钟级的。当紧急 Buffer 池没
17、有资源时才能找腾讯云接口创建对应的资源加到集群里。面向业务的弹性伸缩，我们把 K8s 的 HPA Controller 剥离出来，自己做了 HPAPlus Controller。因为我们的应用规模非常大，一个集群里可能有几万个 Workload，意味着几万个 HPA。我们自研的 HPAPlus-Controller 做了足够的性能优化，以支持如此单集群的 HPA 性能。HPA 这里，我们还做了动态调整 HPA 最大副本数的特性。业务配的最大副本数通常是一个很主观的不可信的值，当业务 HPA 达到 maxReplicas 后仍然有持续扩容的趋势，HPAPlus 会提供 更大弹性 Buffer 能
18、力给业务，maxReplcas 能动态的自增长，还会发告警让业务赶快判断是否正常。这种 HPA 行为，我们会预留业务一定时间处理超出预期的业务流量，当然也有机制去限制 maxReplicas 的无限制自增长。我们还有 HPA 和 CronHPA 的联动决策，支持业务计划内的定时扩容，即便实际流量超过预估流量也能自动扩容。另外 VPAPlus-Controller 是用来支持有状态服务无感知垂直扩缩容场景，而不需要重建 Pod。我们的动态调度器是解决节点负载不均衡的问题。它会根据负载给节点打分，让节点关键资源在集群节点中均衡分布。我们还有自研的热点动态补偿算法，避免调度热点问题，控制好节点的 单
19、位时间 Pod 装箱数量。我们的在线业务混部利用率提升方案，让集群 CPU 平均利用率提升到 30-40%的水平。在使用动态调度器之前节点负载是不均衡的，上线动态调度器后负载相对比较均匀。我们的在离线混部、在线混部方案最后都通过 Crane 对外开源了全套技术。13腾讯云技术实践精选集 2022稳定性面临的挑战及其破解之法负载上升之后会面临很多稳定性问题，我们主要关注平台层、集群层、节点层以及业务层的稳定性。14腾讯云技术实践精选集 2022平台和集群稳定性层面有两个实践案例。第一是监控，要提升稳定性一定要有全面的监控体系。我们通过 Prometheus+Thanos+Kvass 方案，提供高
20、可用部署以及 Prometheus 的横向扩缩容能力。我们集群规模往往很大，每个集群组件很多，意味着配置项非常多。为了对每个集群的所有组件配置做好统一，确保每个集群都是标准的，不能因为某个组件没配对导致行为不一致，就需要做一些组件标准化的监控。我们研发了组件探测能力，可以看到每个组件版本是否统一，是否在做组件灰度发布，几百个集群中哪些组件出现了异常，都可以通过监控实时获取。节点稳定性是 K8s 生产环境遇到最多的问题，这里也举几个例子。第一个例子是针对一些节点上的核心组件、内核状态做对应的指标监控、节点自愈。我们基于 NPD 组件扩展了指标，通过这个组件对节点稳定性做监控，用对应的决策树做自愈
21、。这个组件也在腾讯云 TKE 组件里。节点规模大了之后会遇到各种各样的内核问题，要升级内核或者打补丁时，必须要跟踪好每个补丁是不是正常打好，对应的内核版本是不是我们当前的基线版本内核，这都需要监控、标准化和自动化。比如某些节点少打了一些补丁，我们需要自动把遗漏的补丁打上。业务稳定性方面，我们在内核层面做了很多工作，业务出现稳定性问题要看 Pod 对应内核指标是不是有异常，如果出现异常要快速调度。同一节点上的 Pods 共用内核、资源抢占的问题层出不穷，最终还是依靠演进到 Serverless K8s（TKE Serverless）这个容器产品，能够给 Pod 做到虚拟机级别的隔离能力，最终彻底
22、解决这一类稳定性问题。从面向集群到面向应用的调度编排前两三年大家更多关注的是怎样面向用户提供 K8s 的能力。接下来要重点解决的是从面向集群到面向应用的调度编排问题。这意味着用户不用再关注集群，不用关注底层资源，只需关注应用本身。有一个例子，一个业务全网有一万个工作负载，有五万个 Pod，分布在全球十七个地域，八十多个集群。如果我要对这个业务做一次全网变更，按照以前面向集群的方式效率非常低。所以要抽象出面向应用的能力，首先是跨集群应用的统一变更，要有一个统一的看板跟踪发布是否正常。业务部署后还要能从视图看到部署15腾讯云技术实践精选集 2022的容灾是不是合理的，所以要有多地域的容灾检测。所有
23、这些能力我们都是基于腾讯云的 Clusternet 开源项目来建设。Clusternet 有 2 个极其重要的多集群能力，一个是动态拆分调度，主要根据集群容量、位置拓扑来做决策。比如用户要求两地三中心，接下来在两地三中心选集群，每个集群容量不一致时要根据容量做评估。另一个是多集群协同弹性伸缩。多集群 HPA Coordinator Controller 做多集群 HPA 协同 的事情，可以根据集群容量、集群的可用性做 HPA 协同，保证业务扩容时不会因为某一个集群的资源不足扩不出来，自动调度到其他可用集群。腾讯在大规模资源上云过程中沉淀了这么多技术能力，服务了大量业务场景，包括音视频、游戏、电
24、子商务、社交、办公协同、出行等，我们正在做的是把这里积累的各种业务场景的最佳实践，都输出到云原生应用管理平台这个公有云产品中，比如应用的标准化检测、业务的 QoS 定义、应用多集群灰度发布、应用多集群自愈等等，最终将容器平台上升到应用管理维度，同时服务腾讯内部和外部客户。16腾讯云技术实践精选集 2022扫码获取完整版演讲 PPT17腾讯云技术实践精选集 202250W+小程序开发者背后的数据库降本增效实践杨珏吉 腾讯云高级工程师 TDSQL-C Serverless 研发负责人拥有多年云数据库研发经验，负责设计和研发 TDSQL-C Serverless 产品形态。作为国内第一款云原生 Se
25、rverless 数据库，TDSQL-C 目前仅在微信生态上就为超过 50W 小程序开发者提供数据库底座，凭借按量计费、超强弹性、存算分离等特性，能有效降低用户的数据库使用成本。腾讯云 TDSQL-C 这款云原生数据库相比于传统数据库有哪些技术突破？在场景实践过程中遇到过哪些问题？又是如何解决的呢？在 ArchSummit 2022 全球架构师峰会（深圳站）上，腾讯云 TDSQL-C Serverless 研发负责人杨珏吉发表了50W+小程序开发者背后的数据库降本增效实践的主题分享，围绕 TDSQL-C 在关键技术的多维突破、在实践应用中遇到的挑战及解决方案，以及在内外部用户业务上云过程中的典
26、型应用场景及收益等问题给出了解答。18腾讯云技术实践精选集 2022TDSQL-C Serverless的技术实现与自研业务实践TDSQL-C Serverless 是腾讯自研的云原生数据库。TDSQL-C Serverless 的特色是能够让企业像使用水、电、煤一样使用云数据库的服务。用户不需要为闲置的数据库而付费，用多少算多少。这项技术在很多业务场景下都能帮助企业极大的节省成本。TDSQL-C Serverless 的技术实现传统云数据库并没有实现自动扩缩容、按使用量计费、无使用无费用。这就导致哪怕我只用了 10%的计算资源，另外 90%的闲置计算资源也无法分配给其他用户，还需要为此而付费
27、。存储资源也一样，基于这种存储跟计算绑定的架构，用户需要提前购买好对应 CPU 和内存的数据库，而且买完后就算没用也需要因此而付费。而 TDSQL-C Serverless 做了计算、存储分离。下面是存储层，存储层如果不够，我们可以通过加机器、加存储的方式实现水平扩展；上面是计算层，如果计算资源不够，也可以按自己的需要去动态扩容，而且不用在意存储层是不是满了。计算和存储分离后的每一部分资源都可以按照自己的需求去做分配。我举个例子，现在我们面前有两个房子，一个是两房没有客厅；另一个是两房一厅，客厅里有个电视可以方便我们一起玩游戏，因此每个月要多花 2000 元。但问题在于我也不是每天打游戏，只有
28、周末才有时间打。这就是现实里经常碰到的两难问题。如果这时候有个传送门，我可以直接从房间里传送到一个客厅里，一小时收费 10 块，是不是这个问题就解决了？如果我两房旁边就有一个游戏厅呢？这个游戏厅是不是也能解决我的问题？这样我就不用去解决传送门的问题了。实际上很难，如果这个游戏厅只为你服务，它迟早倒闭。物理位置的限制，让它没办法服务更多人。所以本质上，它要么服务人群足够多，要么就是单价很贵。在现实里，如果游戏厅就在你房间旁边，你房租的价格也会比其他地方的更贵。计算跟存储分离，就是让房子和客厅解耦。只要解决传送问题（自动扩缩容）就可以让这个房间的成本回归到它本身的价值。虽然传送门在物理上不存在，但
29、我们 TDSQL-C Serverless 做了一个传送门，也就是计算存储分离架构，让所有的计算节点和所有的物理层，所有存储层能够相互进行访问。TDSQL-C 在腾讯内部有比较多的应用场景，这里选取了两个比较典型的例子跟他大家聊聊：19腾讯云技术实践精选集 2022TDSQL-C 在微信小程序的应用开发微信小程序面临的问题：云服务成本高。云服务器虽然方便，但价格并不便宜，目前常见的服务器有两种按时付费和包年包月，按时付费价格有点高，包年包月不灵活；资源利用率低。根据数据来看，大部分小程序的用户规模小，数据库的资源使用率很低，而且大多数在活动期间会高一点，活动结束后，资源就用不上了；后端配置复杂
30、。云产品为了使用的通用性，配置会非常多，企业需要花很长时间去学习，去配置，运维成本很大。基于以上的问题，微信和腾讯云一起推出了微信云托管服务。简化小程序开发运维的流程。开箱即用，按使用收费，不使用不收费。能极大减少开发者的成本。在实现整个架构的时候，腾讯云托管遇到了数据库选择的问题。原先选择云托管后端自行分库，所有的小程序都访问同一个数据库，通过不同库来隔离。这种方案的隔离性很差，安全性也很差；后来选择了 TDSQL-C 的方案来解决，每个小程序都有了自己独立完整的 TDSQL-C 数据库实例。TDSQL-C 在腾讯乐享的应用腾讯乐享是腾讯内部的论坛、文档等，已经服务腾讯员工 10 多年了。下
31、图是腾讯乐享的架构图。20腾讯云技术实践精选集 2022不同员工通过外部应用防火墙到 CLB，然后进入到腾讯乐享的业务逻辑层。这是一个典型的 SaaS 服务架构。因为要面对不同的企业用户，所以在数据上要做隔离。同时，很多 ToB 企业用户很少，所以并不会频繁使用这个数据库，导致它的整个负载比较低。经过几次成本优化之后，腾讯乐享就会把很多负载低的客户合并到一个数据库实例里，也就变成了前面微信云托管那样一个架构了。同样，它也会面临云服务器资源浪费的情况。最后，还是使用了 TDSQL-C 来代替原来的云上数据库。TDSQL-C Serverless 数据库最大的优势是计费跟负载是强相关的，负载高计费
32、就高，负载低计费就低。替换后，腾讯乐享这边测算数据库的成本降低了 80%。TDSQL-C Serverless 数据库特点及其他场景应用实践TDSQL-C Serverless 数据库的三大特点是：自动扩缩容、按使用量计费、无使用无费用。我们希望你想要请求的时候，这个水资源能像瀑布一样倾泻而下，不需要业务提前感知。希望云服务能像使用水资源一样精准，你的账单一定是来自你所使用的 CPU 和内存资源。如果你不使用，就像关上的水龙头，不收费。常见的自动扩缩容业务场景1.慢查询。我们大部分业务都有慢查询，比如执行一个不带索引的 SQL；或者你有一个多表查询的场景；又或者前端有运营同学在做数据分析，慢查
33、询会引发一个比较高的 CPU 负载，但如果我们买一个大的规格，21腾讯云技术实践精选集 2022就需要承担比较高的成本，如果买一个小的规格，那么可能会因为这些慢查询而影响到在线服务。2.活动场景。在活动期间会有一个比较高的负载，但活动过去之后，负载就会降低。同样如果我们买一个大的规格，就需要承担比较高的成本，如果买一个小的规格，那么就支撑不了活动的使用了。当然你也可以选择在活动前扩容，活动后缩容。但这总的也不方便，而且并不是所有的活动都有足够的时间去规划。所以这时候就需要一个自动扩缩容的能力。3.定时任务。很多业务都会有定时任务的需求。比如在夜间去计算一下当天业务数据的情况汇总为一个报表。或者
34、是用户的一个账单。那么在这个任务执行的时候会有一个比较高的负载。虽然你也可以根据计划去手动扩缩容。但有些计划使用的计算资源不可控，时间也不可控。少了速度慢，可能还会影响到线上业务，多了又会浪费。TDSQL-C Serverless 自动扩缩容技术业内常见扩容方案如下图：第一步是低负载的情况，CPU 使用了 0.1 核，Buffer pool 使用了 1G，其他内存 100M。第二步，用户来负载了，也就是高负载触发扩容前，CPU 分配了 1 核其他内存 500M。然后第三步高负载触发扩容后，CPU 使用 1.8 核，Buffer pool 2G，其他内存 500M。22腾讯云技术实践精选集 20
35、22但这能满足用户的需求吗？实际上并不能。因为从第二步到第三步得有个持续监控发现它高负载了，发现它超过了阈值，才会自动扩容。比如 5 分钟高负载才扩容。而且它还是阶梯式的，比如我规格最小 1 核，最大 16 核，如果是阶梯式扩容，而我一开始就需要 16 核，你得反应 4 次才能扩容到 16 核，等扩容完成的时候，活动都已经结束了。再比如有些报表一两分钟就计算完了，扩容都来不及触发。所以这个扩容根本就不能满足业务的需求。我们之前也想过，想办法把 5 分钟扩容缩短成十秒甚至更低。但后来我们决定不这样做。我们干脆直接把规格放到最大，也就是如果最大规格是 2 核 4G，我们就直接放大到 2 核 4G。
36、用户可以一开始就使用 1.8 核，然后我们在持续监控这个 CPU 的高负载的情况下，对内存进行一个自动扩容。常见的业务场景计费模式1.近似计费。这种计费方式其实对用户很不友好。比如说，我只有了 0.6 核，但是确要为 1 核付费。如果我控制不好，超出一点，用了 1.1 核就需要为 2 核付费。2.小规格实例。现在其实有很多小数据服务，它的负载是低于 1 核的。但市面上大部分数据库，提供的最小规格就是 1 核。现在市面上有很对微服务，它对应的数据库也是非常小的。TDSQL-C 的计费模式我们每 5 秒进行一次资源使用采样，计算单位为：CCU（TDSQL-C Compute Unit）=max(C
37、PU,MEM/2,最小规格)。按实时的 CCU 进行计费。为了保证按使用计费，我们做了一个算法，能够保证按照你使用的资源来进行计算，账单也会体现你的资源每一时刻的使用。23腾讯云技术实践精选集 2022常见的无使用不收费的场景1.归档数据库。比如，在发论文的时候，有很多训练数据需要存储，这时候会需要去访问这个数据库，去取里面的训练数据做实验。这时候 CPU 会使用比较多，但我发完论文后，就基本不需要使用数据库了，这就是归档数据库的场景。2.低频访问的业务。像个人博客、垂直论坛、微信小程序等低频访问的场景。如果它每天的请求就十几二十次，我们还按 0.25 核去进行收费是不太合适的。3.开发测试环
38、境。大多数只在工作日的白天才会用，周末和晚上基本不用。这种情况完全可以在不使用的时候把数据库关掉。TDSQL-C 是如何实现不使用不收费的用户通过接入层访问我们的计算层，计算层通过存储层取数据返回给用户。管控平台监控计算层和存储层的资源消耗，包括 CPU、内存以及存储量进行计费。如果持续十分钟没有任何请求，我们就会通过管控层进行计算层的资源回收。而当新的 SQL 来了后，我们接入层能够感知并通知管控平台进行恢复，又会开始资源的计算。这里面有一个很重要的指标就是从暂停到再一次启动的时间。我们花了很多时间来优化这个冷启动的时间。目前大概还需要 2 秒，我们未来计划做到 1 秒内。未来展望我们希望把
39、数据库服务做成一个跟水资源一样的。让初创企业用这个水资源去灌溉自己的农田。目前我们做到了一些，未来我们还有更多可以去做。如果说中小企业是一片片沿溪而耕的农田，那么我们 TDSQL-C Serverless 的愿景就是建一座大坝来管理好上游的水资源，用来灌溉下游企业。扫码获取完整版演讲 PPT24腾讯云技术实践精选集 2022拥抱云原生，数十万规模 GPU 卡的利用率极致优化之路陈煜东 腾讯云异构计算、THPC 研发负责人腾讯云异构计算、THPC 研发负责人。2014 年加入腾讯，现负责腾讯云异构计算、裸金属高性能集群等相关研发工作，具有多年的分布式资源调度、大规模集群调度理论与实践经验。在科技
40、和产业进入人工智能和全真互联时代的大背景下，GPU 作为通用的算力加速引擎，业界最强的单加速器算力已经突破 1Pflops。如何配置高性价比的 GPU 弹性容器实例，并进行多任务共享 GPU，充分利用 GPU 算力资源，成为业界共同探索和努力的方向。在腾讯自研业务全面上云和云原生实践的过程中，面对算力挑战，腾讯除了配置极致性价比的 GPU 弹性容器实例外，也探索了在云原生架构下进行容器级别的 GPU 共享，从而在千万级并发下对业务进行加速，帮助自研业务实现降本增效。在 ArchSummit 2022 全球架构师峰会（深圳站）上，腾讯云异构计算负责人陈煜东发表了题为拥抱云原生，数十万规模 GPU
41、 卡的利用率极致优化之路的演讲，为大家解密腾讯自研业务上云和云原生实践背后的 GPU 优化技术及实践。自研 GPU 业务上云历程传统业务上云时，业务部门总会有很多疑虑，主要担忧集中在上云后业务的稳定性、灵活性、成本、监控完善度和部署难易度上。25腾讯云技术实践精选集 2022腾讯内部自研 GPU 业务上云的历程始于 2018 年。早期是一些小规模业务上云，2019 年开始云端达到数千张卡的规模，2020 年随着云游戏业务的发展云端达到了数万张卡规模。直到 2021 年，qGPU、Taco 训练加速和容器实例混部成为上云需求主力，云端规模达到数十万张卡级别。qGPU 共享技术：如何实现容器级细粒
42、度算力切分腾讯音乐和广告业务都会用到在线推理能力，之前使用虚拟机的弹性容器实例，基于 vGPU 虚拟化技术实现。但 vGPU 技术切割不灵活，只能将整卡资源切分成一到四份，没有办法切成更小粒度，而一些业务的算力需求比较低，所以需要做整合，就有了显存和算力强隔离的要求。多业务混合部署需求也是必须满足的，才能让业务有上云的动力。另外 vGPU 技术只有 Nvidia 的高端 GPU 才能支持，这也是一个不足。Nvidia 的 vGPU 是虚拟机固定比例资源切分，在容器场景没有直接适配，粒度受限，且需要许可证管理，运维成本较高。业界对 GPU 共享方案的探索也有很多，一条路径是按 GPU 核心做物理
43、切分，另一条是按时间切分。但前者需求底层硬件技术能力，所以只有原厂可以做，那么其他厂商的思路都专注在了时间切分。腾讯的 qGPU 方案也是时间片切分方式，针对的是 CUDA 和 Nvidia 专有 API 层。腾讯做的是算力隔离和共享方案。26腾讯云技术实践精选集 2022腾讯 qGPU 的架构主要有两个组件，首先是上图中第二行绿色的 GPU manager，其次是中间内核 qGPU 模块。从设备管理角度来看，从下往上看，最底层是一排 GPU 卡，紫色是 GPU 驱动。qGPU 要做的事情在于，如果有两个 Pod，需要用 40%的时间片和 5G 显存分配好，qGPU 就会打开 GPU 的设备，
44、再生成两个设备，一个是/dev/qgpu0 及其配套的/dev/qgpuctl0，一个是/dev/qgpu1 及其配套的/dev/qgpuctl1。Pod 起来的时候会告诉底层 qGPU，这边需要一个 GPU 设备，就把 qGPU 设备暴露在 Pod 里。底下 KMD 是 Nvidia 专有的一层，以为上层操作过来的是 UMB 的驱动，其实是 qGPU 模拟出来的设备。qGPU 在这当中做了一个通信中介，UMD 和 KMD 通过中介来交流，我们通过这个方法来做显存隔离。对于算力隔离需求，只要上层有业务数据过来，就找到对应的硬件资源，准备好之后就走 Linux 的内核模块直接对硬件设备做操作。C
45、UDA 需要申请资源的时候，我们要控制模块帮它分配好内存资源，告诉底层设备把对应的控制信息提前分配好，再把内存之间的数据对好即可。qGPU 这一层可以通过拦截一些库，帮助识别具体的任务，为此我们做了策略调度模型。qGPU 调度策略有两个功能，一是 Spread，平均分配，保证负载稳定均衡；二是 Binpack，尽量填满保证利用率。我们在单卡做的策略调度有三种模式，第一种是 Best Effort，有 N 个 Pod，每个 Pod 给 1/N 资源。第二种是 Fixed Share 固定配额，实现算力的精确隔离。第三种是突发型的 Burst Share，在基础配额基础之上把空闲资源拿出来动态配置
46、。对于第一种 Best Effort 模式，我们推荐负载较低的在线场景使用，即便多个业务高峰期来了，负载还没办法把整个 GPU 打满。有些业务对处理时延敏感，最好使用第二、第三种，保证固定配额的调度模式。再看离线混部场景。离线混部场景下业务往往自己知道自己的优先级，会提前标注好。这时高优先级任务会平均分配保证负载均衡，低优先级任务会尽量填满来保证资源利用率。这里还支持在线 100%抢占。算力平台上有很多离线任务之前用单塔模式做训练或推理，它们的业务没有太多共享，所以上云之后把这种离线任务的 Pod 和在线任务的 Pod 做整合，填在一起。腾讯 qGPU 也是业内唯一的 GPU 在离线混部技术。
47、实测来看，qGPU 的效率损失非常小，QoS 效果比较稳定，延迟也没有忽高忽低的情况。27腾讯云技术实践精选集 2022基于 Taco 的异构计算加速实践之前我们发现广告场景做分布式训练时出现了性能不升反降的情况。我们之前的业务都是用 A100 运行，但我们发现设备加了一倍之后性能反而下降。分析这里面的原因发现，整个 GPU 的数据通信过程被算法变成了一个环型结构，假设有 5 张卡，5 张卡首尾依次互连，然后每个卡都有对方卡的数据，算完还要再算四轮，做数据的交换处理。如果这些卡走跨机网络通信就会受限于 PCIE 的带宽甚至网卡带宽。为了解决网络通信问题，我们主要围绕上图中蓝色的两个层面来做优化
48、，分别推出 LightCC 算法方案和 HARP 协议方案。LightCC 改进了原有算法，先在单机的多卡之间用 NVLink 做数据通信，内部算完的结果再和其他机器做通信，尽量减少跨机之间通信的数据量。并且所有卡都在同时跨机收发数据，这样能提升带宽利用率。上云过程中需要复用云上的 GPU 资源，这些 GPU 资源有很多还是没有对应配套 RDMA 网络的，为此我们做了 HARP 协议。传统数据通信走内核 Socket API，这里还有内存拷贝，效率比较低。我们 HARP 协议栈用 DPDK 做了一个框架，不走传统内核协议栈，减少了内存拷贝。特别是每个 GPU 服务器会配套 8 个弹性网卡，GP
49、U 会跟弹性网卡去做一对一绑定，让它独享弹性网卡资源，避免大家都在共享网卡，出现 QoS 问题。28腾讯云技术实践精选集 2022测试效果来看，A100 GPU，16 卡情况下，用开源方案性能会下降，用了 LightCC 和 HARP，性能还是得到了明显提升。容器实例的 GPU 混部方案为了降低成本，业务端出现了两个问题。第一是业务需要的 CPU 和内存资源无法按照 GPU 等比例切分，第二是业务后端无法定制多种规格的物理机。直接的应对思路就是将空闲资源与 CPU 弹性容器实例混部，但也带来两个问题，一个是频繁的弹性伸缩，碎片资源不知如何高效利用；另一个是资源的迁入与迁出如何设定。上图是我们的
50、迁移策略。迁移时会把待迁数据构建出来，也就是最右边的橙色结构。目的端的宿主机也构建出来，构建成一个最小规格的数据结构。迁移的动作开始时，还是从容器实例最大规格来填，填充好后面就没有产生多余的碎片，按这个排序找最小的规格可以满足的宿主机去迁；小规格实例填充碎片即可。迁出策略和迁入相反，如果 GPU 的容器实例已被退出，我们去看对应的库存 Buffer 量，是不是 GPU 资源已经不够了，或者要补充库存的，我们就会把 CPU 资源迁出来，保证一定的 Buffer 空间。外迁和迁入的动作一样，不用考虑规格问题，因为迁移进来的实例已经被过滤一道了。29腾讯云技术实践精选集 2022收益来看，混部方案可
51、以把空闲 CPU 利用起来，宿主机浪费成本缩减 70%，使用率提升 53%。这里没有做到 100%，因为我们还要给 GPU 资源做预留，避免 GPU 实例过来发现没有资源。总结 通过在 GPU、UMD、KMD 之间增加一层，实现更灵活的算力、显存切分调度；通过减少跨机数据通信与优化协议栈耗时，提升分布式训练效率；弹性容器实例通过资源混部与动态迁移能力，提供能灵活的规格，降低成本。扫码获取完整版演讲 PPT30腾讯云技术实践精选集 2022TDSQL-PG 数据库在微信支付的应用实践胡锦前腾讯云数据库资深架构师TDSQL-PG 系统架构设计师。主导过多个 TDSQL-PG 应用项目，包括腾讯内部
52、微信支付、AMS、互娱数仓、腾讯指数等业务，对外覆盖了保险、税务、公安、消防、政务在线、物联网等行业，对于 TDSQL-PG 分布式数据库应用系统设计、开发、性能调优及多中心多活应用实践方面，拥有丰富的经验。几年前，微信数据量爆发式增长的同时，微信支付商户服务、报表 BI、仓库维表系统却受制于存储和性能无法扩展、业务拆分难度大等瓶颈。在这一背景下，TDSQL-PG 开始了在微信支付业务场景的应用落地探索。为了解决微信支付业务场景的痛点问题，TDSQL-PG 在实践过程中也沉淀了一些技术创新方案。QCon 2022 广州站上，腾讯云数据库资深架构师胡锦前带来题为TDSQL-PG 数据库在微信支付
53、的应用实践的演讲，详细讲解 TDSQL-PG 在微信支付的应用实践历程，以及针对微信支付业务不同的痛点，TDSQL-PG 的解决思路与经验总结。TDSQL-PG 在微信支付上的使用背景2016 年微信支付日均交易规模超过十亿，数据量爆发式增长。彼时，微信支付的商户平台在数据存储、查询等方面无法满足数据业务增长的需求，因此具备海量存储和高查询能力的 PGXZ 数据库开始在微信支付31腾讯云技术实践精选集 2022TDSQL-PG 在微信支付上的主要应用场景微信支付商户平台应用场景。微信支付商户平台是广大微信商户的查询系统，提供账单明细下载及账单单据复杂条件的查询等能力。在迁移到 TDSQL-PG
54、 之前，商户平台采用传统 MySQL 分库分表模式来提供服务，但遇到了分库分表模式的单机存储无法满足业务增长需求、交易量大的商户查询性能不足、MySQL 无法提供存储分离及自动搬迁能力、MySQL 难以满足按时间分区剪枝的需求等问题。TDSQL-PG 解决上述问题的方法是：TDSQL-PG 能支持按照商户号来拆分，将不同的商户数据存储到不同的节点，对外屏蔽内部的分布细节；对于数据大商户的数据存储采用双 KEY 方式存储，把数据均衡打散。TDSQL-PG 具备原生的索引调优等手段，有 Btree 索引、表达式索引等，同时也有 Index Only Scan 的算法，针对性调优可以满足需求。TDS
55、QL-PG 集群支持 Node Group 概念，可以支持不同时数据按照不同 Group 存储，支撑冷热数据自动搬迁，大幅降低成本。TDSQL-PG 自研分区表，有效做到分区的隔离消除，通过分区+索引组合大幅提升查询性能。报表系统微信支付 BI 报表是非常强大的系统，但之前的 MySQL 版本也遇到了空间存储受限、扩容数据迁移成本高、批量写和实时写时延要求高、跨周期的数据统计分析性低、索引类型相对有限等问题。对此 TDSQL-PG 的解决方案如下：BI 通过 Spark 离线接入 MySQL 的写入量可大可小，另一种是实时写入，实时计算结果通过消息队列写到数据库里。这两种写入需求都通过 TDS
56、QL-PG 的并行写入、拷贝入库的方式提供很好的支撑。读取方面则通过模糊查询、精确匹配、下推并行优化、读写分离等措施增强，使 BI 报表、数据开放服务的查询能力有了较大提升。TDSQL-PG 已经全部接管 BI 报表的存储查询功能，大表打开时间在 3 秒以内。商户平台落地。2019 年，随着 PGXZ 不断自我完善，并行写入及复杂条件查询能力不断突破，PGXZ 发展成 TDSQL-PG，微信支付的 BI 报表系统也全面从 MySQL 切换到 TDSQL-PG 数据库。2021 年，在多年应用实践的基础上，腾讯发现 PGXZ 能够打通数据仓库与在线业务，于是把微信支付的仓库维表系统全部都切换到
57、TDSQL-PG 上。32腾讯云技术实践精选集 2022维表系统维表维度是观察事物的角度。开发过程中的枚举值也是维表，维表系统需要管理大量枚举值。切换到 TDSQL-PG 前，维表上下游之间的处理缺乏一致性视图，维表管理难以维护。而 TDSQL-PG 为 OLTP 与 OLAP 架设了桥梁，解决大数据瓶颈的维表管理问题。在线业务与大数据的报表平台中，通过 TDSQL-PG 能够关联维表，并且支持实时更新、修改及删除，还能实现上下游维表值的距离查看，不需要一层层传递。TDSQL-PG 在微信支付上的应用实践双 KEY 分布TDSQL-PG 对数据倾斜的处理采用双 KEY 分布。我们有 Defau
58、lt Shard Group 和 Big Shard Group 两个组，Default Shard Group 直接用商户哈希来计算 Shardid ID，通过商户直接下推到数据节点。大商户用特殊分布逻辑，通过商户 ID、Merchantid 加分片键的偏移量来做 Shardid ID 的路由计算。这种处理方式能实现大商户在 Group 均匀存放，有效解决数据不均衡问题。下推查询33腾讯云技术实践精选集 2022这里计算节点能够把排序下推到数据节点，数据节点通过 Merge Append 归并各个子表的结果，子表上面的结果是有序的，走 lndex Scan 扫描出来，通过 Merge App
59、end 的子表的结果来做 DN 数据节点的高效扫描。数据推下来，所有 DN 并行运行。同样计算节点也会对所有 DN 做归并计算，从而保证有序性、正确性，并且保证数据计算下推并行执行。自研分区表34腾讯云技术实践精选集 2022自研分区表的结构如图所示，计算节点负责纵向分表，不感知分表逻辑，看到的数据节点上就是一张逻辑表。也就是说计算节点并不知道一张表有没有做分区。数据节点具体实现横向分表，根据分表将一张逻辑表划分了物理表，这就是承载分区表的实现逻辑。自研分区表可以有效做到物理的扫描隔离、数据后续清理和治理的优化。并行优化我们现有的系统中，大 CPU、大内存是标配。为了有效利用这些资源提升查询能
60、力，这里我们对于相关算子做了并行优化。35腾讯云技术实践精选集 2022冷热分离如图所示，每一个 Group 的热数据和冷数据都是不同的 Group 组。我们按天来分区，每一张表在冷数据跟热数据都有一张物理表，数据写入到热数据部分，对应的冷数据这个时候是空的，冷热数据转化阈值是集群公共值，可以自定义。当冷数据达到阈值的时候，后台会自动搬迁热数据，这个过程对用户来说完全无感知。因为冷数据存储成本较低，因此总体成本大幅下降。读写分离TDSQL-PG 支持传统的 Proxy 读写分离方案，可以对不同访问转发不同的读写平面来实现读写隔离。多个平面可以容灾、实现均衡负载，降低组的负载压力。但很多情况下开
61、发框架会带来一些显性失误。在这种情况下，传统的 Proxy 没有办法做到自动读写分离。而我们在 CN 的计算节点具备了自动读写分离功能，能够实现一个账号连通一个 IP，自动识别读写，将读请求转发到读平面，写请求转发到写平面。36腾讯云技术实践精选集 2022TDSQL-PG 在微信支付上的使用效果特性总结 海量存储，单表轻松突破 TB，快速扩容。数据治理能够实现冷热分离、灵活分区、数据访问能力、数据多方位管理。事务支持，具备数据 upinsert 场景，全局多平面事务都有效保证事务一致性。高吞吐，可以在横向扩容基础上持续提升整体读写能力。跨 AZ 容灾，保证安全性，多副本跨 AZ 和低延迟。多
62、类型索引支持，支持全文检索、模糊匹配、比较等值等条件。使用收益我们目前的收益包括存储量 400 多 TB，全球流量每秒 24 万，99.6%的响应时间在 10 毫秒以内。报表以及 BI 系统的用户使用满意度都比较好。新版本的特性介绍和总结我们的新版本特性包括：行列混合存储高性价比。支持行式和列式存储，支持高效行列混合计算，自研列存引擎，支持多种压缩算法压缩级别，提供自适应压缩能力和高压缩比。高安全高可用有保障。支持三权分立、数据透明加密、数据脱敏，强制访问控制及全方位审计能力；支持多级容灾高可用，完整的事务能力。支持完整的事务 ACID 能力，保证分布式事务的全局一致性，通过拥有自主专利的技术
63、来保证分布式架构下的一致性和高效性。全并行架构极致性能。无共享分布式架构，节点间、节点内、算子间全并行处理，高效向量化执行引擎，延迟物化技术，万亿级关联查询秒级返回。37腾讯云技术实践精选集 2022 语法兼容度高迁移低成本。兼容 SQL 2011 标准，全面兼容 PostgreSQL，高度兼容 Oracle 语法，配套迁工具一键式迁移。强大数据治理能力。提供冷热分离能力、Hash/List/Range 多种分区策略，灵活扩缩容能力，支持 FDW 外表能力与其他数据源快速互通能力。总结来看，TDSQL-PG 解决了微信商户平台，包括 BI 报表和维表管理系统遇到的海量存储、数据倾斜以及性能和成
64、本等问题与瓶颈。TDSQL-PG 在微信支付提供的在线扩容、双 KEY 分布、冷热迁移、下推查询、并行优化、自研分区表、读写分离等技术特性取得比较好的实践效果。TDSQL-PG 在微信支付各场景实践将进一步优化，为微信支付报表等场景提供坚实的数据存储技术支撑。38腾讯云技术实践精选集 2022将云原生进行到底：腾讯百万级别容器云平台实践揭秘林沐腾讯云高级工程师曾负责 QQ 运维平台的开发工作，在海量服务产品的虚拟机部署形态、微服务架构和 Devops 流程方面积累了丰富经验。现阶段负责腾讯内部业务上云过程中的容器化规范，以及百万级别服务容器云平台的设计与开发工作。基于 K8s 的云原生容器化已
65、经在腾讯内部海量业务中大范围落地实践。业务从传统的虚拟机部署形态无缝切换到容器部署形态，运行在 K8s 上的应用从无状态服务扩展到有状态服务，这个过程经历了哪些改造？同时，K8s 如何经受住业务形态复杂多样、模块数量庞大的考验，遇到哪些新的挑战，如何优化，效果怎么样？在 DIVE 2022 北京站上，腾讯云高级工程师在题为腾讯大规模自研业务容器化实践的分享中解答了上述问题。在线业务资源容器化部署的问题与优化方案腾讯平台的业务基本都属于在线业务。这些业务以前在虚拟机部署时，是通过物理机操办的方式生产出很多虚拟机，对于业务来说是不感知的。当业务发现虚拟机负载较低时，可将多个在线业务混部来提高资源利
66、用率。39腾讯云技术实践精选集 2022这种资源管理方式到容器化部署时发生了一些变化，主要有四方面的内容。容器交付。每个 Pod 在交付的同时需要声明规格大小，规格大小要改变时 Pod 必须销毁重建，无法通过混部来新增业务。节点均衡。K8s 每个节点上部署多个 Pod，每个节点上的 Pod 类型、数量也都不相同，要保证节点均衡是一个挑战。K8s 的云原生特性，也就是弹性，是否能够符合在线业务在生产环境中的需求？集群池化。K8s 是按集群维度管理，而平台有上万个业务，这么多业务如何映射到不同的集群实现条带化管理？针对上述问题，腾讯采取的优化手段是：1.资源利用率提升动态压缩和超卖。我们面临一个痛
67、点是用户配置的容器规模不合理，普遍偏大，这样节点装箱率和负载比较低。所以第一个优化方式就是 Pod 资源动态压缩，Pod 请求双核处理器 4G 内存，在调度时压缩成单核 4G 内存。因为 CPU 属于可压缩资源，内存属于不可压缩资源。这里修改的只是 Request 大小，并不修改 Limit，所以不影响容器实际能使用的上限值。这样能提高节点的装箱率。接下来是 Node 资源动态超卖，根据负载情况超卖更多 CPU 核心。40腾讯云技术实践精选集 20222.节点负载均衡动态调度和重调度。资源压缩超卖能提高节点的装箱率和负载使用率，但 Pod 是共享 Node 的，压缩和超卖会加剧它们之间的干扰。
68、于是我们开发了动态调度器，当每一个 Pod 调度时，能够感知存量 Node 当前的实时负载情况，从而对增量 Pod 在 Node 当中均衡处理，掉到一个低负载的节点上。存量 Pod 在节点上也有可能发生高负载，这时我们在节点上部署 Pod-Problem-Detecor、Node-Problem-Detecor，检测出哪个 Pod 会导致节点高负载，哪些 Pod 属于敏感 Pod，通过事件上报告诉 API Server，让调度器将异常 Pod、敏感 Pod 重新调度到空闲节点。3.K8s 业务弹性伸缩协同弹性。在线业务最关心业务稳定性。有时业务负载超出预期时，因为最大负载数配置过低，导致业务雪
69、崩。所以我们对 HPA 进行优化，加入 HPAPlus-Controller，除了支持弹性最大副本策略之外，还能够支持业务自定义配置进行伸缩。第二个是 VPAPlus-Controller，可以 Pod 突发高负载进行快速扩容，对有状态的服务也可以进行无感知扩缩容。4.集群资源管理动态配额和资源腾挪。从平台的角度，K8s 集群也是一个重要的维护对象。平台通过动态 Operator 的方式控制业务对集群的可见性以及配额大小，使得各个集群的业务是分布均匀的。集群本身也有规模大小，有节点伸缩，叫做 HNA。HNA 能够根据集群负载情况自动补充资源或释放资源。生产环境中一种情况是，有时候突发活动，在公
70、共资源池里没有特定资源，需要从其他系统里腾挪资源。所以我们开发了弹性资源计划 Operator，它会给每个节点、每个集群下发任务，要求每个集群释放一些 Node 出来。这批节点的数量要尽可能符合业务的数量要求，同时要对存量业务的负载质量不产生影响。我们的方式是通过动态规划的方式解决问题，从而在业务做活动，或者紧急情况下，能够使集群之间的资源也能够流转。容器化对动态路由同步的挑战与解决方案每一个 Pod 在销毁重建的时候会动态添加或提取路由。一般来说，生产环节中的路由是第三方系统负责，当 Pod 正常的时候系统给它转发流量，或者做名词解析，当它摘除时就从名词服务里剔除。41腾讯云技术实践精选集
71、2022但我们的平台在生产环节中会遇到一些特殊情况。第一个情况就是容器化之后容器的变更更加频繁。第二个变化在于业务规模非常庞大，单个负载的 Pod 可能成千上万。第三是业务层面的变化，云原生的方式是一个集群对一个路由入口，但在生产环节又是第三方路由系统，允许云上云下混合部署，跨集群多路由服务共享路由。动态路由是容器化的关键路径，是要解决的核心问题。在微观层面，业务对容器运行阶段有特殊需求，包括容器分级、路由和进程的运行状态一致、大批量探针失败时要实现路由熔断。生产环节中路由系统是非常多的，每个路由系统会对应一种控制组件。所以我们需要路由同步 Controller 的统一框架。这个框架理论上是一
72、个旁路 Controller，因此存在不可靠的问题。例如在 Pod 下线前，销毁的时候不保证已经剔除路由；又比如在滚动更新时，可能上一批还没有添加路由，下一批就开始销毁重建。由于有些业务又比较敏感，必须要求绝对保证线下和滚动的时候路由的正确性，于是我们利用了 K8s 云原生的删除保护、滚动更新机制来实现这一需求。当业务在销毁之前先剔除路由，业务在滚动更新的时候先保证上一批添加。通过这种方式将路由融入到 Pod 生命周期里，来实现业务的可靠性。对于运行阶段，例如容器异常自动重启，或者 Pod 其中一个容器通过原地生成的方式启动，这些场景就会绕过前面提到的滚动更新和删除保护。所以还要在运行阶段保证
73、业务之间的快速同步。业务大批量变更又会产生大量事件，导致 Controller 积压问题。42腾讯云技术实践精选集 2022对此我们第一个优化方式是使用 Service 粒度事件合并，将事件数量成数量级减少来提高速度。第二个是双队列模型。K8s 的 Controller 里有定时历史对账机制，会将所有的 Pod 对象全部入队列。我们需要将实时和定时的事件分开，这样既能够解决定时对账，又能解决实时处理需求。这里面有一个细节问题，两个不同队列可能在同一个时刻会有同一个事件要处理，这就需要相互感知的能力避免这种情况发生。下一个 Controller 框架的核心点在于支持共享路由。但云原生的 K8s
74、机制里是一个集群对应一个路由入口，所以我们在 Controller 框架里增加一个路由同步记录，也是按照 Service 的粒度去记录的。如果业务系统产生脏数据，例如触发一个剔除操作，但是路由系统返回成功了，实际上没有剔除，那么下一次它去同步处理这个事件的时候发现它没有被剔除，那么还是会再重新剔除一遍。也就是说路由操作等于期望值去 Diff 当前值，而它的期望值就等于 Endpoint 和 Pod 生命周期的交集，当前值就是路由系统里面的情况加上路由记录，二者再取差积就是要做的路由操作。旁路 Controller 作为一个组件会有异常的时候，虽然 K8s 提供 Leader 机制，但这个机制被
75、 Controller 拉起时需要预加载存量 service 数据，如果数据量非常大需要很久时间。我们的解决方式是，每一个 Controller 运行的时候属于主备模式，这样当主容器挂掉的时候，备容器获得锁，之间的间隔就是整个 Controller 同步中断的最长时间，之后备容器就可以快速接管路由通路服务。中断期间可能发生事件丢失问题，我们通过定时历史对账机制解决这个问题。我们还有特殊需求，是业务为了兼容虚拟机部署的一种管理方式，主要针对容器的运行阶段以及特殊处理。这里的需求包括容器分级、流量平衡、路由熔断。这些需求对传统的 Endpoint Controller 而言是不感知的，原来只维护
76、Ready 和 Not Ready 的状态，没有感知更细分的状态去维护容器的角色和状态。如果这是由路由 Controller 来实现，那么对这些特殊场景来说是牵一发而动全身的，每一个组件都得同时开发，修改一遍，维护成本是很高的。所以我们提供了一种解决方案Endpoint-Plus Controller。它将维护容器角色和状态的能力下沉到 Endpoint 来实现。它与 Endpoint 和路由同步 Controller 之间建立一种交互协议，就是 Endpoint Ready 时添加路由，Not Ready 时禁用路由，不在 Endpoint 里删除路由。这样所有组件都是统一的，而且每次业务的
77、新需求只要修改 Endpoint 就对全部生效，这样实现了动态路由同步的桥梁作用。43腾讯云技术实践精选集 2022一种全新的容器销毁失败自愈机制探索最后一个话题是关于容器销毁失败自愈的。前面提到了动态调度、弹性伸缩、容灾迁移、流水线发布，这些操作都有一个前提，就是容器销毁重建时老的容器要销毁，新的容器能创建出来。但实际上在生产环境中这并不是 100%能保证的。因为容器是共享的，多个容器在同一个节点上，卡住的时候会涉及到很多原因：调用链很长，只要其中任何软件出现 BUG 都会卡住；管理容器对业务容器有侵入，造成卡顿；业务容器之间互相干扰；共享内核、Cgroup、Namespace，并不保证所有
78、资源绝对完全隔离；共享节点资源，当 CPU、磁盘 IO 高负载时会影响整个节点上的所有 Pod。K8s 发展到现在已经有了一套很完善的自愈机制。对容器异常来说，云原生 K8s 提供一个暴力解决方案就是强删机制。该机制只是删除这个数据对象的数据，并不是销毁这个容器。这样导致一个问题，如果进行强制销毁，可能老容器会残留，新容器又起来了，这时老的容器会影响节点。所以容器销毁阶段卡住会影响容器销毁重建这个基本需求，而且它的原因是复杂多样的，在大规模系统环境中更容易出现，而已有的自愈机制是没有涵盖这种场景的，所以我们就需要提供一种全新的自愈机制。传统的解决方案是通过脚本扫描到它，对于定位到的问题，没有解
79、决方案的需要临时隔离，已有解决方案的就要明确修复。但这并不是一个闭环方案，因为还有很多未知问题，对未知问题来说业务关心的是尽可能恢复，而对平台来说为了保证稳定性，需要尽可能知道这些根因，去收敛这类问题。所以我们兼顾这两个需求，要缩小定位范围、缩短定位周期，提高定位效率。对定位到根因的我们要去评估它的影响面，防止增量发生。而已经有解决方案的，我们需要有全网修复能力，出现异常的时候要告警，从而实现闭环解决方案。我们想到了是智能运维的方法，它依靠大规模训练样本，关注相关性。而故障处理一般是小样本量，强调专业和因果性，所以它并不很适合这种场景。但在智能运维的决策树模型里有些概念可以拿来参考，譬如基尼系
80、数、信息熵、剪枝等。44腾讯云技术实践精选集 2022最后简单介绍一下决策树模型的实现。第一步需要建立模型，是关于信息熵的权衡，要平衡自愈机制和定位效率。我们在选择信息熵的时候是自顶向下的推导路径，从节点异常再到容器调用链异常，再到具体系统日志。第二步是特征选取，基尼系数越小特征越明确，所以我们选择共同特征作为一个特征值。同时选择一些已知问题或者根因比较明确的作为叶子节点。最后一步是模型优化，例如剪枝优化，通过后剪枝的方式解决过拟合现象。同时简化模型。通过这种方式，当容器发生销毁失败时，能够触发自愈路径。同时，对于新增问题，我们可以缩短问题范围，提高定位效率。通过以上三步，最终我们探索出了这样
81、一种全新的容器销毁失败自愈机制。扫码获取完整版演讲 PPT45腾讯云技术实践精选集 2022云原生安全可观测性探索与实践江国龙腾讯云容器安全架构师、腾讯安全云鼎实验室高级研究员腾讯云原生安全技术专家，主要负责云原生安全领域的技术研究、安全能力构建、腾讯云原生服务安全架构设计和落地实施等，有着丰富的云原生安全建设和实践经验。云原生架构下，可观测性为云原生应用的故障分析、问题定位、性能提升等提供了重要的帮助，在云原生生态中起到了重要的作用。同样，可观测性对于云原生安全也有着重要的意义，如何利用可观测性实现云原生安全？腾讯在这方面又有哪些积极探索和实践干货？在 ArchSummit 2022 全球架
82、构师峰会（深圳站）上，腾讯云容器安全架构师江国龙带来题为云原生安全可观测性探索与实践的分享，解答了这些问题。云原生架构下，为什么安全需要可观测性业务云原生化后往往会面临一些运维和安全层面的问题：我的集群里有多少个 Pod 拥有高权限、我的应用应该被赋予哪些权限？如果发生提权操作，我怎么知道是哪个 Pod，我该怎么操作？我发现有 Pod 在访问 API Server 执行操作，是被入侵了吗？微服务之间的各种访问通信，都是正常的业务操作吗？46腾讯云技术实践精选集 2022 镜像扫出来一堆漏洞，我该怎么处理？安全产品告警了，我该怎么进行处置、怎么溯源分析？等等。云原生会给业务安全带来这些挑战，一个
83、重要原因是云原生架构颠覆了整个 IT 生命周期与治理模式。我们发现一半左右的容器的生命周期不足五分钟，70%多的容器生命周期小于一小时，这意味着业务资产时时刻刻都在变化，安全检测和防护更加困难。再从主机维度来看，云原生架构下主机行为更复杂，体现在工作负载密度更大、变化频率更高、调用关系更复杂。还有，云原生架构下，现有安全能力无法识别全部风险，新技术、新架构、新模式对现有安全方案提出了重大挑战。最后，云原生的合规标准也提出了更多可观测性要求。基于上述现状和问题，我们认为在云原生架构下，有必要通过可观测性方式来加强安全性建设。什么是云原生安全可观测性云原生可观测性概念可以和传统的监控对比。传统监控
84、能告诉我们系统哪些部分不工作了，而可观测性就能告诉你为什么那里不工作了，给你提供更多详细的数据解决问题。到了安全层面，传统的安全告警可以告诉我们系统哪里是不安全的，而安全可观测性可以告诉我们那个地方为什么是不安全的，让我们能够基于安全可观测性的数据去实现持续安全治理和运营。之所以强调云原生可观测性，是因为云原生架构下安全治理和运营面临更大的复杂度、更多挑战。云原生架构面对的风险全景可分为两部分，第一部分是风险可观测，就是事前判断系统都有哪些风险；第二部分是事中的威胁可观测，一旦系统被入侵，我能够快速发现整个入侵路径、当前的威胁态势。所谓云原生安全可观测性，一方面是运用云原生的可观测性来实现相应
85、的安全检测，同时也是对整体安全态势实现可观测；另一方面，云原生架构的特性使得安全的可观测成为可能。容器、微服务、DevOps 是云原生的基础，它们催生了新的 IT 开发和治理模式，最终呈现为不可变基础设施与声明式的 API。从安全角度来讲，不可变基础设施让安全措施更容易实现，催生了新的安全模式。要实现安全可观测性，在实现层面可以总结为三大支柱：1.系统可观测：风险/行为可观测（监控/日志/追踪）；逃逸检测、越权检测、WebShell 检测、挖矿检测等。2.网络可观测：网络连接、网络通信；挖矿检测、端口探测、异常连接检测等。3.应用可观测：API 资产管理、API 调用异常、业务安全等。47腾讯
86、云技术实践精选集 2022如何实现安全可观测在上图的安全可观测实现路径中，最关键的部分就是数据采集。在这一层面，我们会尽可能把安全能力同样做到云原生化，同云更完美地结合。数据采集分为两部分，首先是采集云端各类资产数据、可观测性数据；其次就是采集安全探针数据。我们通过 DaemonSet/Agent 模式部署探针，采集相应进程数据、网络数据。这里会基于 eBPF 实现安全数据可观测，且腾讯云自身的网络能力与操作系统对 eBPF 有着良好支持，这样安全层面就有更多施展空间。例如对 K8s 审计日志做分析，一些操作对于传统安全能力来说都是正常的，但从安全角度来说就是异常的，那么通过审计日志分析，根据
87、特定规则就能发现风险。又如容器权限的异常检测，我们能够通过探针发现正常业务应该有哪些权限，之后通过准入策略控制应用在启动时获得的权限。云原生安全可观测性实践腾讯云在做超大规模容器平台的安全架构时，总体遵循四大原则：1.安全能力原生化，包括原生基础设施安全性、安全能力云原生化；2.安全左移，指更早投入安全资源和能力、更有效收敛安全漏洞问题、更早确定安全性；48腾讯云技术实践精选集 20223.安全防护生命周期，从开发到部署到运营全面融入 DevOps 体系，实现 DevSecOps；4.零信任安全架构，包括全面有效的身份权限管理与持续的检测与响应。上图是腾讯云的容器安全体系架构。底层是基础安全能
88、力，这部分是不依赖云原生的能力；中间是云原生安全架构的基础能力；最上层是应用安全，依赖于相应的可观测安全管理的能力。这样最终实现了 DevSecOps 全流程安全管控。整体来看，云原生安全性概念的范围是很大的。具体的实现有几个案例：容器镜像的安全风险可观测。我们从基础镜像的角度切入，通过可观测性的方法实现对镜像安全的治理。镜像会有各类依赖关系，复杂业务会有很深的镜像依赖树，那么很多问题就很难找到具体的引入根源。对此我们会在镜像扫描过程中把所有风险定位到相应的层级、相应的镜像负责人。同时我们通过漏洞管理、风险管理等措施实现对容器镜像的风险可观测性。发起云原生安全测试平台，全面覆盖安全风险可观测。
89、除了自身实践之外，我们也联合业界做了一些尝试。我们联合信通院和清华大学成立了云原生实验室，推出了云原生安全测试平台。我们基于这个平台联合业内安全厂商、云厂商、高校一起，共同进行相应的能力建设。我们最终的目标是通过能力共建来对云原生系统做相应的诊断、分析、评估，实现风险的可观测。测试平台目前覆盖了整个云原生安全体系，可以对 400 多项可能存在风险，或者对安全能力有要求的位置做相应的安全有效性验证。我们也希望能够联合整49腾讯云技术实践精选集 2022个业界，把我们的积累分享给全行业。运行时的安全威胁可观测。从运营角度来说，这里主要是发现威胁之后的取证、溯源、分析攻击路径等工作。针对单点威胁，我
90、们能够把相应的问题、影响范围、上下文、责任、资产、相应的责任人做到全方位关联，让运营能够直接定位到具体的负责人，马上做出相应的威胁处置。腾讯云容器服务 TKE 安全性也得到了行业认可，我们的安全成熟度模型拿到了最高的安全等级认证。总结第一，云原生架构在安全防护和安全运营上存在挑战；第二，云原生的可观测性可以很好地赋能安全能力的构建；第三，云原生安全的可观测性包含事前的风险可观测和事中的威胁可观测；最后，云原生安全的可观测性可以很好地赋能安全治理和安全运营。扫码获取完整版演讲 PPT50腾讯云技术实践精选集 2022大规模代码中引入供应链漏洞的分析技术前瞻王福维腾讯安全云鼎实验室高级研究员腾讯云
91、安全高级研究员，专注基础安全研究，在漏洞控掘分析自动化以及恶意代码检测领域，积累了前沿研究和一线攻防经验。现致力于在真实世界中挖掘暴露供应链安全的已知和未知威胁，并研究解决核心问题的技术方案。云原生之所以能提升开发效能，“代码复用”功不可没；独立分析机构的调查报告指出，来自开源软件供应链的代码在线上应用中占比 85%+，这造成了代码缺陷的广泛传播。据 Google Project Zero 团队研究，今年在野利用的 0day 漏洞中有一半是历史漏洞的变种；而开发者也总是在写前人犯过错误的相似代码。为了解决现有安全技术面对历史漏洞传播无能为力的问题，QCon 2022 广州站上，腾讯安全云鼎实验
92、室高级研究员王福维带来了题为大规模代码中引入供应链漏洞的分析技术前瞻的分享。本次分享将从一些典型案例切入，逐一进行问题分析，并首次揭秘腾讯安全当前正在发力研究的一项有别于 SAST、SCA 等的创造性技术，并介绍如何在 DevSecOps 实践中使用该方案。51腾讯云技术实践精选集 2022代码复用所引入的软件供应链安全威胁形式软件可以理解为机密且功能复杂的机器，当中有大量复杂组件，不可避免会有一些核心、边缘组件要从企业外部采购合成。这些组件的知识产权、质量、可靠性等要素经常缺乏足够的保证。据业内权威报告，当今 90%98%的软件包含开源代码，所有软件代码中开源代码所占比例超过 78%。这些开
93、源代码中有 85%是严重过时的，81%的代码至少包括一个漏洞。每个软件依赖的代码中平均有 49 个漏洞。代码复用也不仅仅是“包依赖”一种形式。实践中复用的形式多样、粒度也有多个层次。目录粒度上有软件子模块引用开源项目固定 Tag，开源项目代码静态引入和编译；文件粒度上有单文件代码引用，功能模块克隆修改；代码片段粒度上还有开源代码函数级复用，示例代码借用。特别是在云原生开发背景下，软件开发迭代速度飞快，代码的广泛复用是不可避免的。谷歌的 Google Progect Zero 安全实验室发表的漏洞利用根因分析研究指出，2022 上半年，被黑客在野利用的 0day 漏洞中有一半是历史漏洞的“重现”
94、“翻版”。有时开发者会在项目重构时忽略以往的漏洞修复代码，有时开发者会复制上游项目中已经存在的漏洞。还有一些厂商会自行维护上游项目的分支版本，但上游项目出现漏洞时分支版本要做修复会遇到因为版本差异导致的漏洞判断困难、修复困难等问题。还有一些开发者在函数级别引用了带有漏洞的代码，又没有申明依赖关系，以至于上游漏洞被发现甚至解决后都没有意识到自己项目中有漏洞存在。还有一些漏洞共享的根因是不可修复的，需要对出现漏洞的各处代码逐个修复，但下游开发者不一定都能意识到这一问题。现有分析技术对规模化解决相关问题的盲区行业面对开源代码的安全威胁有两种主流的代码分析技术，分别是 SAST 源码静态安全扫描测试和
95、 SCA 软件成分分析。52腾讯云技术实践精选集 2022但这两种技术解决不了上述问题，存在很多盲区：SAST 的规则类分析过于面向语言相关、通用基础 Bug 模式，对真实、具体漏洞逻辑无感。大量漏洞所采用的都是规则覆盖不到的模式。SCA 技术基于显式依赖属性或相似性度量，思想本身有制约。这种技术无法进行细粒度分析，无法发现逻辑同源漏洞。SCA 所定义的相似性指纹一般不具备可解释性，自然也无法迭代演进。SAST 的规则需要高水平的安全人员编写，需要对漏洞根因有深度理解才有较好的效果，在安全人员紧缺的行业中这是很难做到的。且相关规则很难修正，实践中经常“照本宣科”，为了减少误报还有很多规则会被忽
96、略。规则的社区生态建设也缺乏基础，大量规则的编写工作仍由少数开发人员掌控。现有方案执行效率低，系统庞杂，难于部署、迁移、使用、更新、扩展，DevSecOps 集成的形态和效果不如预期。一种面向代码复用问题挖掘的技术速览腾讯云针对上述安全问题，尝试采用一种创新方法来突破现有挑战。该方法的核心理念是语义和签名的折中。一如“核酸检测”对比“全基因测序”的关系，该方法仅以关键特征“基因”为探针，判断符合性，而无需做长序列相似度匹配。“特征工程”从语法层面，比语义更有定向表示能力，比签名更有泛化能力。53腾讯云技术实践精选集 2022具体实现来看，该方法尝试寻找有问题的代码片段，这个代码片段类似于病毒模
97、板，其特征通过代码补丁的形式承载和体现。整个工程还是落到 SAST 静态源代码扫描平台上，通过平台寻找符合特征点位的代码片段，从而解决当前 SCA 无法对细粒度代码做分析的问题。该方法的框架分为三大部分。首先将打补丁前后同样版本的代码片段引入到平台中，还原到语法层面来看前后语法之间有哪些差异，进一步找出有哪些语法结构是完全匹配的，有哪些语法结构不同，但实际上存在映射关系；定义差异后开始要素翻译，将这些 AST 差异翻译为 SAST 所能理解的代码查询条件，这里将差异节点翻译为该层面的描述语言，描述节点存在哪些上下文，描述目标位置及特征，这样就可以形成查询条件，有机排列组合后得到大量查询规则；最
98、后再用这些规则做回归测试，确定哪些规则可以有效检出目标代码，哪些规则会引入误报，从而更新规则。上图是一个实战案例，该案例涉及一个代码补丁，其核心引入了一个新增的条件判断，不符合特定数据规则就直接忽略。把它翻译成为 AST 抽象语法数，在语法数层面进行语法要素的识别和映射，可以找到它的差异节点。再把它翻译成为对应的查询语句，拼出来很多查询语句条件。接下来把它喂给回归测试，得到一个能够保证检测出预期漏洞，并且尽量少误报的最简规则。我们使用生成的规则发现了 LibreSSL 项目存在同源异构漏洞，该漏洞是因为下游项目没有跟进上游修复而造成的。54腾讯云技术实践精选集 2022技术方案与 DevSec
99、Ops 集成实践前瞻目前上述方案还在前期开发和攻坚阶段，但我们希望未来它能集成到 DevSecOps 的实现中。集成 DevSevOps 的核心思想是两个双轨制：一是敏捷持续和持续测试并行，二是反哺开源社区与商业化输出并行。在软件的完整生命周期中，开发及预发布阶段就要接入安全测试来修复安全问题，这就要求安全扫描能力可以在有限的时间内以最高的准确度给出结果。但同时还有很多安全分析的工具和方法致力于发现更深层次的漏洞，或者以更高的泛化能力去发现未知漏洞。这就是持续测试的理念，是在软件开发生命周期之外，在软件当前运行的所有版本中后台运行测试。这种持续测试可以有一套稍微宽松的规则，这些规则由各个厂商的
100、安全研究员跟进，解决高隐藏高危害、有独特性的问题，从而领先黑客来做前瞻性安全防护。我们的方案在理想情况下预计可以针对整个开源软件生态中所有软件和项目实现历史漏洞的覆盖，针对每一个历史漏洞都实现对应的规则，形成非常庞大的规则库。规则库将向社区开放，开源维护者都是受益者。这样开源软件生态参与者可以及早发现代码漏洞，避免这些漏洞对软件造成危害。对于私有项目来说，该方案可以集成到腾讯自研的 DevSecOps 流程中，形成开源漏洞规则集，让接入 DevSecOps 平台的所有开发者能够分析所有私有项目中包含的历史 Bug，确保项目不会再引入开源项目中的已有漏洞。总结首先，代码复用形式多样，各种形式均可
101、能构成 安全漏洞。静态分析工具面对复杂的代码复用场景，从机制和实践中均无法满足需求，难以解决问题。对此，腾讯云提出了一种基于“结构化比对”和“要素翻译”的技术研究，增强 SAST、解决 SCA 盲区问题。未来，腾讯云会将这种能力集成到软件生命周期，并向整个开源生态贡献能力扫码获取完整版演讲 PPT55腾讯云技术实践精选集 2022大数据与云数据库技术探索及实践0256腾讯云技术实践精选集 2022腾讯云大数据 TBDS 在私有化场景万节点集群的实践杨鹏程腾讯云 高级后台开发工程师腾讯云 TBDS 大数据团队存储组件研发负责人。毕业于武汉理工大学计算机系，在大数据存储、缓存加速以及实时计算等领域
102、有着丰富的落地经验。在当前越来越强调云原生的环境下，存储计算分离已经是大势所趋。存算分离的存储资源和计算资源的解耦，以及计算资源的弹性扩缩容能充分地提高系统整体资源的利用率和系统的健壮性。几乎所有我们熟知的云数据库都已经开始使用存算分离实现资源价值的最大化，不过在私有云场景下，国内的存算分离大规模实践还比较少。这主要是由于私有化场景比较复杂，需要考虑私有化客户的技术人员在大数据领域的固有技术栈、新老架构平滑升级、不同客户的存储计算引擎有一定的差异等一系列问题。在 DIVE 2022 北京站上，腾讯高级后台开发工程师杨鹏程带来了题为腾讯云大数据 TBDS 在私有化场景万节点集群的实践的分享，聚焦
103、腾讯 TBDS 大数据团队通过 Alluxio+Ozone 进行存算分离架构优化，以及存算分离在私有云下大规模集群的实践。57腾讯云技术实践精选集 2022Hadoop 体系下存算一体存在的问题及解决思路大数据发展多年来，根据业务特点可分为四个阶段：1.Hadoop 体系的存算一体阶段。这种模式的计算层有一定的数据本地性，减少了一定的网络 IO，有一定的加速作用。在规模集群较小且节点数较少时，每一个节点存储分配到的总体文件相对较多，加速效果明显。但随着集群、数据规模和节点的增加，本地加速的优势越来越小。相反，由于集群节点对存储和计算的硬件配置要求较高，整体扩容成本也比较大。HDFS 的 Nam
104、enode 元数据扩展性也有瓶颈，导致集群整体的规模上限有瓶颈。为解决这个问题有了存算分离，也就是第二个阶段。2.存算分离阶段。由于存储资源和计算资源对计算机硬件的配置要求不同，所以存储机器的成本会便宜很多。但这个阶段的存算分离最大的问题是：计算要通过网络 IO 去远端存储获取数据，计算速度和效率会比存算一体差很多。3.数据湖阶段。数据湖主要是为了解决业务的多样性以及业务之间数据共享难的挑战而诞生的。数据湖里有一种统一的表格式来支持数仓和上层进行共享计算。4.云原生阶段。云原生希望运用多个弹性计算资源，但计算层并不用关心整体调度细节，以及调度过程中的容错、迁移、重建等操作。存算分离也是借助于云
105、原生和缓存加速才真正有了大规模生产实践的落地。首先来看 Hadoop 体系下存算一体架构存在的问题。HDFS NN 的内存结构主要分为四个部分，一边是 Namespace 和 BlockManager，另一边是内存的网络拓扑等结构。Namespace 维护了整个文件系统的目录结构，是按照树状结构维护的。集群中的目录和文件总量就是整个 Namespace 目录树中包含的节点总数，所以这块的内存会随着集群内文件一级目录个数的增加而成比例增长。BlockManager 维护了整个文件系统与数据块相关的信息，以及数据块的状态变化。这块内存也是会随着集群内的文件个数以及大小而成比例增长。网络拓扑结构维护
106、着整个机架的拓扑以及 Datanode 的基本信息，即使扩容到上千节点规模的集群，这部分使用的内存也比较小且固定，不会随着集群文件个数的增长而变化。其他一些小的结构所使用的内存都比较小，而且不会随着集群文件个数的增长而变化。从内存结构可以看到，Namenode 文件系统元数据以及块信息的位置基本全部存在内存中，随着数据规模的持续增长，内存占用会逐渐增大。所以 HDFS 面临的三大主要问题：NN 元数据扩展性挑战、单机内存限制、JVM 要求高；块上报风暴，重启时间长；全局锁，大量并发写效率严重下降。所以 TBDS 在私有化客户的经验值是，Namenode 一旦超出了 150G 内存，或者整体集群
107、文件规模数量达到 5G 时就开始新建集群，但新建集群和旧集群的数据是不通的，集群之间也会形成数据孤岛。58腾讯云技术实践精选集 2022其实只需一个 HDFS Client 加不同孤岛集群的配置文件就可以达到一个 Client 端访问不同集群数据的目的，但每一次都要切换对应集群的配置文件。如果不同集群配置文件信息都汇总合并成一个配置文件，就可以用同一个 Client 和同一份配置文件访问不同集群。但是这样又导致了新的问题不同集群的 HDFS Schema、Namespace 名字不同，文件路径还是割裂的。为解决这个问题，HDFS 社区提出的方案是在 Client 端用一个新的 ViewFS 挂
108、载表，统一管理多个 HDFS Namespace 路径的映射关系，让不同的集群文件路径和 Schema 都统一成新的 ViewFS，这就是 HDFS Federation 联邦。但 Client 端协议由 HDFS 变成了 ViewFS，另外子集群信息以挂载表的方式配置在 Client 端，一旦集群发生了机器迁移变更，所有的 Client 端配置都得改变。这种情况下，尤其是在私有化场景，引导客户升级和维护的成本都非常大。基于这种考虑，HDFS 社区在后来的 2.9 版本上又提出了 Router 联邦。它引入 Router 服务去管理路由挂载表，对外由 Router 对 Client 端提供 H
109、DFS 协议的解析及访问来代替 ViewFS 协议，达到了向下兼容的目的。TBDS 是基于 Router 联邦的方式解决 HDFS 多集群数据孤岛问题，让集群之间的存储能够互通。在 Hadoop 集群之下绝大多数的业务都是通过 Hive 库表的方式访问 HDFS 存储，虽然解决了数据存储的孤岛问题，但是无法让业务跨集群联通访问。所以还得解决 Hive 库表的跨集群联通问题。TBDS 基于 HDFS Router 这个思路自研 HiveMeta Router Federation，实现了跨集群的 Hive 元数据的联通与统一。HiveMeta Router Federation 实现了 Hive
110、Meta store 库表大部分常见 Thrift 协议以及 SQL 语法解析，对计算引擎提供了 HiveMeta 服务。我们通过 Federation 解决了数据和库表元数据的孤岛问题，让上层应用基本可以无感知底层变化而实现跨集群的数据互通。但 Federation 也有一些问题：第一是它增加了数据访问调用链路，在大量 Shuffle 作业时增加作业整体耗时；第二是该架构只多了一层 Router 代理，没有根本改变原来的存算一体架构，HDFS 和 YARN 在一起混部，在大规模集群对 JVM 要求很高的情况下又增加了相互影响的风险，加大了集群的不稳定性，也不能独立分片扩展；第三是资源成本问题
111、，容易出现冷热集群，需要动态均衡调整。存算一体集群成本高，尤其是大规模集群，同时满足计算和存储需要，硬件配置高，一方资源不够就要整体扩容。不同时段对存储和计算的需求不是相当的，计算和存储对硬件资源要求不同，需求也是弹性变化的。基于后面两点的考虑，我们开始了基于云原生的存算分离架构的演化。59腾讯云技术实践精选集 2022TBDS 存算分离架构演进及三层优化我们的架构设计主要考虑三点，分别是核心扩展性、海量存储计算速度以及云原生。核心扩展性主要是指存储、元数据和调度计算独立的物理扩展性，这种独立扩展性能要达到上万节点的规模能力；海量存储计算速度主要是为了解决存算分离带来的大量网络 IO 的问题，
112、通过缓存加速等手段可以实现数据本地性能的能力；云原生主要是基于计算和调度依赖的云原生 K8s 能力，实现弹性计算以及自动容错。以上是 TBDS 存算分离的架构图。在存储和计算层之间加了一个元数据层，计算层又分为计算资源层、计算加速层和计算引擎层三层。我们把可扩展性核心交给存储层，因为存储层的扩展难度是最大的，只要存储层是可扩展的，上面的所有层理论上都可以扩展，其他上层内容可以通过分布式解决。存储层主推腾讯自研并共享给阿帕奇社区的 Ozone 对象存储。Ozone 在文件的元数据架构上通过拆分以及 Router 分布式方式，解决了 HDFS Namenode 元数据中央节点无法扩展的问题。因为
113、TBDS 面向私有化场景，考虑到客户的现有情况，我们存储层也支持亚马逊的 S3、阿里的 OSS、华为的 OBS，支持标准对象存储协议的对象存储，也兼容老的 HDFS 文件系统存储。针对不同的场景，我们会选择不同的计算引擎，甚至会使用不同的元数据格式的数据。元数据层支持 Iceberg、Hudi 这种面向数据湖的表格式，也支持 Parquet、Orc 这种传统的 Hive 数仓表格式。60腾讯云技术实践精选集 2022我们也自研了“统一元数据”服务，解决元数据层的扩展性问题，它也同样支持大部分 HiveMeta 的标准协议。计算资源层支持 Kubernetes 和 YARN 的计算调度。我们根据
114、不同的集群、不同物化的计算引擎去在 Kubernetes 和 YARN 中做选择。计算加速层采用 Alluxio 作为计算引擎到存储引擎大量网络 IO 的缓冲纽带，Alluxio 带来的数据本地性让我们上层应用享受更快的速度。接下来看我们目前做的设计和优化。对于存储层，针对元数据扩展性问题，Ozone 把 Namespace 元数据服务和 BlockManager 拆分为两个服务。OzoneManager 负责元数据服务，StorageContainerManager 负责数据块管理、节点管理和副本冗余管理。针对块上报风暴问题，StorageContainerManager 无需管理默认的 1
115、28 兆的 Block 信息，只需管理默认 5GB 的 Container 信息，可以极大减少对管理的数据量的依赖，从而提升了服务性能。OzoneManager 内部的锁是 Bucket 级别，可以达到 Bucket 级别的写并发。因为 Ozone 是对象存储，所以对象存储的语义不存在目录和树之间的关系，也不需要维护全局文件系统的系统树，从而实现高吞吐。Ozone 同时支持 HDFS 和对象存储的双重语义，支持 CSI 协议给 K8s 协议挂载盘，也支持标准的 S3 协议。整体性能和 HDFS 差不多，但是稳定性尤其是千台节点规模以上的稳定性比 HDFS 好很多。计算资源层，5000 个节点是
116、 K8s 集群的扩展性瓶颈。同时 K8s 的调度性能与 YARN 有数量级差别，K8s 在 1000 Pods 每秒的调度情况下性能已经严重下降，难以支持大规模数据调度场景；在超大规模集群高并发的场景下，APIserver、Etcd、监控、日志等都会存在明显的瓶颈。我们针对原生的 K8s 节点扩展性以及调度能力瓶颈做了自研的统一 K8s 调度引擎，来优化解决这个问题：61腾讯云技术实践精选集 2022用户提交任务 Pod 之后，把它提交到租户集群内，租户集群的 Controller-Manager 给它创建 Pod，然后 Mongo-Scheduler 调度器会调度 Pod 到具体某一个底层物
117、理 K8s 集群的某个节点上。如果这个节点在租户集群这边还没有创建出来，Syncer 模块会将这个节点以虚拟节点的形式创建出来，并且定期同步物理集群的 Node 心跳信息到租户集群。如果 Syncer 模块发现底层物理集群还没有创建 Namespace，它会创建一个租户集群 Namespace。并且会统一给租户 Namespace 在底层物理 K8s 集群映射的 Namespace 上加一个前缀，保证全局唯一，避免冲突。接着 Syncer 模块会创建 Pod 依赖的 Secret、Configmap、Volume 等对象信息，同步到底层的物理 K8s 集群上。Syncer 创建底层同名的一个
118、Pod，修改 Pod 里面的属性。物理 K8s 集群的 Kubelet 就会运行这个 Pod，最终 Syncer 感知到物理集群 Pod 的状态发生变化，就会把 Pod 的状态和 Event 事件同步到最后，Client 用户就能收到这个 Pod 的状态，这就是通过自研调度器提交 Pod 任务运行的流程。计算加速层优化，我们引入 Alluxio 做计算加速。Alluxio 提供了主动和被动两种方式拉数据，我们可以提前在跑任务之前主动把 Hive 表里面的数据加载到 Alluxio 的 Cache 里，进行计算加速。利用 Alluxio 的 Prefix 前缀 Level 预热能力，可以提前按照
119、表的分区级别设置成前缀，然后让数据加载到 Alluxio 的 Cache 里，并且将数据和周期的调度时间成比例地设置 TTL 过期时间，保证分区的计算数据可以计算完后迅速过期，给 Alluxio 腾挪出更多的空间去缓存最重要的数据。当计算引擎需要的文件向 Alluxio 拿 Block 时，Alluxio 发现本地的 Cache 里没有这个 Block，就会向后面底层的 UFS 去同步访问相应的Block 内容，并且 Cache 到 Alluxio 的 Worker 节点中。这种被动方式第一次比较耗时，但是对于后面计算要重复使用的热数据也有比较明显的加速效果。Alluxio 也提供了元数据 C
120、ache 能力，减少 List 操作的高耗时，提升元数据访问性能。62腾讯云技术实践精选集 2022下图是 Alluxio 部署在 K8s 计算层的一个典型的存算分离场景。云原生下的计算引擎优化和最佳实践下面讲实践中计算引擎的优化，主要以 Spark 计算引擎为例。Spark 在物理集群中的常见的工作流：首先通过 Spark-Submit Client 提交运行一个 Submit Job 到 YARN 或者到 Mesos，接着 Mesos 或者 YARN 分配两个 Worker 节点作为 Executor 给 Spark Client，然后 Spark Client 会向 Worker 启动
121、Spark Executor，并且在 Executor 里启动一个物理执行计划。Spark Executor 的每一个 Task 要从远端的 Ozone 或者 S3 的对象存储访问数据，然后计算。这种模式中的计算都是通过网络 IO 从远端访问数据，网络时延和 IO 都会影响计算速度。63腾讯云技术实践精选集 2022上图是在物理机上 Spark 经过 Alluxio 加速计算的流程。不过这种在物理机上经过 Alluxio 的加速模式放在 K8s 上部署后会有问题。首先 Alluxio Worker 的 Pod Host 是 K8s 集群里分配的，它和所在的宿主机的 Host 是不同的，导致我们
122、没办法通过 Pod 的 Host 去分配 Spark Executor 数据就近的 Pod。我们在实践中配置 Pod 的 Host 的 Network 属性，配置成 True 就可以让这个 Pod 共享宿主机的 Host 来解决这个问题。这里又有两个新的问题，第一个是 Spark Alluxio Pod 的 Host 和宿主机的 Host 不一样，匹配不到。这里同样让 Spark Executor 这个 Pod 可以开启 Host Network 这个属性，它就可以以物理机的 Host 的方式去分配和 Alluxio Worker 同一个物理机的节点去进行本地计算；第二个问题是，即使能让 Al
123、luxio Worker 和 Spark Executor 分配到同一个宿主机上去，但是因为 Alluxio 的 Client 只能通过短路读，或者是 Local Domain Socket 的方式去访问 Worker 开启这个文件，但是 Pod 之间的文件系统又不互通。虽然我们可以通过 VolumeMount 方式共享宿主机的文件，但是具体要访问的文件路径和目录也是动态变化的，而且这种存储文件相对比较大，这种 Mount 的方式相对访问来说是很不稳定的。我们实践后的解决办法是：让 Alluxio Worker 通过挂载 HostPath Volume 方式共享 Domain Socket 到
124、宿主机。比如说挂载到 OPT Domain 这个路径，然后由于每一个 Alluxio Worker 在 K8s 里都有一个唯一的 Pod 的 UUID，所以我们会把这个 Pod 的 UUID 挂载到这个路径下面，具体的文件就变成了 OPT Domain UUIDA。Alluxio Client 会去 Alluxio 的 Master 询问文件的 Block 所在的 Alluxio Worker 的 Pod，所以 64腾讯云技术实践精选集 2022Alluxio Worker 会把自己这个 Local Socket Domain 通过 Master 发给 Client，然后 Alluxio Cl
125、ient 就可以在宿主机上通过匹配 UUID 的方式查找到 Worker 的 Domain Socket 的文件，也就是前面提到的 OPT/Domain/UUIDA，然后匹配到具体的宿主机，并且在这个宿主机上分配具体的 Socket Executor 启动任务。Socket Executor 同样也挂载和 Alluxio Worker 一样的 HostPath Volume 路径，Socket Executor 里面的 Alluxio Client 就可以通过 Domain Socket 的方式去访问这个路径的文件进行本地数据加速。总结此次分享主要包含三部分内容，第一部分提到存算一体的扩展性问
126、题及原因，我们通过新增集群的方式解决了扩展性问题，随后又带来了数据孤岛的问题，我们通过联邦方式解决数据孤岛问题，但联邦的存算分离架构也依然存在一些问题，于是我们开始了基于云原生的存算分离架构演进；第二部分围绕基于云原生存算分离架构的演进，重点讲了存算分离三层架构以及扩展性问题、存储层 Ozone 扩展性、K8s 层扩展性、Alluxio 加速效果；最后一部分是计算引擎的实践优化，尤其是 Socket on K8s 模式下的实践。扫码获取完整版演讲 PPT65腾讯云技术实践精选集 2022PB 级数据秒级分析，腾讯云原生湖仓 DLC 架构揭秘于华丽腾讯云大数据专家工程师腾讯云原生湖仓产品 DLC
127、 内核研发负责人，毕业于复旦大学数学系，近十年公有云大数据经验，基于 AWS/阿里云/腾讯云打造业界领先的云原生湖仓数据平台，在数据湖存储、Severless 计算、统一元数据有丰富落地经验。过去几年，数据湖能力已经在腾讯内部包括微信视频号、小程序等多个业务大规模落地，数据规模达到 PB 至 EB 级别，在此基础上，腾讯自研业务也启动了云原生湖仓能力建设。云原生湖仓架构最大的挑战什么？腾讯云原生湖仓DLC从哪些方面着手解决问题？针对上述问题，在 QCon 2022 全球软件开发大会（广州站）上，腾讯云大数据专家工程师于华丽带来了主题分享 PB 级数据秒级分析，腾讯云原生湖仓 DLC 架构揭秘。
128、云原生湖仓的诞生背景、价值、挑战当前这个阶段，相信大家对于数据湖，数据仓，湖仓一系列的名词已经不算陌生了，我用最直白、最狭义方式去解释“湖仓”的话，就是数据湖跟数仓存储架构统一。数据湖最初的需求是，要存储和分析海量的半结构化、非结构化的数据，以及数据仓备份和温冷数据存储。在公有云找到了对象存储（海量、低价、高 SLA 和高可靠性）这样一个全托管的存储产品后，成本方面对66腾讯云技术实践精选集 2022象存储对比客户 HDFS 自建大概为 1：10，非常有吸引力。这个存储系统看起来这么好，有没有可能把数仓一起解决，结构化数据是不是存在这里？伴随着这个需求的升级，现代湖仓架构的基础也随之产生。云原
129、生湖仓又是什么呢？最狭义的理解就是容器计算+K8s。更加广义的理解应该长在云上，更多的使用云上已有的全托管产品，比如利用对象存储、本身服务云原生化等。在云原生湖仓架构下，会面临很大的挑战就是“性能”。为什么有“性能”的挑战？第一：对象存储有很好的成本优势，但是引入对象存储之后变成了存算分离的架构，损失了本地计算，整体性能损失 30%以上；其次弹性计算跟分析性能是矛盾的变量，ScaleUp 需要时间，甚至有可能弹不出来，没有文件缓存，弹性会引起数据倾斜；最后是敏捷分析，海量明细数据直接分析也是很直接的需求。腾讯云原生湖仓产品 DLC 如何应对挑战DLC 产品定位DLC 的第一个特点，简单三个字概
130、况便是“全托管”，不同于 EMR，DLC 是开箱即用的，例如交互界面、元数据、安全、Spark DDL Server、Spark History 服务等都是全托管、免搭建的，甚至有很多是免费提供的。第二个特点，DLC 是腾讯云数据湖解决方案的粘合剂，不同产品能够用一份湖仓数据，带给用户低成本，低维护成本的价值。DLC 架构理念接下来讲 DLC 的架构理念，DLC 是腾讯大数据自研能力的上云，但是并不是简单平移部署，产品形态便是最大的差异，DLC 是多租户的全托管产品，我们秉持两大原则：保持简单 KISS、云原生。保持简单上我们是非常执着的。67腾讯云技术实践精选集 2022 对于服务引用非常保
131、守，服务能少则少，取而代之的是 SDK 的接入，例如上图右侧的 Presto 的 Local Cache 就不会引入 Alluxio Cluster，Spark 这儿不引入 RSS 服务而是轻量简单的 Shuffle Manager 等等；降低使用复杂度，DLC 集成了腾讯自研 SuperSQL，去实现统一函数和语法来去两个引擎无缝切换。上图右侧大部分服务都是托管的，如元数据、调度、权限、DDL 服务、Spark History 等这些服务都是用户免搭建，开箱即用的，大部分是免费的，而且我们还给到了用户一定的免费额度，只要配置得当，基本是能满足客户需求的。云原生原则：狭义的说，DLC 都是基于
132、容器的，包括计算引擎和各种服务容器化。广义的说，云原生更应该“长在云上”，DLC 是直接使用云上的对象存储、云数据库、云 Kafka、TDSQL 等等全托管 SaaS 服务的。LC 实现 PB 级数据秒级分析回到最开始的问题“高性能”，PB 级数据秒级分析该怎么去做，从三个大维度展开。我们从三个层面出发讲，第一从多维 Cache 的角度出发，包括文件缓存，中间结果缓存等；第二从弹性模型出发；第三从三维 Filter 的模型：分区、列、文件出发。68腾讯云技术实践精选集 2022多维 cache多维 Cache 分了三个角度：1.文件缓存；2.Fragment 结果缓存，中间结果缓存；3.元数据
133、的缓存，重点说说前两个。文件缓存。我们在 DLC 上线了 Alluxio Local Cache，优点是没有单独的 Alluxio 集群，也不占用计算资源，免运维。当然也会有需要优化的地方，比如文件/Split 级别、跨租户 Cache 缓存数据安全、缓存一致性、弹性影响、监控、黑名单等，这些优化空间 DLC 都会帮客户完成。在一些情况下，访问 Cos 的性能有 310 倍的提升。Fragment 结果缓存。优点是不需要预计算，我们知道物化视图也非常流行，但是物化视图的利用率往往不好量化，事实上通常很低，而根据访问行为缓存下来的是用户行为肯定的；另外是用户几乎没有什么成本，同时也很大程度上降低
134、底层存储的压力。当然，还会涉及到一些问题需要大家注意，例如缓存一致性、跨租户的安全等。性能方面，从来自 Presto 社区的数据看，Raptorx 有接近 10X 的提升。虚拟集群弹性模型刚才讲两种缓存效果接近 10 倍的性能提升，对弹性模型就有了很高的要求，因为缓存的命中是很依赖集群拓扑的稳定性的。另外资源启动要时间，新拉容器和镜像最快也要 12 分钟；最后 Client 预热很重要，包括各种服务都是 Lazy 加载的 Module 等等，这也都是需要 30 秒甚至 1 分钟的时间，这跟我们要求的秒级分析就差太远了。那 DLC 是如何解决这个问题的呢？我们采用了虚拟集群架构，以子集群为最小单
135、位去横向弹子集群，这样子集群拓扑稳定，资源跟 Client 都有很好预热。而且因为子集群的 Query 隔离，子集群也是很容易缩容的。69腾讯云技术实践精选集 2022多维 Filter 过滤继续说性能提升，还是 IO 优化，技术也是比较成熟的，只是还不怎么普及。先看第二个，列存 Parquet/ORC，结合引擎 Project 的下推，这样只有关心的列才会被扫描。第三个分区/分桶也比较常规了，但是最新业界的新特性比如 Dynamic Partition Puning，可以很好地加速分区需要推断的场景。下面仔细说说稀疏索引，Bloomfilter、Zordering 本质逻辑上是类似的，需要结
136、合引擎的谓词下推减少 IO 扫描，加速分析。在大数据的海量低成本要求下，稀疏索引可以做到降低存储成本并且加速分析性能，通过减少数据扫描量达到性能提升。具体分两步：第一步数据要进行 Cluster，类似的数聚在一起，结合引擎谓词下推，性能达到 10X 以上的提升。同时也能带来存储的下降，这个原理其实很容易理解，类似的数据在一起了，Encodin 压缩能起到更好的效果。这也是大数据引擎，比如说像 CK、Doris 很重要的性能加速模型。稳定性也是大数据很重要的诉求，前面看到像索引的构建都需要进行大规模的数据 ETL。对于稳定性我们遇到了很多挑战，包括虚拟集群弹性模型本身减少了弹性引擎的数据倾斜、I
137、ceberg 减少底层 List、Rename 导致任务失败等等问题。这里我们主要分享下 DLC 的 Spark Shuffle Manager 架构。我们知道腾讯开源了 RSS 的服务 Filestorm，在全托管云原生的场景下我们做了简化和改造，原理是：优70腾讯云技术实践精选集 2022先使用本地磁盘，不足的时候 Spill 到 Cos，下面是业界几种典型的思路，DLC 的做法秉持着减少服务引入、保持简单、降低用户成本、减少用户/服务的运维。效果也很明显，大部分任务/Task 都会以原有的性能完成，少量数据倾斜的任务/Task 会损失一定的性能，但是依然能稳定完成。DLC 作为全托管的产
138、品，还是要强调一下低成本和易用的特性。COS 湖存储 VS 自建 HDFS 的成本优势，其实 80%以上节省来至于 EC、HDFS 要预留资源以及 COS 有各种冷热分层策略进一步降低成本等。基于 EKS 或者 TKE 弹性资源，对比固定资源节省约 50%以上的成本，如果是交互式分析场景，周六周日两天成本就是节省的，晚上也是节省的，离线是类似的。最后 DLC 是全托管的免运维的一个产品，统一的 SQL 在两个引擎平滑迁移，SaaS 的元数据、DDL 服务、权限、调度、SaaS 级别的 Spark History 保障了用户开箱即用，而且这些公共服务大部分免费，有的是有免费额度的，正确使用都完全
139、够用。第三部分：湖仓背景下的建模新思路71腾讯云技术实践精选集 2022接下来一起看下，在云原生湖仓架构下，建模有有哪些新思路：第一个，扁平湖仓架构，核心是不再维护复杂的数仓分层，而是把明细层的数据能够直接高性能分析；第二个是离线增量；第三个，现在业界比较时髦的新方向实时增量湖仓。仔细讲一下扁平湖仓的结构，要解释为什么需要扁平湖仓建模，首先要看一下为什么要一层层去做分层建模，首先是在传统的数仓架构下，明细数据的分析的性能不够高，被迫去进行的预计算，同时因为多个结果可能会重复利用一部分公共数据，进行了 ETL 抽取。但是在 PB 级数据秒级分析的能力下，这些几乎都是不必要的。层层建模的问题：第一
140、是模式是固定的，不够敏捷。响应需求，从需求对接、历史数据刷新、测试验收，一两个周就过去了；其次是计算利用率往往是低的，尤其 Cube。Cube 虽然命中很快，单 Cube 的利用率往往是个大大的问号，从我们的经验来看其实非常低；另外分层离线更新是比较慢的，而现在特别火的实时增量更新并不是成熟和稳定，即使落地了对于存储和计算硬件的需求往往也是很高的。结合前面讲的云原生湖仓做性能提升的各种手段，在明细层直接分析的扁平湖仓架构的时代自然是大势所趋了。当然最好能结合 BI 工具的时序结果缓存，这样 BI 层都可以省去。72腾讯云技术实践精选集 2022最后介绍下一个游戏客户的案例：实时扁平湖仓秒级分析
141、逻辑架构非常简单直接，数据都是在 Kafka，通过 DLC Spark 去做实时数据的接入，直接写入几百张 Iceberg 明细表，并且能够保证幂等。值得注意的是一个 Kafka 里面有很多张表的数据，保证幂等也有一些比较有意思的逻辑。入到明细表之后，开启明细表背后的一些优化，用 DLC SuperSQLSpark，进行清洗、合并小文件、以及稀疏索引构建等，最后达到的效果直接用 DCL SuperSQL-Presto 去做秒级分析，最后去对接 BI 的工具，达到一个非常好的分析性能，架构简单明了，无需各种建模。扫码获取完整版演讲 PPT73腾讯云技术实践精选集 2022CDW PG 大规模在线
142、数仓技术构架分享张倩腾讯云数据库专家工程师腾讯云数据库专家工程师，中国人民大学博士，具备多年数据库内核研发经验，曾在 Teradata 天睿公司以及华为公司高斯实验室工作多年。加入腾讯后，负责 CDW PG 数据仓库内核优化器、执行器等多项核心功能研发。腾讯云数仓产品 CDW PG 是一款面向超大规模集群海量数据分析的在线数仓。通过创新的数据转发平面、全自研列式存储、分布式延迟物化技术，以及向量化执行引擎等核心技术为用户带来极致的数据分析体验，可以真正将海量数据所蕴藏的价值释放出来。ArchSummit 2022 北京站上，腾讯云数据库专家工程师张倩带来题为CDW PG 大规模在线数仓技术构架
143、分享的分享，主要聚焦 CDW PG 在构架设计以及核心优化上面的一些经验和思路。CDW PG 发展历程介绍CDW PG 是腾讯基于 PostgreSQL 自主研发的分布式在线关系型数据仓库。PostgreSQL 是一个单机版数据库，我们在这个基础上开发了一个无共享 MPP 架构，支持行列混合存储，同时支持超大规模集群，目前集群规模可以支撑到上千节点，同时可以支撑超高速的计算能力。74腾讯云技术实践精选集 2022CDW PG 的整体架构如上图所示。整体架构演进大规模集群面临的一大挑战是集群扩展性挑战，分布式 JOIN 消耗大量网络连接和对应资源。对于分布式 JOIN，数据是分布在不同节点上的，
144、数据的分布键和分布式 JOIN 的键并不是完全一致，这时数据需要重分布，重分布之后再进行 JOIN 连接才能得到最后结果。数据的重分布通过 DN 节点，把本 DN 自身的数据通过模块连接发送到对应的其他 DN 上。如果 DN 节点非常多，每个 DN 都要和 JOIN 建连，则一个数据重分布就会有很多连接。假如有 200 个 DN 节点，有 100 个并发查询，如果每个查询 5 个重分布，这种情况下可以计算出 10 万个连接。每个连接在每个节点上对应一个进程，对服务器的压力非常大，也是限制分布式数据库拓展性的问题之一。原来的集群架构显然不适合大规模集群，所以我们在这个基础上开发了异步执行框架，一
145、个新型的分布式架构。在这个架构里，我们会在查询优化阶段分析物理查询计划，统一创建 DN 上的各层执行进程，各层执行进程之间不需要建立直接连接，不同层级进程可以异步启动执行。假设我们有 N 个节点，就会产生 N 个进程数，这是进程数上的优化。我们在连接数上会进一步引入 FN，FN 来负责节点间的数据交互。每台物理机只需要布置一个 FN 节点，75腾讯云技术实践精选集 2022FN 节点会负责本台物理机和其他集群内其他物理机的数据交换。在本机节点上，这个 FN 与 CN 和 DN 之间是通过共享来进行数据交互的，本机和其他的物理机进行数据交互的时候是通过网络进行。在这样的分布式架构下，假设有 N
146、个节点，不管 JOIN 有多么复杂，查询可以有十几个 JOIN，它们只有 N*（N-1）个连接数。在优化器阶段会查询计划分片。优化器是根据代价来审核的最优计划。在单机上的代价是一些算子，每个算子有不同的代价；但在分布式的情况下，数据重分布也有自己的代价。优化器会生成代价最优的计划，在分布式的计划里可以看到，Remote Subplan 会有数据重分布节点，数据重分布节点会把下层执行的数据按照一定规则进行数据重分布，生成分布式的计划之后会变成整个执行计划，对这个计划进行分片。分片的原理很简单，我们对每个数据分布节点下面的 Log 节点作为一个组数，划分成一个分片，把分片用 FID 编号。每个分片
147、除了 Remote Subplan 节点，下面的计算都可以在本地完成。本地完成之后再通过 Remote Subplan 节点把数据发送出去，串联起整个分布式的计算。生成这样一个分布式计划之后，会下发这个计划分片到对应的执行进程上，每个分片会在每个执行节点上创建一个进程来执行对应的计划片段。在这个 JOIN 里会分成两个 FN 片，会有 FID1 和 FID2，FID2 对数据重分布，然后再跟 FID1 做一个 JOIN，这样两个计划分片在 DN 片会有 4 个进程。这 4 个进程，每个进程会负责执行自己收到的进程，然后把数据通过 Remote Subplan 节点，不会直接建连，而是把数据发送
148、给本机的 FN，FN 负责把数据转发。不同层级之间的进程是异步启动执行的，下面的分片和下面的分片是同时启动执行的，通过 FN 进行数字交互。自研列式存储我们自研的列式存储支持按照行存储和列存储建表，列表和行表之间可以相互操作，行列表之间的混合查询保证事务一致性。很多查询都是点查询或者是只会操作比较少量的数据，在这种情况下，我们点查每次只出一行数据，在这个行数里面可以获取这一行数据进行处理。但是在 AP 场景中，对于宽表来说它的列会非常多，每次用户操作的时候只操作其中几列，比如说只查名字或者只查名字和部门，或者只查名字和年龄，后面的几百上千列都不会管。如果还按行存储就会浪费很多 IO。后面的列数
149、都是我们需要的，每一列单独存储，多个列逻辑上组成一行，一次的磁盘 IO 只包含一列数据。这种情况下，因为这一个数据文件只存储单列的数据，它的数字类型都是固定的，很方便做数字压缩，也能够提供比较高的数字压缩效果。在我们的数据库里支持行列存储，既可以在行存表和列存表，可以同时互相操作，也可以查询复杂的操作，行列表之间的混合查询能够保证数据的一致性。76腾讯云技术实践精选集 2022上图介绍了我们自研的列式存储，主要包含两部分。第一部分是左边的表，会有一些信息，有 C1 文件和 C2 文件，每个文件里面的数据是按照 Silo 来仓储的，对应的 Silo 信息会存储在这个表里，同时 Silo 的输出上
150、，事务的信息也是通过这个表来保证的。在这样的基础上，可以看到这种数据结构比较适合大批量的数据导入，也就是说我们在做大批量数据插入的时候很快会填满，再写入下一个 Silo，内存的效率最高。但是在很多业务场景中，这个场景并不是很单一，也有可能除了大批量的数据插入之外，还有一些小数据量的操作。这种情况下如果我们还用 Silo 来存储就会显得效率比较低。为此我们开发了一个 Stash 表，它是一个行情表，主要目的是在用户进行小数据量操作的时候，这些数据都会进入到 Stash 表里，提供一个像行存一样的性能和访问能力。在后台我们会有一个 Stash Merge 操作，会定期 Merge。数据积累到一定程
151、度，我们有了整个 Silo 的数据，就会把它生成一个 Silo，从而获得批量性能提升，这对用户来说是完全无感知的。分布式集群里一个比较难的问题是保证分布式数字一致性。我们是基于 Timestamp 的分布式提交协议。我们会有一个 GTS 集群，GTS 集群包括 GTS 组和 GTS 位。GTS 集群是提供给数据控制节点，它是从内部开始，内部单向并且唯一由 GTS 维护，由硬件来保证使用源的稳定度。在这个情况下，加上数据库内部的 MVCC 的存储能力（MVCC 是整个并发控制的基础），这两个结合起来提供了分布式事务的一致性。GTM 单点可靠性是由 GTM 主备来支持的，也就是说主节点可以通过对外
152、提供服务来保证分布式事务的一致性，然后主备之间是通过日志簿时间戳的状态来保证 GTS 的可靠性。对于单点可靠性，数据库里面如果是非常繁忙的业务，TS85 服务器每秒能够处理 1200 万的 GTS，可以满足绝大部分业务团队的需求。77腾讯云技术实践精选集 2022在列存的存储格式中，我们进一步提供了延迟物化扫描优化。传统的方式是把数据扫描上来做对应的计算，生成对应的结果。但在列存的数据格式下我们可以提供一个优化的方式，比如说有一个多列计算，可以先扫描其中一列，如果都不符合条件可以都不扫描，第二列直接跳过，或者我们扫描的这一列里面只有一个数据是符合条件的，在对第二列计算的时候，可以扫描对应的数据
153、位置来计算，相比传统的方式需要扫描所有数据，这种方式可以减少很多 IO，提升扫描和查询计算的性能。同样这个列存也是支持索引的，我们现在支持的是两种索引，一个是 B-Tree 索引，一个是 Hash 索引。列存的 Stash 表后台的自动合并能力是为了小数据量插入和小数据量更新准备的。在这种情况下，数据会进入到 Stash Table 里，然后 Stash Table 会自动做一个 Stash Merge 到 Silo 表里。我们的列存表是支持创建配套的 Stash 缓存表，如果是批量的插入，中心会直接写到 Silo 表，如果是小数据量插入，中心会写入到 Stash 表，但这对于用户是完全透明的
154、，是后台自动判断的。后台也会有一个 Stash Merge 的进程，自动判断这个 Stash 表里的数据大小，进行列存格式的整理。也就是说把 Stash 的表格数据 Merge 到 Silo 里，通过列式加 Silo 表能够达到性能统一。执行引擎能力优化我们执行引擎的能力优化分为几个部分，首先是多级并行能力的提升。我们是分布式集群，天然就提供节点级的并行。在每个 DN 内部，我们又提供了进程级的并行。某个 DN 会有计划分片，计划分片在传统的数据里会启动一个进程完成它。在我们的集群里面，对于同样的一个计划分片，我们会生成多进程并行。一个简单的 Stash 操作，如果有两个进程并行 Stash，
155、效率会提升 50%，每个进程只需要处理一半数据。上面做计算时也是两个进程并行执行，最后得到的结果是两个进程结果的叠加。在进程级的并行基础上，我们还提供了 SIMD 指令级并行。在做计算时可以通过 SIMD 进行指令级并行。Silo 头部会定义一些数据特征，包括 CRC 校验、压缩信息、Bitmap 信息、数据压缩文件，最后有一些页面对齐。我们提供了列存文件格式之后，由于每一列的数据格式是一定的，我们就可以提供一个比较高效的数据压缩算法。在这里我们提供了三层压缩级别，分别是 Low、Middle 和 High。选择了对应的压缩级别之后，数据库内部是根据这个列具体的数据类型来选择不同的压缩算法，。
156、这个压缩算法是内部选择，用户不用自己操心。我们写入的时候会有一个轻量级压缩，再一个是透明压缩，然后是写入 Silo 文件中，然后读取到内存中计算，这个过程对用户是完全透明的。High 的压缩比会达到 5.5，Low 是 3.5 左右。78腾讯云技术实践精选集 2022我们的向量化执行引擎也是基于自研的列式存储上开发的执行引擎。传统的执行引擎是采用火山模型，每次处理一个原子，逻辑比较简单，但效率比较低。数据量非常大的时候，比如我们有非常多的源组库的时候，函数调用和指令级调用都非常多，CPU 大部分时间中数据和指令的命中率都比较低，内存的命中率也很低，没办法利用 SIMD 能力。向量化产品执行引擎
157、每次不是处理一条数据，是处理一组数据。它会显著减少函数调用的开销，提高 CPU 的执行效率。我们这个列存天然可以将一组原子变成一组列存向量，从列存里面，我们可以读取一个向量数据再发送给算子，算子就可以对这一组数据进行计算。这样我们既可以减少函数的调用，又可以实现 SIMD 指令来加速算子执行。我们提供的另外一个能力是 Plan Hint 自动调优。很多场景都是非常复杂的查询，会有非常多层。在这种情况下，我们的顺序和对应的每个表选择什么，都会影响 Plan 的执行效率。传统的优化器是通过我们收集的表统计信息来决定查询的执行计划。但统计信息的收集是通过数据采样大概模拟出这个数据到底是什么样的，显然
158、不太精确。而且由于统计信息收集不及时，会造成 Plan 的劣化，统计收集会有代价，在大数据量的情况下需要很长时间。在这种情况下，我们提供了 Plan Hint 的能力，会把这个计划先执行一遍，收集一下计划中执行的信息，生成 Row Set Hint：每个表里选择了什么样的方式，顺序是什么样的，数据存储方式是什么样的，并行执行的并行度选择什么样的，每一步算子执行实际的数据量是什么样的。生成后还会把信息反馈到 Plan Hint 里面，根据这个信息生成一个新的执行计划，再对比新的执行计划和之前的执行计划，然后把新的执行计划再次通过 Plan Hint 执行，循环往复，最后能够生成比较优的执行计划。
159、这个生成过程是完全自动的，用户可以在后台比较空闲的时间来执行，或者用户有一些调优需求的时候可以自动完成。第三是集群资源管理功能。在整个集群可能不会承载一个业务，有可能会有各种不同的各部门业务，都需要用这个集群的资源。在这种情况下，我们需要对集群资源进行管理和划分。比如说我们做一些并发的控制、内存的控制、CPU 的控制，我们通过 Leader CN 节点统一规划资源组使用情况。资源组里会有三个定义，一个是我们的并发，指我可以同时发起多少个查询；内存控制，决定我可以使用多少内存；还有 CPU 控制，决定我可以使用的 CPU。这样一个资源组是在 Limit 节点上进行统一规划控制，优化器会根据 ME
160、MORY_LIMIT 设置 Query 中不同算子的 work_mem 内存占用。GPU 通过 cgroup 来配置占用百分比或者绑核，所有当前资源组启动的后端进程会挂在对应的 cgroup 上。这是一个非常便利的操作。我们开发的 TDX 服务器负责外部数据源导入和导出的操作。CDW PG 引擎可以定义外部表与 TDX 服务器资源进行绑定。数据由 DN 节点并行导入与数据重分布，充分利用分布式系统资源。TDX 服务器支持并行多任务导入导出、管道、错误表等高级功能，提高用户体验，相比传统 Copy 入库出库功能有数倍提升。我们还有多平面的能力，意思是说我们可以提供两个平面，一个是读写平面，还有一
161、个是只读平面。通过这样两个平面可以做到读写分离，也就是说读写请求可以进入到读写平面，大量读请求可以通过只读平面来完79腾讯云技术实践精选集 2022成。内部是通过 DN 之间的内部复制来保证两个平面之间的数据一致性。后续规划上述内容已经在腾讯云上线，包括异步执行框架、FN 能力提升、自研列存储，分布式延迟物化技术。我们后续在构架上会进一步优化，包括列存优化升级、向量化引擎深度优化、算子并行计算优化、SIMD 优化场景覆盖。我们还会持续打造生态，持续融合 PG 社区能力，在兼容性上会有持续的功能提升，还有大数据生态对接和机器学习算法支持。扫码获取完整版演讲 PPT80腾讯云技术实践精选集 202
162、2云原生数据库管控探索和实践孙勇福腾讯云数据库专家工程师云原生数据库 DBPaaS 平台“云巢”负责人，8 年工作经验。从零设计腾讯云数据库云原生 DBPaaS“云巢”平台，并参与多款腾讯云数据库产品从零到一落地。致力于提供易用/稳定/安全的数据库库产品服务，具备丰富的数据库产品研发等技术经验。云原生是未来发展的潮流，同时数据库是用户业务应用的核心存储组件，如何利用云原生技术手段和数据库结合，提供更好的数据库产品易用性和稳定性是一大重要关键。ArchSummit 2022 北京站上，腾讯云数据库专家工程师孙勇福带来了题为云原生数据库管控探索和实践的分享，主要集中在 Kubernetes 上如何
163、构建有状态管理服务方向进行深入探讨，并在此基础上提供一整套容器化管理数据库的解决方案的新思路。PaaS 平台背景70 年代 SQL 数据库诞生后，数据库技术变革日新月异，迭代非常迅速。从 SQL 发展到 NoSQL 和 NewSQL，数据库也愈加复杂。与此同时，云计算形态也日新月异，从单体到单云再到混合云，多技术、多架构形态将成为未来常态。如何在数据库日新月异及多技术平台形态存在的背景下更好地服务客户，对云数据库厂商来说也是巨大的挑战。针对这些挑战，腾讯云数据库中心有着自己的思考和应对。81腾讯云技术实践精选集 2022腾讯云数据库的产品矩阵有两大模块，PaaS 产品矩阵和 FaaS 产品矩阵
164、，有 200 多款数据库产品。众多数据库产品技术架构不统一，大大增加管理难度。云厂商作为数据库服务的提供者，需要给用户提供全托管的企业级数据库服务，并且也要提供一致性的产品体验、统一的用户界面来提升资源使用效率，给云厂商带来了巨大的困难和挑战。数据库演化的核心是如何把云厂商多年数据库管理的经验输出到用户使用。但烟囱式的发展会带来一种问题，无法对新兴技术的数据库产品快速提供复用和知识，导致新的数据库产品形态往往比旧数据库形态落后较多。除此之外，各个产品之间烟囱式的发展、团队之间技术栈不统一，会导致研发效率的低下。这些单独的产品作为一体化解决方案时，打包、输出起来是非常复杂的。云厂商也在考虑资源成
165、本，烟囱式的发展会存在资源利用不充分的问题。带着这些思考，我们主导和设计了数据库 PaaS 平台。我们对 PaaS 平台提了四个规范要求：1.这个平台必须有规范标准。整个平台要统一标准，减少硬件设施的适配工作，减少影响上层的服务逻辑。2.我们也把安全稳定性作为比较高的目标。数据库是用户使用场景中很重的资产和财产。我们作为数据库服务厂商，一定要保证用户财产的安全。保证数据库的高可用以及数据安全性也是我们平台一项重要的指标。3.我们平台化的思路是实现数据库公共能力的沉淀和经验能力的沉淀，形成莲花效益的相互复用。这样可以降低数据库产品的成本，也能给外部客户实现规模化降本。4.有了通用的 PaaS 平
166、台，可以通过标准的 PaaS 平台构建我们的 PaaS 护城河。传统的烟囱式发展很难做到这一点，因为不同的 PaaS 平台的模型和能力都是不统一的。有了标准平台后，可以站在标准上再围绕客户的某些场景或者行业属性去提供 SaaS 的增强能力，提高用户黏性，拓宽数据库的护城河。基于这样的设计理念，我们有了以下分层设计：82腾讯云技术实践精选集 2022整体架构演进我们选择了 Kubernetes 作为基础底座。但 Kubernetes 的优势是在无状态服务领域，我们在状态服务领域更标准化、更成熟。我们就要围绕 Kubernetes 去解决有状态服务的困难，这些也是我们的云数据库“云巢”设计的核心。
167、云巢是按照平台化的思路演进的。如果只是使用社区的 Operator，只是简单把我们之前通过物理机的方案、烟囱式的发展，变成了以 Kubernetes 底座为平台去做烟囱式的演进和发展，完全没有解决烟囱式发展的问题。所以在我们研发初期直接放弃了 Operator 的设计方案。云巢架构设计分了四个层面。资源管理部分可以理解为通过云原生的 Kubernetes 设计实现一整套的资源调度轻量级管理系统，满足资源高可用、资源生命周期入口、配置管理、面源管理等需求。集群管理和流程管理提供业务作业平台，实现业务的复用性。运维模块提供发现、告警和预测机制。在底层的云巢设计之上，我们再通过业务产品的接入实现业务
168、场景界面产品化适配。同时我们整体的 IS 层是构建于整个腾讯云的 IS 层之上，可以形成复用，有了新的技术红利的演进时可以很快触达云巢，再通过云巢触达各个 PaaS 产品。做整体架构设计面临的第一个问题，是对这种数据库领域资源模型的抽象。因为数据库领域涉及到的产品形态非常多，比如说主从关系、多层树状类型、网状结构等。这些产品之间的数据模型如果不统一，就很难统一抽象资源管理系统，所以第一步要收归数据模型。首先要根据模型的分类分为主从类型、树状类型和网83腾讯云技术实践精选集 2022状类型，模拟一个分布。每款产品都是由组件组成的，只是组件的个数有差异而已。基于这一点，我们通过 Cluster 保
169、持实例元数据的概念，通过 Set 标识组件的属性集合，通过 Pod 承接数据节点的角色。有了这样一个标准设计后，我们很容易构建自己的资源管理系统，比如统一发货、升级、销毁或降级等。我们还可以围绕这样一个标准模型去抽象自己的系统，包括统一的监控体系、管理体系、流程细化等。这是云巢设计的基础和核心。接下来我们要处理节点和节点之间的关系，把这种关系叫做资源模型的属性，所以我们会继续往下沉淀和思考我们的属性模型，通过关系和资源模型的配合，满足数据库产品形态所依赖的所有要素。因为属性是领域知识，不同产品所需要的领域模型、领域知识不一样，变化的部分是领域知识。我们对变化的部分分析和抽象，定义每一类模型的标
170、准定义。比如说调度策略，我们会定义一个标准策略的模型是什么样的，这个模型就会当作领域模型的输入和输出，控制器可以按照领域模型的输入和输出构造设计。我通过领域模型的标准输入和输出以及控制器的组合关系，就可以很快、很灵活地拼接出每款产品个性化的诉求。在发布过程以及实例运行过程中，需要实时对数据库的进程和实例进行灵活控制，怎样管理这样的业务容器呢？设计方向有两个，分别是 Client 模型和扩容器模式。为什么我们没有选择扩容器？因为扩容器存在以下问题，它整体架构比较臃肿，还有业务容器和其他属性进程存在更新不同步，会影响整体的 SLA，这对 PaaS 服务来讲是完全不能忍受的。所以最终我们选择了可以集
171、中管理，灵活控制的点。同时基于这个设计，我们会把一些命令和编排进行中心化设计，放到中心化的控制器中。比如说对配置文件的修改、脚本命令的下发、执行以及服务发现等都会放到中心化控制器操作，用户通过控制单元管理 Pod 节点。有了控制，我们的第一个实际目标是发货，发货过来才能给用户使用。我们发的是有状态服务的实例。每个节点都按照数据启动就好，但是这个方案没办法满足发货效率，因为我们数据库都是节点化的，节点数比较多，随着节点数的增加，发货效率会线性下降。针对发货效率的要求，我们分析整个 Pod 的生命周期，一个是 Init-Container 阶段，一个是 Pre-Slop 阶段。通过启动策略去选择
172、ZK 优先启动，然后下发 CK 去实现启动。这样不管任意节点，只要资源足够，就可以并行发货，效率快速提升。还有一个问题，我们实际的节点启动不是单纯启动，还依赖于一些复杂的配置。比如说启动需要 IP，但是只有在节点发货完成之后才能够获取到，所以要求我们实现一套动态的数据获取机制来满足 Pod 节点下发的要求。我们有一个中心化的实例设计，不管是静态还是动态的源数据都是 Pod 的缩影。同时 Translate 层不能有84腾讯云技术实践精选集 2022侵入性。我们通过配置模版渲染出最终想要的配置文件，再把配置下发到用户所需要的目录，在运行过程中下发和更新，用户不管是发货过程中，还是运行过程中都可以
173、修改配置。通过这样的方案设计，我们实现了云巢配置介入和平台编码的解耦。用户在接入云巢的过程中，只需要把自己的算力模型适配好，把自己的模板写清楚，就可以很快速接入云盘。除此之外，实例运行过程中会遇到各种各样的问题，如 Pod 故障，驱逐/删除等。针对各种各样的异常，怎么实时保证服务高可用、数据高安全性，我们也有一些对策。我们设计了云巢的探针服务，还有多维度的数据采集指标。通过多维度的采集，再通过 HA 的决策大脑，根据决策树模型选择合适的 HA 的落地路径来满足 HA 的要求。为了保证实例安全性，云巢主要涉及到几个方向。首先是基于 NetworkPolicy 限制最小化网络访问权限。为避免某一个
174、用户的安全漏洞影响其他节点的使用，我们通过 Kubernetes NetworkPolicy 的手段实现网络的隔离。对于用户数据链路层面，我们会通过整个腾讯云的安全组机制接续。无论是数据链路层还是容器层面，我们都做了安全保护。还有一个瓶颈是，Kubernetes 的资源非常有限，一个 Kubernetes 只能支持 15 w 个 Pod，但云厂商会有上百万个 Pod。我们有一个合理的思路，通过水平扩容 Kubernetes 去满足资源的无限增长，我们抽象了集群管理，通过集群的源数据的维护以及集群控制器的合理设计去屏蔽业务对多集群管理的细节感知。通过这个解决方案可以快速扩展资源模型，最终达到几百
175、万个节点的管理规模。解决了规模之后，随着产品越来越多会遇到另外一个问题，就是完全不能避免性能的损耗，尤其是网络的损耗。于是我们提出了一个新的网络解决方案，也是利用我们云原生的能力，给每个 Pod 插一张网卡。在数据流量使用过程中，数据流量是直接打到容器网卡上。这样的设计可以把性能提高 10%以上。下一个问题，上了云巢之后，我如何量化感知到一款 PaaS 产品的性能指标、高可用指标？我们可以利用云原生的红利，借用一个平台去模拟机器故障、网络故障或者节点故障等，同时通过可编排的流程引擎、主动触发测试来获得量化指标。这样会给所有上云巢的产品提供一个门槛，只有达到一定的指标值之后才能在上面售卖，这样外
176、部用户的体验感更好，口碑有了保证。在整个 PaaS 模型之上，我们还在发力 SaaS 产品。随着云厂商发展，PaaS 层面的同质化相当严重，这时候需要 SaaS 提高护城河和用户黏性，通过 SaaS 打入用户的个性化应用场景或者一些行业属性，绑定这些行业，或者给这些行业的客户提供一些更具应用性的解决方案，让用户的体验更顺畅。85腾讯云技术实践精选集 2022未来展望数据库可能会出现压力过大、负载过高等问题，响应比较慢。传统上会安排人工分析，再 Kill 会话，重启数据库，HA 主备切换。未来云巢的自治场景可以 7*24 小时做异常诊断，通过合理的智能分析，自动做流量阻断或者 SQL 调优，给云
177、厂商提供更好的服务体验。随着云厂商在公有云的不断沉淀和实践，未来我们也会回归社区。通过回馈社区生态能让大家获取这些福利，同时通过社区的生态点来补足用户个性化场景，能够形成行业规范，反哺腾讯云上 PaaS 产品。扫码获取完整版演讲 PPT86腾讯云技术实践精选集 2022腾讯云原生数据库 TDSQL-C 架构探索和实践王鲁俊腾讯数据库内核开发工程师曾就职于蚂蚁金服、阿里云等，在数据库内核领域有多年开发经历，对分布式系统、数据库存储引擎等方面有丰富经验。TDSQL-C 是腾讯打造的云原生数据库产品，其高可用、高可靠、高性能的特性已经被越来越多的用户认可。在 DIVE 2022 全球基础软件创新大会
178、（北京站）上，腾讯数据库内核开发工程师王鲁俊带来了主题为腾讯云原生数据库 TDSQL-C 架构探索和实践的分享，为大家介绍 TDSQL-C 总体架构和核心能力的持续演进现状，并重点介绍 TDSQL-C 在可用性、可靠性和性能方面的工作，同时结合用户场景分享 TDSQL-C 在实际应用中的实践经验。产品架构介绍腾讯云原生数据库早期也曾采用传统架构实现，但实践中存在很多问题：传统架构的实例存储上限完全受限于本地磁盘容量，扩展成本高昂且操作复杂。用户数据较多时需要分库分表，带来很多分布式事务问题。而用户希望一个实例有 100T 以上的容量，且存储容量可以快速透明扩展。传统架构基于 Block 复制，
179、普通的异步或半同步复制方式可能丢失数据，同步复制方式的性能损失较大。87腾讯云技术实践精选集 2022用户要求数据不丢失（RPO=0），且数据有多副本容灾，可靠性满足要求。传统架构可用性不足，HA 或宕机重启后一段时间（分钟级）不可用，且主备副本延迟较高，有些达到小时级。用户期望能够快速切换 HA，实现秒级恢复、回档，且副本时延在毫秒级。传统架构水平扩展时需要复制一份原有数据库实例数据，再建立同步关系。才能真正水平扩展；创建只读副本时要把原始数据复制过来，然后搭建主备同步，只读副本才能开始工作，过程可达小时级别。用户则希望实现秒级副本扩展。腾讯云针对这四方面的用户需求采用了存储计算分离的架构，
180、就是 TDSQL-C 的核心架构。它的存储是云存储，可以水平扩展，理论容量无限，对每一份数据都有多副本来保证可靠性。数据现在分散在云存储的各个节点上，可以做持续备份、运营回档等功能。在可用性方面，数据的分片可以并行恢复、并行回档，时延更低。可扩展性方面，新建只读副本时数据不需要复制，只需要对数据做共享操作，再构建增量的数据复制即可。TDSQL-C 架构整体分为上面的计算层和下面的存储层。计算层有一个读写节点可以提供读写请求，还有多个只读节点可以提供读请求，也就是上图中的 Master 和 Slave 节点。读写请求进入后，Master 节点产生数据修改，然后把修改产生的 InnoDB 的 Re
181、do Log 下传到存储层，同时会把 Redo Log 分发到自己 RO 节点上。88腾讯云技术实践精选集 2022用户场景实践TDSQL-C 的典型客户场景如下：1.Serverless有时业务端预测未来的需求持续上涨，所以会提前准备数据库实例，但实际需求却偏小，最终会造成浪费。但如果突发情况下实际需求暴涨，实例资源无法立刻跟上，又会对业务造成严重影响。理想情况下，资源容量应该与真实业务需求同步变化，随时保持在比真实需求略高的水平。TDSQL-C 实现了智能化的极致弹性，可以根据负载来快速启停实例。TDSQL-C 还实现了按需计费，可以按秒计量、按小时结算，避免浪费。2.弹性扩容有些业务每天
182、都能产生大量数据，且对单库容量要求很高；有些业务如开发测试场景，某一次测试后数据库实例直接删除，生命周期非常短；有些历史库场景中历史数据只存储最近一段时间，老数据直接删除来节省成本。针对上述场景，TDSQL-C 支持按需扩容，不需要预先进行存储规划；还支持自动回收，按实际使用容量计费等。存储层负责管理所有数据，包括数据页面、InnoDB 层的 Segment。当 Redo 日志发送到存储层之后，Segment 负责 Redo 日志的回放。整个存储层架构在 COS 存储服务上。TDSQL-C 的存储可以自动扩容，最大提供超过 1PB 的容量，最大支持 96 CPU、768G 内存，只读性能超过
183、100 万 QPS，读写超过 45 万 QPS。该架构实现了秒级故障切换、秒级快照备份和回档，且存储和计算层有足够弹性，可以实现一定程度的 Serverless。需要扩展只读性能时，该架构很容易增加只读节点。TDSQL-C 现在最多可以挂 15 个只读节点，且在读写节点和只读节点之间只有毫秒级延迟。整个工程是基于 MySQL 代码库演化来的，所以 100%兼容 MySQL。89腾讯云技术实践精选集 2022系统关键优化以下是 TDSQL-C 支撑相关场景的关键优化：可以看到 TDSQL-C 对比传统 RDS 数据库，在停机时间、启动时间、事务恢复时间和性能恢复时间上都有巨大优势。2.二级缓存二
184、级缓存是 TDSQL-C 在存储计算分离架构下所做的创新优化，也是对这种架构的重要补充。例如存储层水平扩展后数据量膨胀上百倍，但计算节点的 Buffer Pool 容量没有太大变化，意味着相同大小的 Buffer Pool 要服务更多数据。由于 InnoDB 的 Buffer Pool 一定程度上承担了读缓存的作用，意味着读缓存的效率可能会下降，对性能影响较大。1.极速启停3.备份回档很多场景对备份回档要求较高，如金融行业对备份速度和备份时效性都有很高要求，涉及到频繁回档的游戏业务对备份回档速度要求较高。TDSQL-C 支持持续备份，存储分片可以根据备份点独立备份，同时可以设定全局一致的备份点
185、来备份。TDSQL-C 还支持每一个分片并行回档，各自的数据全量、增量备份，并且可以并行回放自己的日志。另外，TDSQL-C 还支持 PITR，可以快速恢复到数据库任意一个时间点的状态。90腾讯云技术实践精选集 2022其次，传统 RDS 的 Buffer Pool 和本地的磁盘空间存储中间没有其他层次的硬件存储设备，但在存储计算分离架构下数据存在远端机器上，需要通过网络访问其他机器的 SSD。这之间有至少两个层次的硬件存储设备，一个是 SSD（本机硬盘），另一个是持久化内存。我们将这一类的存储用作二级缓存，能够有效减缓 IO bound 场景下命中率较低的问题。这种方式的运维成本也不高，因为
186、 SSD 的成本远低于内存。3.极致伸缩存储功能下放到存储层后，存储层有了存储池的概念。这样可以把存储空间扩展到整个存储层，所有存储空间都池化。这样页面回收之后可以在物理上真正删除，而不是只标记为删除，这样能降低客户的存储成本，实现按需计费。4.极速备份回档现在数据分散到了分布式存储上，分布式存储包含很多存储节点，本身还有一定计算能力。所以每个实例、存储节点都可以独自备份，也就是自治备份。有时候我们还需要全局一致的备份点，这时有计算节点负责协调，做统一备份。回档也是并行的，每个计算节点都可以独立做自己的回放。根据测试数据来看，1TB 数据的备份时间用 RDS 实例需要 61 分钟，用 TDSQ
187、L-C 只需 21 分钟；1TB 的回档恢复时间，RDS 需要 168 分钟，TDSQL-C 也只需 22 分钟。5.Instant DDL 和并行构建索引Instant DDL 是 MySQL 8.0 的新增功能，是指用户在新增列、修改列类型、删除列时，实际上仅仅修改元数据就可以直接返回，这样注册时间非常短。原来重建表索引时都是单线程构建，先扫描所有主表数据，再根据每一行数据生成对应的索引行信息，生成临时文件。之后对这个临时文件按照索引行的索引键排序，再将数据导入，完成构建。我们针对这里做了并行优化，包括并行扫描、并行采样和并行导入，很多场景提升到 2 倍以上的性能。91腾讯云技术实践精选集
188、 2022产品未来演进我们探索的第一个演进叫 Global Database：上图左边有一个 Primary 实例，现在新增了一个 Log Store 模块。它负责接收日志、分发日志，可以提升日志的响应速度和整体的 IO 吞吐量，进一步提升写性能。另外 Primary 实例与图右的 Standby 实例可以通过各自的 Log Store 来建立数据复制链路，这样数据就扩展出来一个只读节点，从而可以读扩展，而且是跨 Region 读。另外我们通过这种方式实现了跨 Region 容灾，这对很多金融业务来讲是刚需。第二个演进是计算下推。我们的存储实际上拥有一定的计算能力，所谓下推就是利用它的计算能力
189、。例如读下推（页面内计算下推），不用将索引的叶子节点读入 Buffer Pool，而是直接将下推条件发给存储，返回符合条件的 Record。又如读下推（undo 页面间的计算），对于数据的历史版本扫描下推到存储层完成，内存不读取页面，仅获取最终结果。还有写下推，特定页面的修改直接在存储层进行。92腾讯云技术实践精选集 2022总结腾讯云原生数据库 TDSQL-C 继承了传统架构下的云数据库 1.0 的优势和竞争力。我们面向云上用户场景分析其业务特性，持续提升产品的可用性、可靠性、可扩展性和性能，进一步提升了 TDSQL-C 产品的竞争力。未来我们还会继续面向客户需求，跟进新硬件的发展，再去探索
190、表现更好的新型架构。扫码获取完整版演讲 PPT93腾讯云技术实践精选集 2022金融级分布式数据库 TDSQL 升级版引擎架构和关键技术介绍韩硕腾讯云数据库高级工程师北京大学博士，研究方向包括分布式数据库、图数据库、存储引擎优化等，在 SIGMOD 等数据库领域顶级会议上发表多篇论文。2019 年博士毕业后加入腾讯计费，主要负责 TDSQL 存储相关的研发。TDSQL 是腾讯云发布的一款全新自研的分布式数据库产品，具有完全兼容 MySQL、分布式事务全局一致性、弹性扩缩容、智能调度管控、在线表结构变更等关键特性。金融级分布式数据库 TDSQL 升级版引擎聚焦于适配金融级敏态业务，在频繁进行模式
191、变更，数据流量陡增等敏态场景下，实现弹性伸缩变更对业务透明无感知。ArchSummit 2022 北京站上，腾讯云数据库高级工程师韩硕带来分享金融级分布式数据库 TDSQL 升级版引擎架构和关键技术介绍，介绍 TDSQL 升级版引擎的架构设计，以及弹性伸缩特性的实现原理。TDSQL 升级版引擎架构TDSQL 是腾讯自研的，面向企业金融级应用场景的分布式数据库产品，它最早诞生于腾讯百亿级账户规模的金融平台。目前，TDSQL 产品已经在金融、政务、电商、社交等客户得到广泛应用，奠定了金融级高可用、强一致、高性能的产品特性和口碑。全国前 20 的银行里有将近半数都在使用 TDSQL，有力推动了国产数
192、94腾讯云技术实践精选集 2022据库的技术创新与发展。随着我们业务场景的不断增长和复杂化，业务形态、业务量会超过预期地增长，业务的敏态发展对于我们数据库的底层技术也提出了具有敏态能力的要求。我们已经投产的 TDSQL 版本应对这些业务的敏态变更时，有以下痛点需要改善：兼容性：建表需要手动指定 ShardKey。运维：存储层扩容需要 DBA 发起，部分事务会中断。模式变更：Online DDL 依赖 Pt 等工具。去年腾讯云发布了 TDSQL 升级版引擎架构，针对我们不断变化的敏态业务和以前的痛点做了改善。新架构实现了模式变更，可以大幅度提高数据吞吐量，有效应对业务变化，还具有数据形态的自动感
193、知特点，使得数据能够根据业务的负载情况进行动态迁移，降低分布式事务的比例，从而获得比较好的扩展性能。上图是升级版的架构图，分为计算层、元数据管理层和分布式存储层。升级版引擎技术亮点可以总结为四部分：MySQL 兼容、分布式、低成本，非常适合大规模业务量的业务。高可扩展性，计算/存储资源弹性扩缩容。95腾讯云技术实践精选集 2022 事务模型具有全局读一致性，围绕管理层 TDMetaCluster 统一分配全局唯一递增事务时间戳，来做数据的一致性判断。计算节点是在线模式变更，目前已支持在线操作、索引操作。升级版有三大模块，首先是计算模块 SQLEngine，内核完全兼容 MySQL8.0。计算层
194、为多主架构，每个 SQLEngine 节点均可读写，SQLEngine 之间通过一定方式刷新表结构变更等信息。新版改造为无状态化设计，移除各种有状态化数据，多线程替换为协程框架。交互层 SQLEngine 从 MC 获取全局事务时间戳和路由信息，然后返回。存储模块 TDstore。架构是基于 LSM-Tree 和 Multi-Raft 的分布式 KV 存储引擎。数据方面，Region 是基于 Raft 同步的多副本存储管理单元，数据根据 Key 范围分布在不同 Region 上；Region TDMC 调度下可发生分裂、合并、迁移、切主等操作；交互层面：TDStore 接收来自 SQLEngi
195、ne 的事务请求，充当分布式事务的协调者角色，处理后返回结果；每个 Region 的主副本负责接收和处理读写请求；管控模块 TDMetaCluster。主要工作是高效生成和下发全局唯一的事务时间戳，管理模块的元数据（比如 TDStore 和 SQLEngine 元数据），管理 Region 数据路由信息，以 Region 为基本单位进行负载均衡和存储的均衡调度。负载均衡调度要考虑负载热点，管控模块会把热点 Region 打散到不同的存储节点上，也需要兼顾性能影响，还要对 Region 进程做一些合理的划分。对于两阶段提交的模型，我们会把进程通过合理的 Region 调度和划分，把两个阶段的事务
196、变成一阶段的事务，从而提升效率。关键技术介绍分布式事务TDSQL 升级版分布式事务模型遵从了分布式事务的原则性。对于涉及到多个 Region 的事务，所有的参与者要么提交成功，要么全部回滚，通过两阶段提交模型杜绝半提交事务情况的发生。与经典的 percolator 模型相比，我们把协调者下沉到了存储层 TDStore，选取其中一个作为协调者。我们会把未提交事务的缓存到 TDStore，下沉之后做一个落盘。因为我们的存储层会有过期版本的清理，并且我们作为时间戳的分界点早于全局时间戳，所以只需要保留一个最新的版本，不再依赖于额外的垃圾回收机制。96腾讯云技术实践精选集 2022上图是简单分布式事务
197、的执行过程。无感知扩缩容这是我们非常重要的特性。我们扩缩容的过程中对业务是透明和无感知的，也就是说扩容期间，对业务的请求能够做到观察不到性能抖动的现象。下面以扩容场景为例，展示我们是如何做到水平扩展和负载均衡的。首先水平扩容涉及到 Region 的调度：分裂、迁移、切主。分裂时，我们的管控模块发现某个 Region 的设计规模超过了 Region 的阈值，MC 就会下发一个分类任务。分裂过程中也遵循了两阶段提交的原则，但是以 MC 作为协调者，Region 一主两备的副本作为参与者，来保证全员成功或者全员失败，避免分裂过程中不一致的现象。分裂结束之后，我们会发现分裂只能让 Region 数量增
198、加，但是数据本身的分母不变，只是每个 Region 所管理的数据规模变得更均匀了，但是要想真正达到水平扩展的效果，还需要迁移。迁移是由 MC 下发，迁移的流程是通过 Raft 协议增减副本完成的。迁移过程中，除了原数据要迁移过去，数据本身也会迁移。增加了一个副本后接下来要移除一个老副本，Region 置换数据的迁移是通过 Raft 协议中的流程来实现的。迁移完之后会发现，Region 在几个 TDStore 之间变得更加均匀。但这不意味着 TDStore 之间的读写负载也是均衡的，所以下一个操作是切主，让不同的 TDStore 副本之间达到负载均衡。比如说我们通过 Raft 的操作，把 Lea
199、der 尽量分配均匀。97腾讯云技术实践精选集 2022以上几点操作是无感知，对事务没有影响的，所有过程中是不插事务的。2PC 阶段提交由新主继续推进；未进入 2PC 阶段的事务，切主前需要将事务数据传输到新主上，从而保证事务执行的生命周期会跨过切主的流程，分裂也是类似的。迁移是通过 Raft 增减副本的方式执行的，就是增加了一个 Follower 节点，它与提供服务的 Leader 节点并没有直接联系。Raft 副本的机制保证了迁移过程中对事务没有影响。分裂和切主不可能存在并发，我们希望事务的生命周期必须要跨过分裂和切主的操作，这在工程实践来讲是个挑战。以分裂为例，刚开始只有一个 Regio
200、n1，上面有个事务 T，写入了两条，A 等于 1，H 等于 5，反映到 Region1 上。Region 的区间是 A 到 Z，分解成 Region1 和 Region2，Region 中的部分数据需要分到 Region2 上，这时候会做数据的切分，把事务缓冲中的信息做切分和传输。如果这个事务想读 H，H 跑到 Region2 上去了，在分裂之前可以从 Region1 读，在分裂执行的一霎那之后，就可以到 Region2 读，把活跃事务的私有数据迁移过来。另一个方面来讲，我们在 Region1 除了把事务分裂搬迁出去，另外涉及到两阶段提交。单节点的 1PC 的事务变成了 2PC 的事务，这时候
201、我们就要保证事务参与列表能够实时更新，从而在事务的提交阶段能够保证98腾讯云技术实践精选集 2022数据项顺利落盘。在两阶段提交阶段我们也会做一个检测，会检测 Region 列表是不是包含了分裂过程中新增的 Region，如果不包含会返回上层，但不会造成事务的回滚。协调者会更新协调者列表，本地保存的 Region List 更新一下，发现所有的数据都可以提交成功。这个例子可以说明基本的逻辑。数据存储与迁移上图展示了 TDStore 数据的持久化流程，分为两部分，一部分是 Raft 信息，另一部分是数据，分别存放在 Raft Log DB 和 Data DB。事务写入的数据首先会以 Raft L
202、og 的形式同步到 Region 的副本上，当 Raft Log 形成了多数派后，这时候会认为这个 Raft Log 就提交成功了。成功后，主备都会做 Raft Log 回放，会把其中事务相关的信息回放到内存结构WriteBatch 中，写入到 MemTable 的事务中。如果收到回滚请求，就直接把 WriteBatch 中的暂存信息丢弃。对于已提交事务的信息，MemTable 会不断增长，写到阈值之后就会转成不可变的 MemTable，然后做落盘操作，也就是 Flush。数据是以 SST 文件组织的。我们通过 Compaction 做过期数据的清理和数据压缩。这涉及到数据的清理，无论是 Ra
203、ft Log DB 还是 Data DB，都要做清理，我们会以快照的形式进行清理，保存具体的数据。更老的数据根据全局一致性原则肯定不会读到，所以可以及时清理。99腾讯云技术实践精选集 2022上图展示了数据迁移 Install Snapshot 的流程。对于 Raft 协议会发送一条请求，接受到这个请求之后就会开启一个流程，首先向 Leader 或者其他副本请求数据，要在 SST 中捞取对应的 Data，相当于是实时生成的。源端就会以 Region 区间为单位，与这个 Region 重叠的 SST 生成一个迭代器，把迭代器做合并，把数据按照新老版本合并，边合并边传输，传到目的端。传输过程中只会
204、把你所需要的数据版本存过来。传过来之后不能直接往里 LSM-tree 中写，而是形成外部的 External SSTs 文件，写满阈值会生成一个或多个外部 SST，然后插入到 LSM-tree 中一个合适的位置。数据传过来放到合适的位置之后，也不能影响新旧版本数据的一致性或者正确性的原则。100腾讯云技术实践精选集 2022扫码获取完整版演讲 PPT总结与未来规划我们希望用户能够像使用单机数据库一样使用我们的分布式数据库，同时又会具备无限扩展性。未来我们会有三个比较重大的特性升级：一是数据位置感知，允许运维人员具体根据不同的分析表做具体的 Region 分布的数据对齐和感知，这个特性可以让更多
205、分布式降低到事务，从而大范围提升性能；二是对等架构，使得在线上的小规模集群环境下，资源利用率能够得到进一步提升；三是管控这边会做粒度更细、更智能的负载均衡和调度策略，使得扩缩容、变更的性能曲线更平滑。101腾讯云技术实践精选集 2022国内行业 IT 系统中，数据库领域长期被国外产品垄断，国内云计算厂商基于云计算带来的架构升级，以及产业互联网数字化实践，引领了新一代分布式云数据库技术与实践突破。从金融级场景到传统金融核心系统场景，在云化的技术浪潮下，国产分布式数据库得以在对数据库最高要求的金融行业实现应用，并逐步拓展至政务、运营商、工业制造等，逐步支撑国民经济对数据库的国产化与数字化转型升级需
206、求。腾讯云数据库 TDSQL 正是走过了这样的历程，在技术突破，到支持客户转型实践过程中，积累了丰富的解决方案与实践经验。在 DIVE 2022 全球基础软件创新大会（北京站）上，腾讯云数据库资深解决方案架构师贾瓅园带来了国产金融级分布式数据库在金融核心场景的探索实践的主题分享。国产金融级分布式数据库在金融核心场景的探索实践贾瓅园 腾讯云/数据库资深解决方案架构师15 年金融银行 IT 工作经验，先后经历和主导国内多家银行核心系统架构设计与建设，长期从事核心业务系统、分布式技术架构、云原生、信创相关技术工作，现为腾讯云数据库团队行业架构专家，从事金融领域数据库赋能、行业架构设计相关工作。102
207、腾讯云技术实践精选集 2022回归本源，是什么驱动力促进金融核心场景分布式数据库发展？一方面是国家机构、监管机构给出的政策及指引，2021 年末，中国人民银行基于“十四五”规划发布了金融科技的发展规划，2022 年初银保监会发布了银行业、保险业的数字化转型指导意见，个人总结为三个词：安全、发展、创新。第二方面是金融业务的发展对于技术架构的要求，银行业务与需求发展背景下，技术要求、技术多样性、功能细化性、架构复杂度、管理等维度的要求也逐级提高。第三方面，金融业系统技术与架构的趋势之下所衍生的数据库要求、自主可控的软硬件要求等。我们当下处在分布式数据库的快速发展过程当中，既要契合金融场景专业特性，
208、技术上也要适配外部环境与生态以及通用性，面临着从技术角度、从公司实力角度、从数据库研发角度的多维度挑战。分布式数据库在金融领域的挑战与痛点金融架构里面的挑战维度有哪些？第一是设计、规划、解决方案能力，相对于新事物，需要行业多方面的接受过程，这个时期国产分布式数据库不能像传统数据库，而是需要更贴合于业务场景和行业特性并抽象和分析使用特点，衍生变化为数据库通用特性和功能，更方便地让金融客户以及开发厂商使用。第二方面是扩展能力，包括横向和纵向的扩展能力。第三方面是稳定性和性能，围绕这个维度又衍生了广播表、单表、事务等功能与解决方案。103腾讯云技术实践精选集 2022第四方面是高可用性，满足监管要求
209、和行业特点，支持多中心多活、故障切换等方式。第五方面是软硬件兼容性要求，我们正在使用的领域有自主可控软硬件、虚拟化、云化等基础底座。分布式数据库在金融业务领域又面临哪些难点呢？第一是保证业务系统兼容性，降低改造和引发的风险，比如关键字、函数、语法，甚至常规业务系统使用的软件驱动。第二是迁移同步的方案与功能，这个往往在金融场景下容易被忽略掉，需要考虑异构迁移工具、方案，考虑如何处理业务场景数据同步、高可用要求下的数据同步。第三是运维体系，分布式体系下特性带来的管控维度较多，因此可视化、智能化的管理平台和工具尤为重要，同时也要覆盖黑屏命令工具、监控工具等，匹配 DBA 使用习惯。第四是服务与交付，
210、分布式数据库还处在一个发展和高速迭代过程中，那么如何来契合金融场景设计特点与复杂度，都对人员能力、交付提供了更新的要求，当下走的路线应该既与金融行业系统开发厂商不同，又与传统数据库厂商不同。第五是生态建设，这涉及到共享知识库如何建立、检索、查阅，社区如何运营、认证培训如何开展更有助于生态合作。总结来说，分布式数据金融领域落地不仅仅是技术与产品力的考验，也是考验着金融场景理解能力、金融运转体系理解能力与设计能力等。金融级架构探索、思考与实践架构体系如何支撑金融核心业务发展和合规?我们一直在探索和积累，来支撑金融级分布式的架构体系，以满足监管合规的要求，完整的实现自主可控，并契合金融核心的特点。我
211、们满足了金融级的“四高两低”的要求，包括未来都是以此为原则基础。并且实现了多内核。为什么要多内核？在金融银行业中，不同的金融业务场景，不同的分布式业务架构需求，以及每家银行的建设因素不同、104腾讯云技术实践精选集 2022系统历史遗留问题原因不同、系统的 AP/TP 属性等综合多方面和实践经验，因此必须要有多内核的兼容性来保障新旧数据库转换能力，保证业务系统能够平滑下移。另外，贴近开发，解决“开发不规范，调优困难”的问题。契合金融业运维模式，解决“诊断难、维护难、时效长”的问题。同时也要考虑不单一绑定某一技术形态，采用兼容通用协议的技术形态，降低从业者的学习难度。业务系统兼容性探索在做业务系
212、统兼容性探索时，要注意系统背景、特点、场景的不同，不能“通吃”，应按不同类型、不同纬度进行兼容适配，并考虑系统业务与当前的架构现状。例如：我们按照金融银行业系统传统分类标准做了梳理和归纳，它们都有各自的特点以及兼容思路和技术诉求。在语法与开发兼容性方面，我们通常关注：数据结构梳理:访问频度、数据量、关联关系、分片依据、水平垂直分库设计规则 基础数据类型:字段数据类型归纳，不兼容类型采用工具化配置转换 对象使用:存储过程、视图、非标准函数使用分析，与业务系统配合调整 SQL 执行对象:索引、函数、锁、大查询、大事务分析与调整 数据库基础集成层面:会话保持、链接池参数、探活机制、驱动设置105腾讯
213、云技术实践精选集 2022数据迁移与同步的兼容和实践业务场景数据迁移与异构数据库迁移项结合，数据库须具备异构库数据迁移能力，不同的数据迁移同步场景有着各自的关注点：异构业务系统迁移场景：业务逻辑复杂、数据业务关联度高 适用定制化的业务数据迁移程序与方案并配合数据库工具，进行数据迁移异构对抽迁移场景：业务逻辑关联少，数据量大,增量/全量数据迁移 适用数据库提供异构库迁移工具进行数据的迁移 业务迁移与异构库结合场景：兼具两种场景特点 采用组合迁移方案，满足异构业务系统+异构数据库数据迁移 在贴源数据同步实践中，各场景的关注点如下：106腾讯云技术实践精选集 2022运维架构探索与实践从运维角度来看
214、，架构特性从最早的字符界面端到图形化、智能化运维发展迭代，字符界面操作上手速度快，但具有高度依赖人工、管理流程复杂、成本高、容错低、风险高等特点。图形化运维实现了工具化，降低了容错风险和管理成本，而智能化运维更进一步实现了风险预警、主动探测和提前预知，让运维从被动变主动。探索实践新的实施与服务模式大多数的开发人员、技术人员都具备一定程度的传统数据库的知识、开发经验和体系，基于系统的成熟稳定，技术的共识性实施角度不存在什么太多的问题。因此传统成熟的数据库厂商在经历了众多行业的积累后不断打磨，已走出了一条成熟的实施道路，即关键节点保障型。面向客户时技术团队基本上是以 DBA/架构师1v1，或 1v
215、 多的模式，不需要完整周期跟进实施全流程。107腾讯云技术实践精选集 2022生态建设高校、合作机构、金融 IT 同业、金融客户等，对当前分布式数据库都有一定的深入了解，但认知程度暂时达不到传统数据库所积累的程度，因此需要我们在数据库层面不停深入建设共享知识体系，包含社区、生态合作、培训等体系。一、这个生态里面不只我们自己，包括分布式数据库领域的众多厂商、金融IT开发厂商，实践方案、调优指南、使用指南、技巧经验、系统兼容经验、金融系统运维等丰富到整个金融实践体系中。金融软件的开发厂商聚焦业务系统，这类型厂商为什么走的是需求差异化的路线，原因是业务通用性的同时每家银行的需求不同，业务复杂度不同，
216、涉及每家银行技术架构、厂商特点也不同，导致了整体相关的工作，都需要在银行整体组织下进行大规模的完整周期实施和调整。所以团队有技术架构、DBA、业务专家、项目管理以及开发，基本上团队是一个 1v1 的模式，全周期保证。基于我们多年的研发、实施经验来讲，当下兼容和融合以上两种相对比较好，既保障了数据库的交付与落地，同时兼顾成本和投入，以及经验回归和产品打磨。具体的方法论而言，总结大致为：第一，帮助金融行业的客户将数据库融入到行业架构规划中，既然能够协助更好地理解知识体系，也能够为金融客户未来的数据库使用奠定基础。第二，跟进常规的 IT 系统建设，总结系统使用数据库的特点特性。第三，在设计交付之初，
217、我们就考虑到兼容对应的业务性特点来进行分片、运营模式、数据吞吐量设计、数据节点等统筹安排。第四，有别于传统的数据库厂商，我们配备了行业架构师、数据库架构师以及 DBA 等角色来共同完成项目。这样兼顾了数据库以往的交付与服务模式，同时也兼顾了行业的特点，也包含成本管控以及诉求。108腾讯云技术实践精选集 2022二、增强社区广度和深度，聚集于碎片化问题解决、学习笔记、金融场景特点优化，开办技术论坛，让众多的行业以及未来有潜力从事这个行业的人才能够加入到其中。三、深入生态合作，与学术研究机构、信创基础软硬件厂商、金融软件同业、金融客户合作，推进一些相关的标准甚至研发体系，进行产能体系的升级。四、认
218、证培训添加，联合第三方进行金融客户服务中知识转移、技术认证模式，通过认证培训普及常规知识，为未来金融 IT 领域人才储备夯实基础。建设模式探索与实践聚焦到建设模式共分为两类，一是关键系统/模块下移模式，二是业务系统升级/建设模式。关键系统/模块下移模式实际是把整体分了 N 个阶段来做，并不是一次完成。这种模式具有很多优点，包括低成本、风险比较低，并且是循序渐进的。但对于系统的规划、建设周期布局以及管控能力要求较高。分布式数据库要满足“四高两低”的要求，即高可用、高一致性、高扩展、高性能、低成本、低风险。从产品109腾讯云技术实践精选集 2022选型到适配业务，原则上必须要保证数据库兼容业务系统
219、，相对来说业务结构要清晰，数据结构容易梳理、系统维护技术能力要强。在基础适配压测阶段，重点是语义语法、业务使用场景和问题的筛选。在业务系统适配验证阶段，重点是联机业务，批量业务，供数、同步类业务，验证“四高两低”。业务系统升级/建设模式其实相对来说容易一些。因为系统升级自然面临新系统的变化改造，通过开发设计过程，匹配数据库特性，没有历史包袱。此类模式对于管控能力的要求相对会低。总体而言，从投入成本、核心能力、服务能力来讲，对厂商、银行也会有一定挑战。这些挑战主要集中在升级与适配、系统的架构设计、UAT 测试与基础底座验证、工具化与数据移植、切换投产演练等方面。未来挑战与探索思考将来，我们认为金
220、融领域分布数据库仍然需要不断地面对挑战和打磨。110腾讯云技术实践精选集 2022第一个是分布式事务的业务场景，当下我们能够保证分布式数据库的事务处理能力，能保证全金融业务场景，但我们也在不断地努力，探索将来按照分类去做一些实践研发工作，探索如何通过数据库解决事务场景，降低应用的复杂度。第二是随着外部环境的发展，数据库不断提升兼容生态能力。第三是全打包的金融级解决方案，符合金融级监管要求的同时，满足客户的个性化特点，最终走向多对一的、统一的数据库产品。未来数据库时代，云原生数据库发展也在不断进行当中。云时代的特点是 IT 设施从零散走向集中化、规模化，交付方式从软件交付走向服务标准交付，开发方
221、式从底层(laaS+PaaS)走向上层(SaaS)，数据形式及应用场景从单一化走向多样化。在这样的云时代的背景下，数据库将来要做到单一引擎极致化、多引擎统一智能管控融合、以及 DBaaS 形态在行业应用的探索。扫码获取完整版演讲 PPT111腾讯云技术实践精选集 2022腾讯云 MongoDB 智能诊断及性能优化实践杨亚洲腾讯云数据库专家工程师当前就职于腾讯 NoSQL 团队，多年软件研发经验，致力于高性能中间件、数据库研发。腾讯云 MongoDB 当前已服务于各行业头部用户，致力于为用户提供高性能、低成本、高可用的存储服务。在 DIVE 2022 全球基础软件创新大会（北京站）上，来自腾讯云
222、的数据库专家工程师杨亚洲带来了主题为 腾讯云 MongoDB 智能诊断及性能优化实践的演讲。为大家分享了 DBbrain for MongoDB 智能诊断、数据库自治等功能实现，包括异常诊断、智能索引推荐、SQL 限流等核心功能实现。此外，结合真实典型案例，给大家分享千亿级高并发 MongoDB 集群踩坑及性能优化实践。MongoDB 核心优势分布式MongoDB 是开源的分布式数据库，可以解决传统数据库在性能和存储容量上的瓶颈问题，得益于此，用户不必再提前考虑分库分表等操作。同时 MongoDB 也是一个天然高可用的数据库，比如说在一主两从的工作模式下，当主节点意外宕机，从节点就会接替主节点
223、的工作，整个过程无须依赖任何第三方组件。112腾讯云技术实践精选集 2022schema-freeMongoDB 的表结构相对自由，添加字段方便快捷，相比于传统数据库在一张大表里添加字段，运维成本大大降低。高性能MongoDB 早期使用 MMAPv1 存储引擎，后来替换为 WiredTiger 存储引擎，它支持行级粒度锁、热点数据缓存等特性，这给 MongoDB 带来了高性能、低延迟、高吞吐等能力。高压缩比在默认配置下，MongoDB 使用 snappy 压缩算法，可达到平均 2 到 4 倍的文本数据压缩能力，如果使用 Zlib 压缩算法则可以提升到 3 至 7 倍，但是对性能影响较大，因此线
224、上通常使用默认配置即可。经测试，在默认配置的情况下，同样一份数据写入 MongoDB、MySQL、ES 的真实磁盘消耗比约为 1:3:6。完善的客户端访问策略MongoDB 支持五种均衡访问策略：Primary：读主节点，当主节点异常时，可能造成短期内的业务异常。PrimaryPreferred：主节点优先，当主节点异常时可以读从节点。Secondary：读从节点，把流量平均分配给多个从节点，实现负载均衡。SecondaryPreferred：从节点优先，如果从节点异常，则读取主节点。Nearest：就近访问，在多机房场景下，就近访问可以避免出现跨机房访问的情况。113腾讯云技术实践精选集 2
225、022腾讯云 MongoDB 的核心优势腾讯云 MongoDB 可有效减少运维成本，通过 DBbrain 提供一站式监控的诊断分析，并且能给出相应的优化建议，同时也集成了官方的常用工具，让用户使用更方便。腾讯云 MongoDB 在内核里做了一些定制化的开发，比如解决表数量达到百万级别时的性能问题、提供 SQL 限流功能减少流量过大导致的集群不可用问题。安全方面，腾讯云 MongoDB 可以将数据恢复到 7 天内的任意时间点，并且提供 24 小时的专业支持服务。除此之外，也天然集成了云上高可用、高性能等通用能力。DBbrain for MongoDB 介绍DBbrain for MongoDB
226、是腾讯云开发的数据库智能管家，是为用户提供数据库性能、安全、管理等功能的数据库自治云服务，它不仅支持 MongoDB 数据库，同时也接入了 MySQL 等其它数据库。DBbrain for MongoDB 拥有的核心能力如下：丰富的监控指标：除了最初控制台暴露给用户的主要监控指标以外，所有实例维度和节点维度的核心指标同时也被暴露到 DBbrain 上。丰富的工具集成：一键集成 MongoDB 常用分析工具，如 Mongostate、Mongotop 等。如果需要查看某个实例或者某个节点的流量、库表分布等信息，直接在控制台界面点击就可以实时输出，无需额外通过客户端登录查看。114腾讯云技术实践精
227、选集 2022 实时异常事件诊断与优化建议：很多异常事件可以被 DBbrain 提前发现，并且给出一系列优化建议，除了常规的异常诊断，还包括一些特殊的异常诊断项。实时 Kill 会话：有些查询没有使用到索引，有时需要手动 Kill 这些会话，现在这些操作可以直接在 DBbrain 上完成，甚至可以设置一些定时任务来周期性的执行，这样开发或运维人员就不需要自己编写脚本来进行操作。库表分析：对数据库和表进行详细分析。慢日志分类汇总：将慢日志进行分类汇总，更清晰直观的展示给用户。健康报告：每日生成健康报告，数据库状况一目了然。索引推荐：很多用户自己并不清楚如何创建索引，这时就可以采用 DBbrain
228、 推荐的最优索引。SQL 限流：在大流量、不同业务使用同一数据库等情况下，可以使用 SQL 限流来保障核心业务的可用性。MongoDB 异常诊断异常诊断当前已经覆盖了 MongoDB 常见的核心指标，实时对云上所有实例进行异常分析，发现异常后会第一时间触发诊断告警并提出优化建议。通常把异常诊断项分成两种，一种是基础诊断，比如内存、CPU、磁盘、连接数，慢查询、节点连通性、主从延迟、Oplog 保存时间等，这些是最常用的数据库诊断指标，还有一些高级的指标，比如 Session 会话数（Session 会话数较高的时候，可能会引起集群抖动）、读写活跃队列、前台加索引、读写等待队列、死锁检查（例如索
229、引还没加完，又去删除索引就会造成死锁）、全表扫描，还有纯粹的引擎相关的一些参数，如引擎 Cache 使用百分比、引擎脏数据百分比等。腾讯云 MongoDB 团队后续规划把 MongoDB 的诊断数据，也就是经常在数据库里面看到的 diaglog 数据进行处理，用来分析内核的一些深层次问题。MongoDB 智能索引推荐实现智能索引推荐主要是基于索引规则和代价估算来实现的，整体的架构如下：115腾讯云技术实践精选集 2022智能索引推荐分为四个模块：Agent 模块 Kafka 模块 日志分类模块 代价估算模块系统整体的工作流程是：每个 MongoDB 节点上布署一个 Agent 节点，它会实时采
230、集所有有用的日志并存储到 Kafka 里，日志分类处理模块会从 Kafka 里把需要的日志提取出来进行分类，然后把分类好的日志交给索引代价计算模块进行计算，最终得到最优索引。Agent 模块和 Kafka 模块的逻辑相对简单，这里重点介绍日志分类模块和代价估算模块。116腾讯云技术实践精选集 2022日志预处理分类第一步：提取有效的慢日志并不是所有的慢查询日志都需要处理，由索引问题导致的慢查询，诸如索引不对或者索引不优引起的问题就需要提取，由于没加索引造成的全表扫描，这类日志也应该提取。如果加了索引，如何判断添加的索引是不是最优？答案是对比索引数据扫描的行数与实际数据的行数，如果差值较大，就判
231、断这个索引不是最优的，需要进一步优化。第二步：根据 filter 对 SQL 分类同一个库表中会有很多查询，查询条件不尽相同，属于同一类的 SQL 需要满足几个条件，即库、表、命令、查询条件完全相同，前三个条件容易区分，比如同库同表情况下，Find 操作算一类，Update 操作算一类，而查询条件相同的前提是查询关键字要相同且操作符属于同一类。日志聚合处理定期从 DB 中获取分类好的 SQL 信息交给代价估算模块进行处理。索引代价计算模块处理流程抽象语法树生成及分解：从日志分类处理模块中获取对应 SQL，抽象语法树，同时进行分解。根据索引规则生成候选索引：根据最优候选索引规则生成侯选索引的流程
232、，可以参考腾讯云数据库公众号发布的文章：云上 MongoDB 常见索引问题及候选索引规则大全一文。对候选索引进行代价估算：从源集群随机抽样数据，对候选索引进行代价估算，得出最优索引。AST 裁剪及候选索引生成，详见下图：117腾讯云技术实践精选集 2022假设有一个查询，查找位于四川成都，年龄在 20 到 30 岁，身高大于 1 米 7 的人，或者位于四川成都并且在腾讯工作的人，这个查询如何推荐最优索引？第一步要生成抽象语法树，可借助 MongoDB 内核的 Explain 来实现，可以看到生成的抽象语法树中涉及了 OR 操作，需要进行拆解并把 OR 操作“去掉”，将原 AST 分解成 2 个
233、子树，可以看到拆解后的两个子树中已经没有 OR 操作了，然后分别获取子树 1 和子树 2 的候选索引，生成整个 OR 类查询的候选索引。可以看到子树 1 包含三个查询，省、市、工作地点，都是等值查询，所以可以把三个字段随机组合在一起成为一个候选索引即可，因为等值查询无论怎样组合，代价都是一样的，通常在等值查询的情况下有一个不成文的规定，即把区分度最高的字段放到最左边，什么是区分度？假设一个字段的取值有 100 种，区分度可以理解成就是 100。假设 Work 的区分度大于 City，City 的区分度又大于 Provice，把区分度最高的字段放在最左边，子树 1 的候选索引就可以求得了。再看一
234、下子树 2 的候选索引可以发现，省份和城市都是等值的，但是年龄和身高是非等值的，所以需要根据等值和非等值组合索引规则，通过查询前面提到的候选索引规则表，可以知道子树 2 的候选索引需要先把等值字段组合在一起，然后再加上一个非等值字段，因为有两个非等值字段，所以等值字段加第一个非等值字段构成第一个候选索引，第二个等值字段再加第二个非等值字段，就构成了第二个候选索引，所以子树 1 就有一个候选索引，子树 2 就有两个候选索引，因为子树 1 和子树 2 是 OR 的关系，所以整个 OR 查询的候选索引就是把子树 1 的候选索引和子树 2 的第一个候选索引组成一个候选索引，再把子树 1 的候选索118
235、腾讯云技术实践精选集 2022引和子树 2 的第二个候选索引组成一个候选索引，最终整个 OR 查询就有两个候选索引。至此就得出了整个 OR 类查询，这是通用于绝大部分场景的候选索引生成过程。腾讯云上有些用户的数据分布比较特殊，所以腾讯云 MongoDB 后续还会增加几种候选索引，主要用于应对一些特殊的场景，对于一般用户来讲，通常只要满足上述候选索引规则，再总结出来，就能够满足绝大部分场景的候选索引需求。候选索引代价计算现在就有两个候选索引可供选择，那么哪个是最优的？这就需要进行代价计算，举例说明，对于一个 OR 类查询，上面得出的两个索引对应的执行计划流程是：首先第一个索引进入 index s
236、can stage，然后进入 OR stage，OR stage 执行完成后就会开始做 Fetch 操作，最后就会得出整个流程扫描了多少行数据、得到了多少行数据，以及整个流程的执行时间，第二个索引也需要执行同样的流程，代价估算就根据这三个值进行对比，最终选择执行时间少，扫描行数少的候选索引，这就是代价计算的主要流程。腾讯云的代价估算是由一个旁路模块实现的，实现难度较大，需要对整个内核执行计划有透彻的理解，所以对于自研用户，建议在采样数据过后，写入一个新的 MongoDB 集群，然后让执行计划执行候选索引，得出执行这个索引扫描了多少行、执行多少行、执行了多长时间，最终也可以得到最优索引。云上因为
237、要保证用119腾讯云技术实践精选集 2022户的信息安全，所以一般直接抽样到内存里并进行计算，而不是抽样到一个新的实例上，但实际这两种方式原理是一样的。智能索引推荐当前已经服务化，逐步会开放给用户使用，如果大家有兴趣可以去体验。索引推荐基本上能在半小时内发现实例上存在的索引问题，除了推荐最优索引外，还可以把实例上的无用索引和重复索引也找出来，这样能用最少的索引满足用户需求，性能等方面也会更好。MongoDB 内核 SQL 限流实现另外一个要分享的是 SQL 限流。为什么要做 SQL 限流呢？当流量过大、负载过高，数据库抖动可能造成雪崩时，就可以限制一下流量，保证一些请求能正常返回。另一方面，有
238、些用户为了节约成本，将多个用户的数据写到了同一个实例上，某一时刻可能出现用户编写的接口不对或其它异常情况，导致流量非常高，就会影响这个实例上的其他核心业务，这时就可以通过限流把异常的和不太重要的表做限流，保证核心的业务流量能正常访问，还有一些突发扫表，高危扫表操作都可以通过限流进行限制。我们在内核哪个地方做了 SQL 限流功能呢？先捋一下 MongoDB 的整体架构，它是分层的，第一层是网络收发模块，网络收发过后，交由命令处理模块把这些 SQL 解析出来，然后这些 SQL 会进入查询引擎模块、读写模块以及并发控制模块。我们整个 SQL 限流模块是加在命令处理模块之后的，加在这里有什么好处呢？首
239、先到这里的时候，已经拿到了详细的 SQL，再者就是在并发控制之前做到 SQL 限流，避免 SQL 限流里120腾讯云技术实践精选集 2022面的操作会影响并发控制和数据库读写访问，防止与下层的并发控制模块产生冲突。内核 SQL 限流的整体流程是：首先在 DBbrain 界面上可以配置策略规则，比如 SQL 类型、并发数，可以配置定时关闭还是手动关闭，定时关闭是指最多执多少时间，手动关闭就是打开后永远执行，除非手动关闭。然后是搜索关键字，配置完规则，就可以对指定库、表或者指定的 SQL 语句做限流。整个流程是首先在 DBbrain 的控制台下发规则，以分片集群为例，就下发给分片集群的 Confi
240、g Server，Config Server 接收到后把这个规则写到 Config Server 的一个表里，分片集群的每个 mongod 定期从 Config Server 获取这些规则并加载到自己内存里，基本上几十秒就获取一次，所有的 mongod 节点内存里就会有完整的规则数据存在，当发起一个请求，通过客户端到代理，再到 Mongod 节点的时候，进行限流规则匹配，触发限流操作。为什么选择在 Mongod 上做限流？而不是在 Mongos 上？首先 Mongos 上面的流量控制是由客户端基于 IP 做哈希的，可能导致流量不均匀，其次线上有副本集的集群，也有分片的副本集群，在 Mongod
241、 上做可以实现代码统一，再者如果在 Mongos 上做的话，因为 Mongos 之间是无状态的，无法保证相互的控制达到一定的级别，还有一个原因是瓶颈一般都在 Mongod 节点上，所以就在 Mongod 上面做。121腾讯云技术实践精选集 2022关于 SQL 限流规则，一个是 SQL 类型，比如说增删改查，另外一个是限流时间，再者就是并发数，并发数可以限制某类请求同时访问我们 DB 的并发量，另外就是关键字，可以匹配库，也可以匹配表，甚至可以匹配详细的 SQL，这样就可以实现指定的库、表和某一类型的 SQL 限流。收到一个请求的处理流程是怎样的？一个请求到达 MongoDB 后，首先看这个实
242、例是否启用了 SQL 限流功能，如果已启用，则提取用户请求中的库、表和 SQL 关键字信息，下一步和配置的限流规则做匹配，判断这类 SQL 是否有可用的 Ticket,Ticket 代表并发控制中的并发数，如果没有可用的 Ticket，比如 Ticket 值为 0，说明当前已经有很多访问，就直接限制这个请求，返回客户端异常。如果有可用的 ticket，就把 Ticket 值减 1，同时访问 DB，访问到 DB 后就将数据返回给客户端，同时释放当前 ticket，后面的请求就可以继续复用，这就是整个限流工作流程。典型案例：千亿级高并发 MongoDB 踩坑及性能优化实践给大家举一个典型案例，我们
243、有一个千亿级的高并发 MongoDB 集群，维护过程中踩了一些坑，我们对它做了一些性能优化，在此给大家讲一下。122腾讯云技术实践精选集 2022这个集群存储了一个金融行业头部客户大概 1000 多亿条订单信息数据，整体采用私有云的解决方案，MongoDB 集群采用分片模式，由于需要长时间高并发读写，写入的数据需要马上可读，所以读写都在主节点完成。高峰期的读写流量可达几十万每秒，在极端情况下甚至能超过百万每秒。从上图可以看到仅一个分片的流量即可达到 16 万每秒。我们其中一个踩坑点是主从切换。业务上曾出现过几次主从切换，切换完成后，从节点变为新的主节点时，整个集群出现了几分钟到几十分钟的不可用
244、，而且这个时间是不固定的。还有一个踩坑点是集群经常会出现数十秒的抖动，产生慢查询。123腾讯云技术实践精选集 2022下面就具体看这几个问题，比如说主从切换，为什么会发生主从切换？主从切换只发生在主分片，因为主分片压力最大，流量较高，有十几万的写入，可以看到的现象是数据百分比正常，不到 20%，但内存使用率在持续增加，可以达到 95%，读写队列和流量也比较高，流量高是由 于用户运行批量任务造成的，批量任务会持续运行数个小时，产生大量的写入和更新。短期来看集群是正常的，但长时间的压力导致整体内存持续升高，产生大量排队现象，最终主节点不堪重负，保活检测超时，进行了主从切换。针对这个问题短期的解决方
245、案是让业务进行改造，在批量任务并发写入的时候减少并发量，拉长写入时间，控制在业务可以接受的范围内，但长时间的批处理作业依然会产生一定的积压现象，所以对于长期的优化方案来说，我们看到的物理现象是主分片压力很大，但是其它分片压力不大，集群的 Chunks 数又比较均衡，这说明集群中存在热点 Chunks，终极的优化方案是找出热点 Chunks，通过手动的方式把一部分热点 Chunks 迁移到其它分片。124腾讯云技术实践精选集 2022主从切换后存在一个非常严重的问题，集群会出现几分钟到几十分钟的不可用，这是不可接受的。通过日志进行分析可以看到，新的主节点会去获取路由的元数据（Chunks 信息等
246、），而获取 Chunks 信息的原理是：业务通过 Mongos 访问数据时，会带上最新的版本路由信息，当主节点接到请求后会将此信息与本地路由信息进行对比，如果发现路由信息不是最新的，则从 Config Server 获取路由增量信息并写入本地 Config 库的 Cache.chunks 表中，但这个操作的前提是 Oplog 需要同步到多数节点中，但此时主从延迟较高，导致 Oplog 同步缓慢，这就间接导致获取路由信息的操作也被卡住。当路由信息写表完成后，还需要从表中加载到内存，因为有 500 万个 Chunks 路由信息，所以加载过程很慢，大概需要 45 秒，这也造成了时间的消耗。优化方法是
247、让从节点定期从 Config 库的 Cache.chunks 表中把路由版本信息加载到内存，这样当从库切换为主库被业务访问时，就不会触发获取增量或全量路由信息的流程，新的主节点就可以快速变为可用状态。由于路由版本信息是定期加载的，极端情况下还有可能因为 chunks 数据不一致而触发重新获取 chunks 数据的操作，当出现这个问题时，可以及时把延迟高的节点从集群中踢掉来规避这个问题。125腾讯云技术实践精选集 2022FTDC 是 MongoDB 的内核诊断模块，通常会写数据到 MongoDB 数据目录的 Diagnose.data 目录中，这些数据会记录 MongoDB 内核各个流程的核心
248、诊断数据，比如时间消耗等信息，但它是加密的，导致只有原厂工程师才可以对其进行分析。腾讯云 MongoDB 团队结合 MongoDB 内核源码对 FTDC 生成的数据进行了反解析，包括全量的和增量的。有一些疑难问题通过日志是看不出来的，比如可以看到慢，但为什么慢不知道，这时候就需要解析诊断数据，举个例子，一个集群在低峰期的时候没有什么流量，却发生了主从切换并产生了大量慢查询，这明显是有问题的。日志里只能看出数据库慢，做了主从切换，但不知道原因。这时把诊断数据解析出来，可以分析出数据库内核模块每个流程的执行时间消耗，可以看到时间都消耗在 TCMalloc 这个模块上，用了 17 秒，这样就能明确问
249、题出现在 TCMalloc 模块，进一步分析，将 Diagnose.data 中的增量数据解析出来，可以看到 TCMalloc 在某个时间点一次性释放了几十个 G 的内存，一次性释放大量内存就会引起业务卡顿，解决方案是在平峰期实时的释放 TCMalloc 的内存，不要积压在一起统一释放。未来腾讯云 MongoDB 团队计划将 DBbrain 与 Diagnose.data 诊断数据结合，去分析深层次的内核疑难问题。126腾讯云技术实践精选集 2022腾讯云数据库云上 SaaS 生态演进潘怡飞腾讯云数据库高级工程师腾讯云数据库解决方案架构师，拥有多年的数据库服务应用优化实践经验。近年来，腾讯云数
250、据库产品在 SaaS 生态方向上积极探索与布局，在数据库服务平台化、自动化、智能化领域推出一系列优秀的 SaaS 产品和完善解决方案，助力互联网、金融、传统企业等客户架构升级，数字化转型，构建新一代的数据库服务平台。ArchSummit 2022 北京站上，腾讯云数据库高级工程师潘怡飞发表题为腾讯云数据库云上 SaaS 生态演进的演讲，介绍腾讯云 SaaS 产品矩阵、能力、生态和演进方向。腾讯云数据库 SaaS 生态矩阵腾讯云数据库 SaaS 生态分为基础能力 SaaS 化、易用性 SaaS 化、智能化运维和模块化 SaaS 产品四个方向。总体来说，SaaS 产品的生态演进是基于 PaaS 产
251、品的基础能力和衍生能力，提炼出更靠近业务属性的 SaaS 能力，帮助用户和客户更好更方便地使用数据库，创造业务价值。腾讯云 SaaS 生态矩阵的几个主要产品包括：127腾讯云技术实践精选集 2022 数据传输服务 DTS，定位为数据迁移与数据流打通的服务，包含在线迁移同步、低时延和高可靠的特性，主要包含迁移、同步和订阅模块。数据智能管家 DBbrain，是定位于自动化、智能化运维统一管理平台，从前期的数据库巡检、故障发现、故障定位到后期的故障解决与系统优化，形成一套数据库全生命周期管理运维的工具。数据库安全审计，是一个内核级别的安全审计平台。区别于一些需要旁路管控部署的方式，它对性能和收集完整
252、度都支持得比较好。同时它跟 DBbrain 联动，对收集到的审批日志进行汇总、分析，这样可以看到具体的问题根因，发展出在运维或者台账过程中也可以使用审计日志的能力。腾讯云图，是一个定位于定制化大屏 BI 展示的平台。它可以快速通过可视化的图标管理来降低建立专业大屏的门槛。它内置预设了多个行业模版，可以用自由拖拉拽的方式快速形成一套炫酷大屏，包括前端数据展示。腾讯云数据传输服务 DTS数据传输服务 DTS 包括以下几个部分：数据迁移功能面向单次的数据库迁移，支持多种网络链路，全量增量不停机迁移，最小化迁移过程中停机对业务造成的影响，全程自动化减少风险点，支持一致性校验能力。适用于一次性迁移数据库
253、迁移，数据库迁移上云或迁移下云场景。数据同步功能指两个数据源之间的数据长期实时同步，具有多种高级特性，库表重映射、DML/DDL 过滤，Where 条件过滤，双向同步，丰富冲突策略。适用于云上云下多活、异地多活、跨境数据同步、实时数据仓库场景。数据订阅是指实时按需获取数据库中关键业务的数据变化信息，将这些信息包装为消息对象推送到内置 Kafka 中，方便下游实时消费。适用于异构数据更新、业务异步解耦 缓存更新，ETL 实时同步等场景。128腾讯云技术实践精选集 2022上图是数据传输服务整体架构，主要有两个关键措施。第一个是基于原生解耦，采用统一的数据中间格式，导出和导入完全流程化。第二是插件
254、式设计，方便数据库快速接入，解决历史遗留问题。数据传输服务应用的场景有：云数据库迁移，提供灵活的上云下云场景支持，同时支持下云到自建 IDC，有数据正确性保证。双向数据同步，支持异地多活、异地灾备，支持双向、环形数据同步，解决了同步数据重复写冲突问题，具备高性能、低延迟。多到一数据同步，包括多源数据聚合、汇总分析场景。支持多到一数据汇总、同步，支持分表聚合、一拆多、跨云账号。异构数据同步，包括同源异构同步与非同源异构同步。数据传输服务中，数据订阅适用于很多没有固定下游的场景，例如数据仓库、自定义函数、云函数等。数据订阅的架构和同步类似，基于 Binlog 解析，将这些 Binlog 解析为正确
255、的消息对象，基于客户配置的不同的表或库，再推送到内置的 Kafka 里。用户可以很方便地通过各种 Kafka 来消费不同的异构下游，实现了异构数据库之间或者复杂链路之间的同构。同时 Kafka 也支持多分区，可以设置不同的策略来优化大数据量同时传输效率。129腾讯云技术实践精选集 2022Binlog 本身是无法自解析的，解析出来的日志只有数值，没有对应的表结构字段。如果按这种方式推送到下游，其实数据是不可用的。所以我们需要自研的 Schema Tracker 组件来实时、无锁，动态获取维护表结构的变更，这样就完成了整个链路的打通。另外考虑到数据订阅也支持到了更多数据格式，降低了用户切换和使用
256、的成本，可以无损替换使用，方便打通不同链路。通过迁移、同步和订阅三种模块，可以充分打通数据链路之间的流转管理，构建双向、环形、异构、多合一等场景。用户不用自己开发工具或定时任务解决这些需求，可以更专注于业务。数据库智能管家 DBbain数据库中统一管理时有许多难点和痛点，DBbain 是应用于这个场景的一款 SaaS 工具。它有三大功能：智能优化。针对获取信息、分析信息、优化手段痛点，利用完善的云平台监控、智能算法与案例库沉 淀，针对问题根因形成优化手段。数据库安全。DBbrain 内置深度学习算法、海量样本，提供的功能包括安全预警、敏感数据发现、数据脱敏、治理建议等。数据库管理。DBbrai
257、n 的功能包括云上云下混合云管理、无侵入安全链路、掌上运维。基于上述三大功能，DBbrain 适用于数据库日常运维、安全威胁识别、混合云管理数据库、掌上数据库运维等场景。130腾讯云技术实践精选集 2022上图是 DBbrain 的整体架构图与核心优势展示。基于 DBbrain，运维人员可以针对突发复杂告警问题做快速处理或提前规避。DBbrain 的全生命周期管理分为几个模块，一是监控、预防、分析、告警，主要用于事前分析。包括 70 余项监控项，监控大屏、秒级定期巡检，做到全程问题把控，把问题扼杀在摇篮中。这一部分还可以进行性能预测、容量预测，避免因为存储问题影响性能。事中模块包括快速定位和应
258、急管理，如果不幸发生问题可以快速止损。比如一键分析异常能力会给出具体分析，应急处理里的灵活限流可以避免问题扩散，一键 Kill 提供兜底能力。事后需要复盘，复盘后需要一键优化能力，DBbrain 会给出全盘报告对之前的问题复盘，包括自动调优、专家级建议，还有优化效果对比。DBbrain 的一个性能优化场景是慢 SQL 分析。它会基于多维度统计，包括用户和账号等信息，根据耗时区间来统一汇总 SQL 模版并自动排序，这样我们可以灵活判断出是哪个 SQL 导致的问题。下一步是性能优化，我们可以进行编译器、优化器的改写，比如计算代价和成本，同时可以判断 SQL 是不是优质，是不是需要添加索引，可以针对
259、性做优化，也减少了 DB 和研发的各种对接。甚至一些不必要麻烦可以在 DB 层面处理掉。它甚至可以做 API 的拉取，再通过开源组件进行存储分析。这样可以基于 DBbrain 的 SaaS 能力构建自己的运维平台，免费满足收集、分析、优化需求。131腾讯云技术实践精选集 2022第二个性能优化场景是异常诊断。日常诊断是根据秒级监控，对十几个维度的信息做汇总展示。诊断提示展示诊断事件的概要信息，包括等级、开始时间、诊断项、持续时长。DBbrain 会定期进行健康巡检。诊断事件详情可查看事件概要、现象描述，给出智能分析以及专家建议。腾讯云 BI 云图腾讯云图可以零门槛构建 2D 和 3D 的前端大
260、屏，预设有多个模版，不需要有代码门槛，可以快速构建出一个炫酷大屏，同时投屏到不同终端，后端数据源也支持多种。构建大屏只需要四步，首先创建一个大屏项目，再基于预设的模板形成及时预览和所见即所得的页面。第三步是配置数据源，然后预览发布。不管是运维大屏还是业务大屏都可以快速交付。云图的一些案例包括现在常见的疫情监控大屏，包括 3D 版的智慧校园、腾讯内部用的腾讯云大屏，还包括智慧城市、智慧零售等等。这些案例都可以用几步很简单地制作出来，大幅降低研发成本。132腾讯云技术实践精选集 2022总结和展望SaaS 产品价值总结下来就一句话：可以降低用户在工具或者不必要的研发上的投入，更专注聚焦于自己的业务
261、，不需要再去建数据库和前端，直接依赖 SaaS 就好，帮助业务更好地创造自己的价值，不需要分散精力。DTS 后续会在场景化和复杂拓扑场景深耕，可以一键创建用户需要的复杂拓扑链路，比如环形、双向等场景，而且不需要逐条配置冲突策略。DBbrian 后续会向智能化、AI 化方向发展，可以直接基于慢 SQL 自动创建索引，甚至数据库负载自动扩缩容，同时可以利用云原生数据库的快速缩扩容能力，充分结合更多产品进行场景联动，帮助客户创造业务价值。扫码获取完整版演讲 PPT133腾讯云技术实践精选集 2022云成本优化与研发提效03134腾讯云技术实践精选集 2022企业上云，云上资源整体成本优化管理如何做？
262、郭志宏腾讯云资深容器解决方案架构师容器解决架构师团队负责人，具备多年容器，Kubernetes 从业经验和丰富实践经验，主导了腾讯云多个大客户向腾讯云 TKE 迁移及容器化落地工作。Kubernetes 在生产系统中部署率快速上升，然而业务上云的过程中，针对资源的有效利用有待提升。在 ArchSummit 2022 北京站，腾讯云资深容器解决方案架构师郭志宏发表题为企业上云，云上资源整体成本优化管理如何做？的演讲，分享腾讯内部广泛使用的云成熟度模型。该模型将基于云原生技术高效利用云资源手段作为成熟度重要考核指标。郭志宏还在演讲中发布了基于 FinOps 理论指导的 Kubernetes 开源项
263、目 Crane。135腾讯云技术实践精选集 2022云原生资源利用现状CNCF 在 2021 年的报告中指出，目前 96%的企业已经开始使用云原生技术。但另一方面，Flexera 发布的2021 云计算市场发展状态报告提到，云原生领域的资源利用率非常低，大概有 35%的资源被浪费掉了。我们也对腾讯云上客户真实的资源利用率从三个维度做了抽样调查，包括物理机、虚拟机和容器。其中物理机的利用率只有 10%左右，因为物理机没有虚拟化技术，也没有很好的混部方法，所以这个数字可以理解。虚拟机时代，我们通过 VM 在操作系统层面的隔离做了虚拟化，让利用率提升到了 12%，也不高。Kubernetes 和容器
264、具有更细粒度的资源管理和调度能力，它应该可以最大程度提升资源利用率，但其实利用率也只有 14%左右。我们分析了一下云原生时代资源利用率不高的核心原因。在之前没有云原生的时候，企业一般有一个统一的 IT 架构或者财务团队，统一对半年以后的资源需求做规划，然后采购。这是一个中心化的管理模式。迈入云原生时代，更多企业把这种权限下放给了其他业务团队，上云后资源分配更频繁，灵活度更高，所以没法通过中心化手段统一管理，而是用类似分布式的手段下放给其他组织。虽然灵活了，但是管理难度更大。也就是说虽然技术或者手段有了迭代，但管理维度上对 Kubernetes 的理解程度不够，导致了利用率还是无法显著提升。深入
265、理解 Kubernetes 的资源管理首先我们来看 Kubernetes 是如何管理资源的。Kubernetes 是声明式的 API，对每一种管理资源都抽象了一个对象。为了给系统或者底层组件做预留会有预留资源，分配后会有剩余，比如说一些碎片资源没法分配。Kubernetes 还有两个核心概念，Request 和 Limit。Request 指的是申请的资源数量，Kubernetes 是根据申请做调度的。Limit 指的是使用过程中最大可以使用的资源数量，这两个参数对应 Kubernetes 底层的容器和技术。Request 对应 CPU Share，指 CPU 内核调度权重；Limit 对应
266、Quota，限制最大用量。这两个参数可以提升部署密度，Request 小于 Limit 时就可以申请比较低的资源，但它可以在利用率高的时候用更多资源。136腾讯云技术实践精选集 2022上图是典型的资源利用率较低的情况。资源总量很多，但实际使用并不多，中间有很大浪费，包含很多未分配以及过多分配的资源。在线业务还有波峰波谷，这些波谷也是被浪费了。所以提升资源利用率的核心思路就是从这三部分入手来解决问题。Kubernetes 也提供了弹性能力，帮助我们进一步提升资源利用率。虽然 Kubernetes 提供了提升资源利用率的手段，也可以细粒度管理资源，但实践中用户往往并不能充分利用这些手段。核心原因
267、是我们向容器化迁移后往往会带着之前的经验，延续过去的用法，导致水土不服。业务人员如果通过压测来规划业务增长规模，往往规划也是偏多的。如果通过弹性能力来扩容，遇到业务高峰又可能出现扩容不及时导致业务崩溃的情况。还有一些业务优先级较高，用户也不敢缩小资源配比。总结来说就是不会配、不敢配、不能配的问题。基于云原生技术的成本管理最佳实践基于上面的这些问题，我们有了对应的思考、方案和实践落地。首先，我们提供了全链路降本方案，从三个维度出发：137腾讯云技术实践精选集 2022上图概括了我们的三大方案，也就是解题思路。有了解题思路后还需要理论指导，这里就要提到 FinOps Framework，它定义了一
268、套最佳实践和原则。它提倡团队协作，提倡团队内部每个人都有成本管理意识；它也有一些自上而下的角色，由 FinOps 从业者或管理人员驱动整个团队做成本优化；它也有一些阶段，例如成本展示、费率优化、持续迭代运维等；要做到成功优化，我们还需要一些核心能力，包括理解用量、理解成本，理解浪费；还要做绩效和综合展示，驱动业务团队向前走；还有实时决策、运营日报、费率优化、用量优化等。我们提供的技术手段是 Crane 开源项目。Crane 是 Cloud Resource Analytics and Economics 的缩写，就是云资源分析和优化。Crane 框架的核心能力完全对标 FinOps 能力模型，
269、包括理解成本、快速决策、性能优化、费率优化等。Crane 核心由两部分组成，第一部分是 Craned，第二部分是 Crane Agent。Craned 的核心是资源的预测，正常的在线业务都有类似波形的周期曲线，所以我们可以根据波形算法和历史利用率预测未来一段时间可能需要的资源数量，推荐合理的 Request。有了预测还可以做提前弹性，解决扩缩容延迟问题。还可以预测空闲时间，让空闲资源被其他业务重复使用。提升利用率的同时必须保障业务稳定性。Crane Agent 就是做稳定性相关的工作，它扩展了 kubernetes 的PriorityClass，提供了更多业务优先级定义。我们还提供了一些全功能
270、的 QoS 隔离，包括 CPU、内存、网络、GPU 的 Kubernetes 隔离能力，保证高优业务不被干扰，低优业务可以避让。138腾讯云技术实践精选集 2022上图是我们内部基于 Crane 做的降本产品框架。基于这样的降本产品，腾讯内部按照 FinOps 的能力模型指导了实践落地过程。首先我们做了成本分析，发现业务资源利用率不高，弹性也不好，只有 10%左右的 HPA 在一年中弹出过。第二步我们做了目标设定，目标是自上而下设定，绩效则是自下而上汇总：1.为优化腾讯内部业务云资源，腾讯定义了云成熟度模型；2.该模型从平台侧以及业务侧考核各个 BG 的云资源使用情况；3.总成熟度得分=业务侧
271、得分*50%+平台侧得分*50%；4.得分情况从作业、产品、部门维度层层汇总，并以该结果作为考核参考指标。通过这样的模型，我们推动业务部分提升得分，取得了很好的效果。我们还有一个奖金池来奖励表现较好的团队。FinOps 还需要持续的优化迭代过程。这里分为业务侧和平台侧两个维度。业务侧提供了成本可视化，业务人员可以看到自己的业务资源使用率情况、浪费情况、本月费用、下月费用预测。我们还根据不同部门、不同业务、不同标签做业务汇总。使用过程中业务会提出各种各样的需求，我们也支持了原地升降配能力、提升 VPA 时不需要重启的能力等。139腾讯云技术实践精选集 2022我们在平台侧也提供了一些能力，比如说
272、集群大盘的可视化，可以看到大盘集群资源利用率，哪些节点是热点，哪些节点的资源利用率不高，等等。为了提升部署密度，在业务侧可以降低 Request，在平台侧可以放大节点的可调度能力。我们在平台侧可以给节点容量做缩放，为了保证节点稳定性还提供了节点的控制。比如说某节点预估最大的 CPU 和内存达到了 80%，新的业务就向它调度，保证节点不被打掉。我们还提供了紧缩优先策略，一些空闲的资源利用率不高，我们就不往这个节点上调度，后续可以把这个节点回收掉。这些都是 Kubernetes 原生调度没有的能力。平台侧还有一大优化能力是业务定级与混部。我们可以大范围提升资源利用率，核心有两点，一是提供了 Pri
273、orityClass 的优先级定义，让业务定义它的优先级，高优任务可以定成 1 和 0，其他业务可以定到 2、3，离线任务可以定义较低水平。这样通过 Crane Agent 或底层内核提供的 QoS 隔离技术保证高优任务可以在业务高峰时抢占低优业务资源。腾讯内部目前有上百万核的混部集群，利用率一直维持到 50%-60%左右。降本产品混部推广后在数百个集群、上百万核资源做了实践。结果资源的申请量通过预测技术降低了 25%左右，效果非常明显。GPU 资源成本优化两年前谷歌在一份调研报告中提到，GCP 的 GPU 利用率只有 40%左右。腾讯云上用户的 GPU 利用率也不高。我们认为核心原因在于 G
274、PU 推理任务较多，很多资源被浪费。目前 Kubernetes 提供的 GPU 管理技术也没法共享资源，英伟达提供的 vGPU 技术也没法细粒度到进程层面的调度，所以 Kubernetes 场景使用起来不太方便。业界方案也有很多问题。基于这些困境，腾讯虚拟化团队做了 qGPU 产品。它可以让多个容器共享一张卡，并且可以细粒度保证算力和显存精细隔离，同时支持业界唯一的在离线混部能力，从而在精细切分 GPU 资源的基础上，在最大程度保证业务稳定的前提下，将 GPU 利用率压榨到极致，最终帮助客户大幅节约 GPU 资源成本。qGPU 使用起来非常简单，我们继承了 Kubernetes，还提供了三种隔
275、离策略和调度模式，分别是默认的 Best-Effort，可以互相抢占；Fixed-Share 固定配额；Burst-Share，保证配额加弹性能力。140腾讯云技术实践精选集 2022扫码获取完整版演讲 PPT我们测试了 qGPU 方案的性能，发现精度、准确度、吞吐和原生方案相比基本没有损失，隔离性非常好。qGPU 与业界方案对比，兼容性、抖动性、算力隔离、灵活度、切分粒度等层面都有优势。Crane 项目在 2021 年底开源，希望业界可以一起参与共建，也欢迎大家试用和落地实践。希望我们提供的技术可以帮助更多企业享受到云原生技术的红利。141腾讯云技术实践精选集 2022企业如何利用云厂商能力
276、构建自己的分布式云？李向辉腾讯云容器技术专家腾讯云容器技术专家，腾讯云分布式云产品副总监，主要负责腾讯分布式云产品，致力于基于容器技术构建分布式云，构建分布式云操作系统，向下屏蔽混合异构的基础，向上支撑业务系统上云，同时支撑更多的应用和行业。具有多年分布式系统高可用，可并发和在线服务治理经验，曾负责过十亿 pv 应用的在线业务架构和应用迁移云原生经验，以及混合云操作系统经验，在稳定性提升，成本优化，效率和业务体验提升上有较深的积累和思考。2021 Flexera 云状态报告显示，92%的企业选择多云战略，企业平均使用 2.6 个公有云+2.7 个私有云。Gartner 2020/2021 连续
277、两年将分布式云作为十大顶级战略趋势之一，同时预测，2025 年超过 50%的组织将使用分布式云实现业务转型。信通院“2021 云计算十大关键词”之三：云原生、混合云、边缘计算。企业在构建分布式云的过程中，面临复杂的网络互通与管理，统一控制面和操作体验和业务单元化部署等众多挑战。ArchSummit 2022 北京站上，腾讯云容器技术专家李向辉发表演讲企业如何利用云厂商能力构建自己的分布式云？介绍腾讯云在分布式云领域的实践和思考，介绍企业如何利用企业既有的 IT 投资构建自己的分布式云，实现降本增效。142腾讯云技术实践精选集 2022企业上云困境与行业趋势我们首先来看企业上云面临的核心问题。第
278、一个问题是 IDC 利旧场景。在企业上云时往往有大量 IDC 物理机或私有云，希望能充分利用这些 IDC 资源。其次，这些 IDC 资源和公有云连接后，发现整体资源利用率只有 10%左右。企业面临的问题是如何通过部署密度提升、综合调度编排能力、离在线混部来提升资源利用率。第三，由于用户在 IDC 环境中构建了自己的私有云，同时又使用了云厂商能力构建了公有云，在满足数据主权和安全能力需求的前提下，如何构建体验一致的一朵云也是一大问题。最后，混合多云成为目前企业上云的主流架构，企业要同时面对 IDC 资源和多家公有云资源，如何屏蔽底层的异构基础设施，实现上层应用的统一管理，也是一大课题。目前业内有
279、三大技术趋势值得关注：一是容器采纳率在不断提升，2022 年 Forrester 报告指出行业容器采纳率达到 50%左右，CNCF 云原生用户调查报告也显示，目前计划和正在使用容器 K8s 的用户达到 96%；其次，由于新冠疫情和地缘政治的影响，降本增效成为企业的主要趋势；最后，我们还看到托管容器服务的平均年增长率达到了 140%，同时容器的渗透率达到 50%+。我们认为云原生能够很好地屏蔽底层异构基础设施的差异，同时有效提升部署密度和弹性。分布式云能够有效平衡资源和应用架构，是企业渐进式上云的最佳方案。Gartner 在分布式云的定义中指出，将公有云服务分布到不同的物理位置，而服务的所有权、
280、运营、治理、更新和发展仍然由原始公有云提供商负责。腾讯云在 2022 年七月份联合信通院发布业内首个“分布式云发展白皮书”。我们认为分布式云是将云服务按需部署到不同地理位置，提升统一管理能力的云计算模型。腾讯云在原生分布式云的实践腾讯云原生分布式云的载体是云原生操作系统遨弛 Orca，我们希望统一管控用户跨数据中心、多云和边缘的基础设施，给用户提供一致的体验，使用户可以随时随地构建云原生的应用能力，最终将一致、延伸的云服务提供到用户的生产现场 IDC。我们希望通过腾讯的云原生操作系统实现分布式云的战略，最终达到开源创新、全域治理、无限算力和触手可及的目标。腾讯云原生分布式云是构建在遨弛操作系统
281、之上的，是一个面向多云和多集群的应用管理平台，主要包括三个部分：143腾讯云技术实践精选集 2022TKE Anywhere，希望能够在任意位置创建 Kubernetes 集群，纳管任意的 Kubernetes 集群；TKE DataService。我们在用户落地实践的过程中发现用户需要有云端监控、日志、运维、审计以及安全等能力。当我们向用户交付本地化容器环境时，用户需要 PaaS 数据库和中间件能力。这一部分可以将公有云 PaaS 能力延伸至多云、混合云或边云环境；TKE AppEngine，分布式云应用管理平台。云原生分布式云的应用场景包括：资源利旧，打通 IDC 资源和云上资源，实现云上
282、云下的一致体验；云边一体场景，将公有云能力交付至云下，通过分布式管控进行弱网自治，实现云边一体管理；混合多云，构建一个多云混合云底座，实现业务的跨云迁移和多活。腾讯云原生分布式云的主要解决场景我们在落地过程中面临的核心问题如下：144腾讯云技术实践精选集 2022如何管理异构的基础设施差异我们的解决方案是 TKE Anywhere。TKE Anywhere 是将 TKE 延伸到任意环境，无时无地无差异地获得腾讯云原生能力。对于云下节点，TKE Anywhere 可以通过云联网技术实现云下节点和云上VPC 的互通。其次，TKE Anywhere 使用了腾讯开源的 Clusternet 方案，可以
283、通过反向注册通道为 Agent 反向连接到云上时构建安全通道，实现云上可以安全管控云下集群，最终实现云上和云下集群和节点的统一管理。在边缘等网络条件较差场景下，采用 SuperEdge 方案保证网络断开情况下用户也能保持边缘自治能力。通过构建安全的连接通道和云联网连接，TKE Anywhere 可以将云上监控、日志、审计、事件、安全认证、权限授权等一系列能力延伸到云下。我们还可以通过应用市场分发云上应用，同时进行业务的治理、一键扩缩容、PaaS 组件的交付。如何解决多场景网络互通我们还提出了新一代容器网络解决方案，适用于四种场景。用户在云上可以使用我们的网络方案，但用户在 IDC 场景下不具备
284、 SDN 网络能力，需要采用 BGP、Overlay 等多种网络模式。我们支持在一个集群、一个节点上运行多种网络模式，实现混合网络的网络互通。给用户提供云上 LB 方案时我们采用 LB 直通的零损耗网络方案，可以使整体性能提升 50%-70%。同时我们还支持网络限流能力和在离线混部，在混合网络场景下支持业务动态优先级的绝对抢占及多优先级任务的抢占。我们还有精细化 IP 管理机制，包括指定 IP、固定 IP 和多集群共享子网能力。整套网络方案支持万级 TKE 集群、30 万节点和 600 万容器稳定运行。如何实现轻量应用交付传统本地化交付方案采用云下交付，需要派遣驻场运维人员，成本较高、毛利较低
285、。且私有化交付导致版本管理复杂，问题的发现和解决依赖驻场人员。我们的轻量交付方案依托开源 Clusternet 方案，通过 Clusternet-Agent 和云上分布式云集群 TDCC 连接后，构建了一个完整的交付通道。当用户没有完整的 TKE 集群时，我们将云上 TKE 的发行版交付到云下，而用户只需要在云上简单操作就可以完成部署，后续的运维和升级由腾讯公有云来负责。如果用户已经有了 Kubernetes 集群，我们通过注册集群能力安装好 Clusternet-Agent，完成云下集群和云上集群的连接，构建一个交付通道。接下来可以通过云上应用市场能145腾讯云技术实践精选集 2022力将云
286、上应用分发至 TKE Anywhere 或者注册集群。之后通过正向代理构建 LB，将云下日志、监控等数据推送到云上，然后依靠公有云监控和日志来做报警，可以先于用户发现问题。由于云上集群和云下集群是一致的 TKE 发行版，也就提供了一致的用户体验。由于云下数据会实时推送到云上，我们可以运用公有云的大量运维经验先于客户发现问题，发现问题后又能通过交付通道来及时修复，降低集群运维成本。用户还可以通过这个交付通道连接自己的应用，实现自己应用的备份和升级能力。如何解决数据库中间件依赖问题完成用户集群交付后，用户在多云环境下会有一些数据库和中间件的依赖。这里通过 TKE for DataService 的
287、能力，使用上述交付通道来交付云上 PaaS。TKE for DataService 的能力有远程投递、离线时云下自治，以及在公有云管控云下服务，提供多云 IDC 和边缘场景下一致的数据库引擎及管理能力。用户在构建 PaaS 体系时会存在 PaaS 版本不一致，多云 PaaS 不统一，PaaS 弹性扩容能力不足三个问题。用户 PaaS 版本的能力不足时，我们可以通过云上远程投递能力逐渐满足用户需求。用户多云的 PaaS 不统一时，因为我们在底层构建了 TKE Anywhere，就可以将一致的 PaaS 应用在这个环境下，实现 TKE PaaS 能力的统一。因为原有的 PaaS 能力扩容依赖于底层
288、资源扩容，由于我们的 PaaS 是在容器环境下，环境适配后可以提供快速弹性。目前我们已经支持了 6 款 PaaS 组件的分发。如何解决应用统一管理问题用户在多集群环境中需要统一发布管理多个云上的应用和服务，还要解决应用的跨域容灾、故障迁移、备份场景需求，与多集群间的弹性伸缩调度需求。为此我们提供了 TKE AppEngine 一站式应用管理平台。该平台可以构建分发资源，称为 CRD，再由用户制定分发策略，进行多个集群的统一分发。多个集群配置存在不一致时，可以通过配置的差异化管理来满足多个集群之间分发的差异性要求。在此之上，我们构建了一个云原生网关，能够基于流量进行智能调度和亲和性调度。同时我们
289、提供了一套统一的权限和认证机制，满足业务的安全、合规和审计需求。平台整体对用户是零侵入的，用户可以方便地管理自己的集群，而不需要对原有的基础设施进行统一改造。146腾讯云技术实践精选集 2022如何进行成本优化如何将云上成本优化经验输出到云下？我们给出的解决方案是成本大师。我们认为成本优化分为几个方面：首先是可扩展的资源优化推荐，通过实时监控数据发现业务级别的浪费情况，同时给出业务的平台得分和业务得分，为用户提供整体的最佳资源推荐。这里分为 Request 推荐和副本数推荐，能够推荐出一个应用应该申请的内存、CPU 的资源大小、以及它应该有多少个副本；针对突发流量，我们实时监控用户过往 14
290、天的数据，结合用户应用特征绘制用户的业务画像，我们能够提前预测整个业务的副本数和推荐资源，通过容器原地升降配以及副本数扩充去解决 VPA 和 HPA 扩容和弹性不一致问题；我们还提供了节点增强调度能力，支持节点打散和紧缩调度，提升节点利用率并实现应用均衡调度。在业务混部场景，我们通过多优先级管理和容器动态调度机制来解决调度时容器资源分布不均的问题。基于腾讯开源方案，我们提供了 CPU、内存、磁盘、网络以及 GPU 等多种资源的精细隔离能力，实现资源的最大化利用，降低应用的交付成本。企业构建分布式云案例分享企业该如何构建自己的分布式云原生云？我们提出了三种模式：第一是节点连接模式，也就是注册节点
291、模式；第二是集群部署模式，也就是轻量交付模式；第三是集群注册模式，也就是集群连接。注册节点是云上运行托管的 TKE 服务，允许用户将非腾讯云的主机添加到腾讯的容器服务。此时 Kubernetes 集群的控制面在云上，而用户自己的节点通过专线和云联网技术和云上打通，这样就可以利用 IDC 资源来进行整体部署。同时由于云下只有一个简单节点，云上节点就可以免运维。由于云上 TKE 的控制面对接到了云上监控、日志、审计和安全服务，就可以无差异实现云下和云上节点的能力一致性。同时我们也支持云上和云下节点混合部署，实现云上和云下一致的弹性。实践中，某客户在 IDC 购买了大量物理机需要利旧，但在上云时这些
292、机器又不能退库。用户还想尝试云原生技术方案来提升部署密度和降本增效，希望利用这些 IDC 资源实现快速云原生。我们给用户推荐了云原生分布式云方案，将 IDC 节点以云联网方式加入公有云，实现 IDC 节点和云上 VPC 之间的互通。接下来，我们在云上节点运行云上插件，在云下运行 Overlay 网络模式，使用集群的混合网络。IDC 集群导入公有云后，整个云集群的运维由云团队负责，同时 IDC 资源又能够利旧和重复投入，实现降本增效目标。147腾讯云技术实践精选集 2022有些客户有大量 IDC 资源，需要在 IDC 里部署一个集群，同时需要完整的控制面。这时用户往往会自建一个 Kubernet
293、es 集群，但 Kubernetes 集群的学习曲线是非常陡峭的。这时可以用 TKE Anywhere 集群来统一云上和云下能力。还有客户的数据机器是边缘节点或设备，分散在相距几十公里远的工厂内，网络又是弱网络。这时可以使用 TKE edge 方案，TKE 控制面在云上，云下节点只需装一个插件就可以实现云下弱网环境的统一管理。随后，用户可以通过云上应用市场，将日志监控和 PaaS 能力下发到云下，运维一侧又有公有云的运维团队负责，这样极大提升了应用的交付效率，降低了业务的交付成本。这种模式称为轻量交付模式。某光通信企业有若干工厂和分厂，工厂间距离很远。客户希望在集团统一管理各个分厂，又希望有统
294、一的云厂商维护集团公有云的基础设施。我们提供了云原生分布式云的分级管控方案。首先我们在云上通过云原生分布式云中心，为用户集团工厂交付若干个 TKE Anywhere 集群。在集团工厂上，我们通过 TKE Anywhere 搭载的边缘一体机部署在用户的企业工厂。边缘一体机注册到 TKE Anywhere 上，实现数字工厂的三级管控能力。同时用户可以用边缘设备打通自己的 IT 和 OT 通道，获得大数据运算及边缘 AI 检测能力。由于我们打通了云边端通道，用户出现故障后我们可以及时解决。集群注册是将用户本地数据中心的 K8s 集群或其他云厂商的集群接入到云平台实现统一管理。云原生分布式云中心可以对
295、多个集群进行统一管理，对分布式应用进行统一分发，同时管理多个集群的流量来实现业务流量的动态调度。云上的可观测能力还可以满足监控和审计要求。某韩国游戏注册用户 1500 万，业务主要部署在东京、首尔和新加坡的 TKE 集群，以及北美和欧洲的 AWS 集群。由于我们的云原生分布式云是支持国际站的，我们通过国际站能力将分布在 TKE、AWS 和 Kubernetes 的集群进行统一管理，同时将日志监控统一接入腾讯云国际站，给用户提供开箱即用的高运维效率和系统高稳定性。同时我们通过应用的分发策略、多集群的批量发布和灰度发布能力，最终实现业务的快速迁移，提升了业务发布效率，降低出错率。148腾讯云技术实
296、践精选集 2022总结总体来说我们解决了两个核心问题，一是管理异构资源，二是承接上层应用。我们主要通过五层能力来构建方案，最底层是腾讯云遨弛云原生操作系统，之上构建了 TKE Anywhere 实现任意位置集群的统一管理。在此之上通过 TKE for DataService 实现云上能力一比一延伸至 IDC 和用户现场。在 PaaS 组件和应用交付后，我们提供了一站式的应用管理中心来多维度管理用户在多云上的应用。最后，我们希望云原生分布式云能够给用户赋能，让用户可以利用云厂商能力在任意基础设施上享受腾讯云带来的云原生生态，构建一朵自己的分布式云。扫码获取完整版演讲 PPT149腾讯云技术实践精
297、选集 2022从混部到 Serverless 化，腾讯自研业务的稳定性及云原生成本优化实践吕祥坤腾讯云容器高级工程师负责腾讯内部超大规模云原生应用平台 TKEx 的研发设计工作，已支持包括腾讯会议、QQ、腾讯文档在内的海量自研业务实现云原生架构改造。随着云原生技术的逐步推广，腾讯公司内部也在大力推动业务使用云原生容器化的方式去构建自己的应用。Kubernetes 作为云原生应用管理平台，成为大家的一致选择。虽然 Kubernetes 有着众多优势，但是去建设并运营一个云原生应用平台，依然存在很多的痛点与挑战。特别是在业务规模快速增长后，平台资源运营成本居高不下。为此平台希望通过混部提升资源利用
298、率，以此节省成本，却导致服务稳定性受损。ArchSummit 2022 北京站，腾讯云容器高级工程师吕祥坤带来分享从混部到 Serverless 化，腾讯自研业务的稳定性及云原生成本优化实践，介绍腾讯内部云原生应用平台在面临规模快速增长遇到的痛点问题时给出的解决方案。150腾讯云技术实践精选集 2022腾讯自研业务容器化上云历程及主要问题上图是腾讯内部业务上云的简略架构。最下层是我们腾讯云基础设施层，包括计算、存储、网络，上面提供基础服务。再对服务做产品化包装，就有了公有云的 TKE、EKS、TKE-Edge、TKE-STACK 等，有了这些产品化服务，我们在公司的 OA 这边给用户提供了容器
299、控制台，用户可以在这里查看他们自己创建的服务和相关数据。并且我们会把原生的 Kubernetes API 提供给用户和研效平台，用户可以在研效平台实现从代码开发到应用构建再到应用发布的完整流程。我们的平台早期是独立集群架构，给每个业务在每个用户需要的地域创建一个独立集群。独立集群有几个缺点，一是节点装箱率较低，二是资源利用率偏低，因为很多业务每天都会有很长时间是空闲的。三是运营成本高，四是海量节点运维成本高，没法利用弹性优势。于是我们把独立集群改成了公共集群，所有的业务都使用同一个集群。151腾讯云技术实践精选集 2022在线混部集群的资源利用率提升方案上图是该方案的整体架构。我们会依赖监控平
300、台所存储的业务节点负载相关数据，再使用一些算法对用户资源进行预测，描绘业务画像。有了这些数据后我们做了二层资源超卖、节点负载均衡调度、弹性伸缩、业务配额动态管理。动态调度器。Kubernetes 原生调度器属于静态调度，当大量业务混部在一个集群时，必然出现节点负载不均衡，Pod 调度时仍可能往高负载节点调度，造成业务服务质量下降。为此我们自研了动态调度器，让节点的关键资源在集群节点中均衡分布。调度器会定期拉取每个节点的负载情况，调度时读取候选节点指标来过滤节点，对过滤出来的节点打分并选取合适节点来调度。具体流程中，如果一个集群在某一小段时间内有一大批 Pod 同时创建，很可能这一批 Pod 都
301、被调度到相同节点上，因此我们又自研了热点动态补偿算法来解决问题。我们加了一个评测指标，用它评测节点被调度的频繁程度，用来和刚才计算出来的负载分数对冲。二层动态资源超卖。混部的核心诉求是提升整个集群的资源利用率。为此一定要把超卖比控制好，尽量不影响业务的稳定运行。其次，节点资源超卖后不能对 Kubernetes 驱逐机制和资源预留机制产生影响，超卖比变化需要动态调整 Kubelet 的对应配置。超卖比需要根据节点实时负载数据动态调整，防止节点负载过高。如果确实出现高负载情况，我们会对节点进行驱逐。如果出现大面积节点高负载，会通过集群弹性伸缩方案尽快向集群添加节点。这个方案有两个核心组件，分别是
302、Compressor，用于动态调整 Pod 资源压缩比；还有 Oversaler，用于动态调整 Node 资源超卖比。152腾讯云技术实践精选集 2022集群弹性伸缩。我们平台已经运行了上百个集群，核心目标是统筹全局，让整个平台所有节点能够在各个集群之间高效流转、管理，提升资源利用率。我们还要做不同集群的节点上下线自动化和标准化，同时针对紧急扩容和普通的常规扩容需求准备两个资源池。该方案中，De Scheduler 组件会先送一个节点，把 Pod 驱逐掉。Node Score 组件负责给节点打分，将低分节点下线对整个集群影响最小。HNA Controller 组件在集群高负载时添加节点，集群空
303、闲时下线节点。ERP Controller 对接我们自己维护的资源池和公司免审批资源池，做节点扩缩容。集群缩容策略。集群要驱逐节点时，要选择对业务影响最小的节点。Node Score 组件会对所有节点打分，阈值以下的节点是可以缩容的。这里先拉出整个节点下所有 Pod 的情况，看 Pod 所属的负载是否开启副本数，是否是无状态负载类型，是否创建在了测试空间。知道 Pod 所属的负载得分后，看实际 Pod 的负载情况。经过计算得到节点上每一个 Pod 的得分，最后将所有 Pod 得分求和，再计算和查看节点的实际负载情况，根据实际 Pod 数量得到最终分数。业务弹性伸缩。集群混部方案中业务也要配合弹
304、性伸缩策略。我们基于社区原创的 HPAPlus-Controller 研发了增强版的 CronHPA-Controller 来支持业务常规场景。它支持用户给每个 HPA 对象定制扩缩容策略、HPA 计算周期和容忍度，还支持弹性最大副本数的配置策略。我们还针对整个集群所有对象都创建一个 Workload，需要计算 Workloads 调整副本数时，我们支持几千个对象并行策略，能够最快响应业务流量扩容诉求。HPA 和 VPA 也有联动策略，我们优先会使用固定副本数，但 HPA 也会生效，会计算当前确定的固定副本数是否能满足业务需求；如果不能，会继续扩容到 HPA 最大副本数的 2 倍。在线混部利用
305、率提升方案取得了很好的效果，通过在线业务混部超卖方案，集群 CPU 平均利用率提升到 30%40%。使用动态调度器后，几乎所有节点的资源利用率都比较均衡，方差不会特别大。稳定性提升方案。混部无论如何都会对业务运行造成一定影响。因为原生的基于虚拟机创建的集群上，一个虚拟机会创建多个业务 Pod，这些 Pod 之间并没有完全隔离。当某一个 Pod 出现问题时会导致这个节点上所有 Pod 异常，甚至节点自己出现问题。为此，我们做了节点层面和容器层面的优化。在节点层面，我们所有的集群都装了 APD 组件。它会读取节点状态，分析异常日志，展示稳定性指标等。腾讯内部团队专门定制了一个团队内核，我们能读到内
306、核级别的稳定性问题。出现异常时我们会按照预定策略执行动作，比如重启节点。153腾讯云技术实践精选集 2022拥抱腾讯云弹性容器服务 EKS 的价值所在集群扩展到超大规模后，混部带来的稳定性影响是不可避免的。于是我们逐渐把架构从混部迁移到了 Serverless，就是腾讯云弹性容器服务 EKS。EKS 采用 Serverless 架构，以 Pod 为交付资源，无须在集群添置节点即可部署负载。容器弹性不受固定资源池限制，理论上可以无限扩容。它采用 Pod 间虚拟化隔离技术，每个 Pod 独享虚拟机，不会被集群其他异常 Pod 干扰。EKS 通过 Pod 而非节点计费，根据 Pod 的资源配置及运行
307、时间计费，容器运行结束自动停止计费，无须为 Buffer 资源付费，可以降低运营成本。EKS 的产品优势包括：支持 K8s 编排，完全兼容社区 K8s API。内核的计算、网络性能非常好。高可用，可自动/指定跨 Zone 部署应用，容器支持热迁移。支持异构算力，包括多种主流 CPU 型号、虚拟化 GPU。弹性效率，支持敏感扩容、定时扩容。安全性强大，有租户间隔离等。154腾讯云技术实践精选集 2022扫码获取完整版演讲 PPT未来规划 引入 EHPA，预测传入的峰值流量并提前扩展其副本数，提升用户使用 HPA 的信心。通过服务负载历史数据，给用户进行资源配置推荐，以此提升资源利用率。针对需要固
308、定副本数的工作负载，进行副本数推荐；针对可以开启 HPA 的工作负载，进行上下限副本数推荐。155腾讯云技术实践精选集 2022Serverless 时代下，企业微服务的降本思考与实践于善游腾讯云微服务高级工程师腾讯云高级工程师，负责腾讯云 TEM 产品的设计与开发，专注于微服务和 Serverless 云原生领域，在微服务方向具有丰富经验。自 2014 年 AWS 推出 Lambda 服务开始，Serverless 的概念遍借着云原生的东风吹向企业应用开发的各个角落。Serverless 快速交付，免运维，极致弹性扩容等诸多特点，为企业应用开发的降本增效提供了简洁有效的最佳实践路径。与此同时
309、，在如今大多数企业应用架构都已经转型为微服务架构的今天，如何让微服务在 Serverless 平台产生价值最大化，让 Serverless 平台成为支撑微服务架构实现的最佳方式，便成为了一个值得探讨的话题。ArchSummit 2022 北京站上，腾讯云微服务高级工程师于善游带来题为Serverless 时代下，企业微服务的降本思考与实践的演讲，从腾讯云微服务产品矩阵出发，结合众多企业在上云过程中的实践，为大家提供企业微服务架构在 Serverless 平台上实现降本增效的新思路和最佳实践方式。Serverless 场景带来的新机遇在前云原生时代，IDC 基础设施时期的问题是波峰波谷相差很大，
310、用户成本和体验很难平衡。虚拟机时期的问题则是虚拟化技术重复轮子很多，很难保证质量，且一致性较差。156腾讯云技术实践精选集 2022进入云原生时代，主流的 Kubernetes 最大的问题是学习曲线陡峭，且生态庞杂、难以取舍。传统应用改造迁移成本非常高昂。2016 年谷歌 Cloud 诞生，FaaS 形态的 Serverless 产品开始百花齐放。2019 年，基于 Kubernetes 的 Knative 诞生，以应用为中心的 Serverless 产品进入新形态。Serverless 有两种形式，一种是面向应用的，另外一种是 FaaS。很多用户认为 FaaS 并非最佳选择，因为企业需要对应
311、用做大规模改造来对接 FaaS 平台，且 FaaS 依旧需要冷启动时间。为此腾讯关注的是面向应用的 Serverless，希望让用户的应用无需改造也能享受 Serverless 的优势。Serverless 平台如何成为微服务架构的最佳底座在企业架构演进过程中，资源层和应用层是相辅相成的发展过程。应用层从单体发展到微服务架构，资源层则从 IDC 到 Kubernetes 再到 Serverless。微服务体系的特性包括日日可发布、实时可扩缩、故障可回滚、平滑过渡，随之而来的是发布挑战，流量弹性挑战，可监测性挑战。腾讯致力于帮助用户解决这些问题，通过极致的弹性方式帮助用户提升可用性，帮助用户平滑
312、升级应用，保证业务不中断服务，同时也节省用户的资源成本，解决服务质量下降和运维成本高的问题。第一代微服务技术是侵入式的框架，其优点是去中心化，引入注册中心，服务间的通讯及容错机制模块化，非功能性能力下沉。而它的缺点有框架适用范围、语言有限，对业务存在侵入性，框架维护成本高、升级困难，框架提供的治理能力有限。第二代微服务技术是 Sidecar Proxy 模式的服务网格。优点是屏蔽分布式系统通信的复杂性（负载均衡、服务发现、认证授权、监控追踪、流量控制等），服务只用关注业务逻辑；异构语言，统一服务治理体系，标准化；对应用透明，Service Mesh 组件可单独升级。缺点是存在一定程度上的性能损
313、耗，引入 Service Mesh 服务实例还有运维和管理问题。第三代微服务技术是内核态的服务网格，优点是不需要 Sidecar，直接在套接字和网络接口处拦截数据包，请求路径缩短，性能更优。缺点是实现复杂，技术较新，未经过大规模生产验证。157腾讯云技术实践精选集 2022上图是企业微服务在云上部署的一种形态。腾讯云 TEM 针对企业应用降本增效的优化首先是 DevOps 层面。DevOps 是部署到各个环境上的构建模式，是比较流行的构建方式。TEM 通过两种方式实现 DevOps，一是通过腾讯云 Coding 平台。我们在 Coding 上有插件，可以部署到腾讯云的 TEM 上，可以选择各种
314、发布方式，自动分批或者手动分批发布，接入 Coding 上云。第二是 IDEA 方式，主要面对开发者。我们开发了一个 IDEA 插件，开发人员可以直接通过 IDEA 部署到腾讯云上。其次是针对镜像构建加速做的优化。传统的 Docker Build 有很多问题：只改变 Dockerfile 中的一行，就会使之后所有行的缓存失效；无法提供编译历史缓存，多阶段并行的构建效率不佳；镜像 Push 和 Pull 的过程中存在压缩和解压的固有耗时。因此腾讯云 TEM 针对传统的 DockerFile 做了改变。我们用了最新的 Docker 开源数据，Buildkit 组件做了构建。该组件的稳定性、兼容性、
315、构建效率、Push 效率和可维护性都很好。经过优化后，用户原本拉取镜像所需的时间被节省下来，镜像构建和 Push 速度也提升了。TEM 针对应用加速也做了优化。这里主要是指 Java 的应用加速。Java 提供了一种冷启动加速方式 AppCDS，先使用 ClassList，然后把源数据存储到 JSA 文件中，再指定文件进行应用加速过程。它的缺点是使用比较繁琐，且 Spring Boot 应用需要使用 Maven Shade 插件改造。而 TEM 对任何应用都可以直接158腾讯云技术实践精选集 2022加速，无需任何改造。RCK 会自动解析 JAR 包，对 Spring Boot 嵌套 JAR
316、包结构进行解析和改造。TEM 还能自动将 AppCDS 的归档文件构建成一个 Image Layer。TEM 还使用 AppClassLoader 加载归档文件，实现加速。在发布管理层面，我们引入了开源社区的 OpenKruise CloneSet。但它不支持多个批次，只支持两批；它还不支持自定义删除策略，原地升级是先缩后扩的语义，需要支持多种批次确认策略。第一版的问题主要是过多消耗用户资源，平台侧成本也较大。为了解决问题，我们引入了多集群管理方案。这是平台纳管的 Kubernetes，可以做应用下发、协同管理。在极致弹性层面，TEM 针对传统的 HPA 做了一些改造。我们可以通过一些指标做弹
317、性处理，还支持从 0 到 1 的弹性过程。我们对接了 TEM 上的各类 HPA，如网络带宽、网络流量、磁盘流量等指标都可以对接上去。可观测性层面包含三部分，分别是 Logging、Tracing、Metrics。TEM 可以通过各种各样的协议进行指标上报。腾讯云 TSE 针对大规模微服务的落地实践腾讯内部的注册中心孵化出了北极星（PolarisMesh）。之前，我们在服务注册上遇到的最大问题是公司的服务注册是不统一的。我们为了统一服务注册开发了北极星，目前整体注册服务数已达 160 万，服务企业数 340 万，接口日调用量 20 万。北极星解决了分布式和微服务架构中的服务发现和治理问题，提供了
318、服务注册、健康检查、服务发现、服务路由、负载均衡、服务降级、服务熔断、服务限流等功能。其中，TSE 解决的是微服务的传统问题，提供服务注册、健康检查、服务发现、服务路由、负载均衡、服务降级、服务熔断、服务限流等功能，还可以提供跨地域的数据就近接入能力。北极星除了支持多语言 SDK 外，还有 Mesh、HTTP、DNS 接入，解决了多个集群之间的通信问题，同时还提供 HTTP 协议和 DNS 的注册过程。TSE 还为央视频提供了统一的注册方案。TSE 的全局服务注册中心解决了服务发现问题；多种路由策略，解决集群隔离以及互访问题。TSE 还兼容多种接入模式，解决新增与存量互访问题等。扫码获取完整版
319、演讲 PPT159腾讯云技术实践精选集 2022腾讯课堂面向协作的 DevOps 流程设计与实践董峤术腾讯课堂研发效能负责人先后参与过 QQ 群、吃喝玩乐、NOW 直播、腾讯课堂等产品的研发，在云原生、研发效能和分布式架构方向深耕多年，目前是腾讯课堂后台 Leader 和研发效能负责人。关注云原生、CICD、可观测、自动化测试、性能和成本优化等方向的最新理念与实践。今天的互联网行业面临了越来越多的不确定因素，如何降本增效成为热议话题。在 ArchSummit 2022 全球架构师峰会（深圳站）上，腾讯课堂研发效能负责人董峤术带来了题为腾讯课堂面向协作的 DevOps 流程设计与实践 的演讲。董
320、峤术从研发流程和开发节奏入手，分享腾讯课堂在 DevOps 流程中，如何通过统一化、标准化、透明化、主干开发、APIOps、GitOps、测试左移、领域驱动等方法，逐渐降低研发人员理解和交流成本，提高工作拆分的合理性和提升项目落地执行效率，从而提高业务整体研发效能。背景腾讯课堂平台是 B2B2C 的直接教育平台，业务非常复杂。首先它是一个电商平台，有商品系统、机构中心、营销系统和支付结算系统；其次它也是一个教学平台，有直播房间业务、考勤签到业务、考试批改业务；另外它也是一个开放协作平台，有开放平台、ToG/ToB 业务、私有化能力。腾讯课堂平台有多年历史，现在微服务有上千个，三种语言实现，五种
321、 RPC 框架，历史债务很多，提升研发效能比较困难。160腾讯云技术实践精选集 2022外部因素来看，近两年在线教育经历了高峰到低谷，又出现了职业教育风口，我们也在顺应大潮发展职业教育。面对这些内外部因素，业务快速迭代的能力就成为通向成功的非常关键的因素。谈到快速迭代，理想的研发节奏是按部就班的，按照产品节奏慢慢迭代，但现实情况不是这样。因为市场、用户习惯、政策都在变化，面对突如其来的问题我们可能会发起一场战役，打完后会修整一下进入下一场战役。为了打好团战，我们有很多角度可以提升效率，例如建设公共中台来提高复用度、通过云原生实践降低业务的运营成本、实现快速自动扩缩容、提高开发人员研发和交付的能
322、力，或者技术主管提前预测产品动向，做技术预研或布局，等等。从 DevOps 的角度来看，我们要提高协作效率，从而提升团战能力。从 DevOps 流程来看，随着参与人员不断增多，研发耗时成本一开始会逐渐下降，但继续增加就会逐渐趋于平缓，甚至可能会开始回升。因为人员之间的理解成本、交流成本和资源浪费不断增加，对人员沟通协作能力、对需求的拆解能力、方案的细化能力等要求也在不断增加。为了应对这一挑战，我们可以将需求的生命周期分为需求评审、技术方案、开发、联调、测试、发布、运营等过程。这些过程中有四大关键点贯穿始终：1.理解，指团队对需求、技术栈等有一致的认知和操作；2.分工，指对工作合理细致的拆解；3
323、.交流，指研发过程中团队内部和部门之间的顺畅有效的沟通交流；4.落地，指上述措施切实有力的落地执行接下来我们从实践出发，来看如何提升这四大要点的效率。理解以一个业务痛点为例，研发人员经常抱怨工具太多，频繁切换带来很大心智负担。我们的优化策略是在 DevOps 选型时尽可能选择可以闭环整个研发工作流的平台，来提升研发效率。平台的工具链有着联动和组合效应，CI、CD、联调、自动化测试、CO 等工具都统一到云原生 DevOps 平台上。云原生 DevOps 的架构，底层基于腾讯云上一站式 DevOps 平台，上层有开发域、构建域、测试域、部署域、运营域，完善了业务的 DevOps 流程，从而提升研发
324、效能和资源效能。161腾讯云技术实践精选集 2022第二个痛点是缺乏研发全流程的标准化。我们在 CI 环节有标准化过程，但在测试、部署和运营过程中缺失标准。在服务数量较多时，这种情况非常不利于跨团队协作。对此我们通过研效平台做了研发全流程约束。比如新建一个服务，录入服务基本信息，就可以通过平台对整个自动化测试、资源、部署、编排、监控、日志都进行标准初始化。第三个痛点是黑盒问题，就是配置不透明，且分散在各个角落。比如说构建和编译过程在 CI 平台上，而部署的配置是在发布系统上，监控告警是在可观测系统上配置，等等。这里我们是使用了“XAC+同源”的理念，以一个微服务的代码为中心，通过 Makefi
325、le 或 Dockerfile 描述其 DI、编译构建等过程。CI 则呈现成.ci.yml 放入库中，CD 配置放在.cd.yml，等等。这样开发人员都可以通过代码来看清整个 DevOps 过程。总体而言，我们通过统一化、标准化、透明化机制来降低了团队的理解成本，让研发人员和产品人员能够更好地对齐对需求的理解。分工我们希望需求尽可能细致，方便小步快跑、快速迭代试错。如何拆分需求？我们的做法首先是根据领域来划分，其次是根据业务流程拆解。接下来是根据紧急程度、实现难度、所属客户端和平台、用户价值、用户角色、团队当前情况等因素来拆分。拆分过程需要架构师或者主管对业务和商业模式有深入理解，才能和产品人
326、员很好地沟通和交流。162腾讯云技术实践精选集 2022第二个方法是领域驱动设计。有些需求可能非常大且复杂，很难拆解。领域驱动设计可以分层抽象、降低需求的耦合度、复杂度。以某政务系统为例，首先由业务人员对整体业务架构进行归纳和总结，生成业务架构图。接下来将业务架构转变成系统架构，最后切分成代码实现。这样的架构能够让每一位研发人员清晰认知自己在系统中处于哪个模块，以及模块之间的联动方式。领域拆分的代码实现方面，我们针对小型需求有一个小型的代码目录，没有非常复杂的代码设计。对于比较大型或者复杂的业务流程，我们有一个详细的 DDD 代码目录结构设计，这样可以让团队有规范可循，不论是简单架构还是复杂架
327、构都可以参考设计。总体来看，我们主要采用需求拆解和领域驱动这两个方式提高需求拆分、工作拆分的细致程度。交流分工协作是研发流程中非常容易产生浪费的环节。为了帮助大家顺畅和有效地沟通，我们主要有以下几个实践。主干开发，直接通过代码方式帮助研发人员对齐需求。我们主要围绕 Master 分支进行版本迭代，个人则通过特性分支持续开发，然后回到主干上。CR 过程也尽可能左移，避免很大的 CR。通过小规模的提交、主干开发和 CR 左移的实践，可以帮助我们把控代码质量，对齐对需求的理解。自动化测试也是不可或缺的，测试代码本身也需要 CR。如果有一些对不齐的问题，就通过当面交流或者会议及时对齐。163腾讯云技术
328、实践精选集 2022 APIOps，也就是通过 API 驱动后端和前端的代码设计和开发协作。APIOps 平台可以沉淀代码或接口协议的规范，并具备 Mock、抓包等能力，方便前后端联调和验证。这是前后端沟通过程中必不可少的工具。测试左移可以降低开发和测试人员的沟通成本。我们通过测试代码对齐测试和开发人员对功能的理解，并将 UT 和 IT 沉淀在代码库中。开发和测试人员可以通过代码协作对齐测试过程，提交代码后可以输出自动化测试报告，及时反馈给开发人员。GitOps 理念能够降低开发人员与工具的人机交互成本。我们通过 GitOps 管理研发流程，沉淀信息，通过 Git 回溯开发过程的变更，对变更进
329、行 CICD 和自动化测试。开发人员提交代码后，后续的过程都是自动的，并且整个过程产生的信息都是在 Git 上沉淀的。看板管理项目进展和风险。我们将每个需求的研发过程、进度、风险都在敏捷看板上同步，这样可以帮助我们和项目侧更好地对齐进度和风险。落地最后，如何切实有效地保障这些实践的落地？我们第一个理念是度量，要对整个研发过程有较好的度量指标。管理者可以通过度量指标掌握团队的单元测试情况、CI 延时等信息。我们尽量选取比较客观、明确、公正，不易作弊的指标，数量不宜过多。如果盲目选取指标，会对团队造成较大伤害。164腾讯云技术实践精选集 2022第二个实践是 ChatOps。以告警流程为例，告警出
330、来后会自动对服务拉一个群，在小群里同步告警的详细情况，在大群中公示每个告警的处理和解决的过程，在组长群度量每个组对告警的响应率、响应时间和解决情况，并且通过单据沉淀。其他领域也可以通过 ChatOps 方式推进研效工作落地。在企微群或发这些消息可以更方便团队接收，也起到了公示作用。总结总结来看，我们在理解层面有几种方式降低理解成本，在分工层面通过需求拆解、领域驱动设计进行科学分工，在交流层面通过几个实践降低交流成本，在落地层面通过度量和 ChatOps 帮助我们更好地落地。当然，研效提升的方法并不唯一，我们也会加强交流和探索，寻找更多有效的手段提升我们的研发效率。扫码获取完整版演讲 PPT16
331、5腾讯云技术实践精选集 2022中间件与基础设施04166腾讯云技术实践精选集 2022Kafka Stream 的进化探索：流式 Serverless 计算许文强腾讯高级工程师腾讯高级工程师，Apache Kafka Contributor。拥有多年分布式系统研发经验，主要负责腾讯云 Kafka 和 Datahub 的研发 和管理工作。专注于消息队列及其周边技术生态在公有云场景下的技术建设、分析、优化。随着 Kappa 架构流批一体在大数据领域兴起，万物互联引发数据源爆发，基于数据流的实时处理计算成为趋势，传统的分布式数据计算引擎如 Spark、Flink 也面临着数据量级和业务复杂度的双重
332、考验。业界的流批一体，也逐渐转变为统一到流。近年来，新的流计算形态不断涌现。在 Apache Kafka 的生态中，通常是通过原生的 Connector 来实现集群间的容灾、同步以及简单的数据转换处理能力。如果需要实现流式计算处理，则需借助 Flink、Spark 或者原生的 Kafka Stream 来编程实现。这在实际的使用运营过程中面临学习成本、运维投入、扩缩容等问题。新兴起的无服务器架构具有事件触发，多语言编程，弹性扩缩容，函数态运行等能力，为消息在容灾、同步、转换处理、流式计算等场景提供了一种新的技术选择。在 DIVE 2022 北京站上，腾讯高级工程师许文强带来了主题为Kafka
333、Stream 的进化探索：流式 Serverless 计算 的演讲，主要分享基于 Serverless 架构的消息的处理、流转的探索和实践经验。167腾讯云技术实践精选集 2022Kafka Stream 的机遇和挑战在大数据架构中，Kafka 是一个消息队列，扮演缓冲层的角色，起到削峰平谷缓冲的作用。Kafka 上下游分为数据接入和流出两部分，Kafka Stream 就是数据流出部分的技术方案之一。Kafka Stream 的主流方案分为计算、集成、处理和容灾四类，每一类都有一些主流方案和适用场景。Kafka 自带的流计算库 Kafka Stream 是社区推出一个库，功能和 Spark/Flink 类似，架构分为消费、处理、写入三部分。它的优点是部署、管理比较简单，和 Kafka 强绑定，但功能不够强大，应用不多。总结来看，当前方案面临的痛点主要包括使用成本和扩缩容能力两方面。使用成
sgpjbg002
工作日 8:30 - 17:30
报告分类
