您的浏览器禁用了JavaScript(一种计算机语言,用以实现您与网页的交互),请解除该禁用,或者联系我们。[腾讯]:腾讯云技术实践精选集2021 - 发现报告
当前位置:首页/其他报告/报告详情/

腾讯云技术实践精选集2021

2022-02-20腾讯华***
腾讯云技术实践精选集2021

1腾讯云技术实践精选集 2腾讯云技术实践精选集卷首语近年来,云计算、5G、人工智能、大数据等新一代信息技术发展势头迅猛,加速了各行各业的数字化转型,数字经济俨然成了产业发展的新风口。身处技术革新的浪潮下的企业,更应顺势而为,抓住时代机遇。一直以来,腾讯云坚持以卓越的科技能力打造丰富的行业解决方案,构建开放共赢的云端生态,推动产业互联网建设,助力各行各业实现数字化升级以及产业的降本增效。与此同时,腾讯云不仅在技术领域不断创新突破,取得了沉甸甸的收获,还将积累的成功经验向外部技术同仁赋能输出。回望 2021,来自腾讯云的技术专家分别在 QCon 全球软件开发大会、ArchSummit 全球架构师峰会、GMTC 全球大前端技术大会中,围绕“云原生技术应用”“数据库与存储技术”“前端业务架构”以及“架构设计”四个方面,分享了独到的技术见解与成功经验。《腾讯云技术实践精选集 2021》第一期将二十余位腾讯云讲师的演讲内容进行了收录,以期帮助更多中国互联网行业的同仁们学习腾讯云在技术演进、能力落地以及行业探索等方面的经验。展望 2022,腾讯云将持续输出更多的技术能力、沉淀更优质的技术内容,也期待与更多业界同仁一道推动产业升级,促进业务创新。 3腾讯云技术实践精选集推荐序数据库行业迄今已有数十载,而历久弥新。随着互联网行业及云计算、5G、人工智能等技术发展,多种类型的数据呈爆发式增长,各种创新业务场景层出不穷,冲击着这块古老而全新的软件领域,也促进了技术和产品架构的创新,使得中国数据库市场进入了百花齐放的阶段。 从我的从业经历来看,越来越复杂的业务场景对数据容量、并发量、实时性、数据分析、安全性、容错性、可信赖等方面提出了更高的要求。硬件发展和软硬件一体化优化技术,给数据库设计者和开发者提供了更多解决问题的思路。 腾讯云数据库构建了企业级分布式事务能力、云原生能力、超融合能力以及全球部署能力,在提供强大存储和计算能力的同时,简化了业务开发模型,在金融、游戏、 物联网等众多关键领域中,都取得了亮眼的成绩。本册电子书收录了与数据库相关文章,结合了腾讯云数据库的实践经验,向外界传递我们的前沿探索 / 技术实践,让更多业界同行从中获得有价值的见解。 腾讯云副总裁 林晓斌“生于云,长于云”,短短几年时间,云原生技术便从出现走向成熟,在企业的数字化转型中发挥着重要作用。与此同时,云原生技术所涵盖的范围也越来越广,从容器、微服务、DevOps 到 Serverless、大数据、AI,只要符合云原生理念的,我们都可以称为云原生技术。那么这些云原生技术演进背后的逻辑是什么? 究竟能够给企业带来什么价值呢? 我认为用 “降本增效”四个字可以涵盖。本册电子书的“云原生技术应用”部分将主要介绍如何利用云原生技术帮助企业实现“降本增效”。 腾讯云容器产品中心总经理 邹辉 4腾讯云技术实践精选集目录云原生技术应用数据库与存储技术PART 01PART 02Service Mesh 在游戏行业大规模落地实践解决万千节点可观测性数据压力腾讯内部实践正本清源,你真的了解 Serverless 吗?百万级大规模容器平台的设计与实践腾讯云 Serverless 在音视频处理的探索与实践腾讯 Kubernetes 大规模离在线混部与内核隔离实践腾讯百万级容器规模的云原生平台设计与实践1000+ 企业云原生改造成本优化总结破解 Kubernetes 应用开发低效之困 : 一键调试,实时热加载腾讯大规模云原生平台稳定性实践Kubernetes 环境下极致开发体验 - 实时热加载和一键调试云原生 Serverless 数据库的设计与实践企业级分布式数据库 TDSQL 元数据管控与集群调度TDSQL-C PostgreSQL 在云原生架构下的新活力“缓存 + 存储”架构下 Redis 持久化的探索与实践云原生数据库的“能与不能”腾讯云存储数据湖三层加速1.2.3.4.5.6.7.8.9.1.2.3.4.5.6.071723303843526370779098106122128133138CONTENTS10.11. 5腾讯云技术实践精选集前端业务架构架构设计PART 03PART 04TRTC Web SDK 新架构设计解析云剪辑实时渲染引擎设计音视频跨平台应用与元宇宙未来畅想Serverless 时代的低代码实践十亿级 Node.js 网关的架构设计与工程实践云原生微服务治理架构深度解读和实践腾讯云亿级 QPS 弹性负载均衡系统演进1.2.3.4.1.2.3.146155164170179189197 6腾讯云技术实践精选集云原生技术应用PART 01 7腾讯云技术实践精选集近几年,云原生工具和技术应用持续增长,容器的使用和编排愈加流行,Serverless(无服务器)、Service Mesh(服务网格)等技术兴起。在大规模服务网格性能提升的需求面前,其过程中的探索价值凸显。在游戏行业的上云过程中,腾讯积累了深厚的经验,也探索出了自己的路。在 2021 年 Qcon 全球软件开发大会【北京站】中,腾讯云高级工程师钟华带来了主题为《Service Mesh 在游戏行业大规模落地实践》的演讲,分享了腾讯云在这一领域的成功案例与最佳实践。Service Mesh 在游戏行业大规模落地实践钟华 腾讯云高级工程师Istio contributor,Dapr contributor, Tencent Cloud Mesh 技术负责人。专注于容器和服务网格,腾讯服务网格 Oteam PMC,在容器化和服务网格生产落地和性能调优方面具有丰富经验。发展趋势与挑战据 CNCF 发布的 2020 年服务网格发展趋势报告显示,在 1300 多家 IT 企业中,生产环境里使用 Mesh 技术的比例为 27%,较上一年(2019 年)提升了 50%,预计未来还会持续增长;而所有的 Mesh 技术栈中,Istio 的使用比率最高。 8腾讯云技术实践精选集数据面的统计数据中,2020 年在生产环境中使用了 sevice porxy 的比例大概是 37%,其中前两名是 Nginx 和 Envoy,分别是 62% 和 37%,值得关注的是, Envoy 的增长率达到了 116%:为了获得更强的七层流量管控能力,一部分用户会从老牌的 proxy 迁移到 Envoy ,比如 Nginx 和 HAProxy。这份报告中体现了两个主要的信息:一,服务网格生产落地持续增长;二,在技术选型方面,Istio 和 Envoy 还是主流的选择。但这份报告没有体现规模化体验方面的内容,比如,使用这些 Mesh 的用户规模如何? 实际上,在我们接触的 Istio 用户中,中小规模占了很大比重,这并不表明 Istio 大规模落地没有需求,而是其需求更复杂、要求更严苛。我们在大规模落地过程中遇到的问题,包括性能开销、场景限制、复杂度。其中最难的是性能开销,在给腾讯大规模的游戏客户做服务网格支持的时候,体会更深。大规模服务网格性能优化游戏服务本质上是互联网的产物或者互联网的组成部分,所以它有互联网服务的一些共性。比如,它们都是分布式环境,要求高可用,强调分离基础能力,有很多微服务等等。同时也有行业自身的特点,比如会产生更多有状态的服务。由于游戏体验强调实时性和强交互,所以对延迟更敏感,稳定性要求更高。比如, Web 程序通常是读多写少,CPU 通常还好,但 IO 很密集;而游戏的读写都很频繁,CPU 和 IO 都非常密集。此外,游戏中的大量差异化玩法,在微服务方面则体现为更多的版本。1. 利用 BPF 技术优化数据面转发链路优化为了提高性能,我们做的第一个优化是利用 BPF 技术优化数据面转发链路优化。 首先,相比于服务直接通信,Istio 数据面的通信模型在引入 Sidecar 模型后,通信路径明显增加,具体来说,每个被劫持的报文会多经过 2 次协议栈,多 2 次数据拷贝。根据测试,这个架构在内核态的开销,大概占总开销的 30% 左右。 9腾讯云技术实践精选集BPF 的全称是伯克利包过滤器,它在内核中已经存在很多年,是一个高效的虚拟机,它能以安全的方式在很多 hook 点执行我们提供的字节码。这里的核心工作是在 Socket ops 挂载我们的 eBPF 程序,拦截应用程序和 Envoy 之间的流量,直接发给对端的 Socket,这样就跳过了后续的内核协议栈处理。业界对这个问题的一些探索:业务进程和 proxy 之间使用 UDS 通信,数据包不会经过协议栈。但是 UDS 的缺点是对代码有入侵,需要用户显示面向 UDS 编程,这种做法常见于一些私有的 Mesh 方案,不适合公有云的场景。我们的方案是利用 BPF 来跳过协议栈的处理。 10腾讯云技术实践精选集在具体流程中,我们要关注连接创建和数据发送。当监听到连接创建事件后,程序把两端的 Socket 信息存到 Socket hash 中,这是一个高效的 KV 存储,Key 包括源和目的的四元组,Value 是 Socket 对象。当监听到消息发送的事件时,可以从当前的 Socket 信息中,分析出目的端的缓存 Key,利用这个缓存 Key,再去 Socket hash 取到对端的 Socket 对象。这样就实现了源和目的两端都跳过了后续协议栈的目的。这样操作的优化效果也比较明显:吞吐量提升了约 7.4%,延迟 p90 降低 15.6%,延迟 p99 降低 27%,基本符合我们的优化预期。2.xDS Lazy Loading第二个主要是优化 Istiod 设计的缺陷—— xDS 全量下发,带来的性能瓶颈。目前,Istiod 下发 xDS 的机制是全量下发,以左图为例,Workload1 虽然只依赖 Service2,但它的内存里会始终加载 Service2、Service3、Service4,因为 Istiod 会把所有数据都发给 Workload1。这会导致 Workload1 中的内存急剧膨胀,同时还要花大量的 CPU 去解析这些 xDS。另外, HPA 也会受到影响,Kubernetes HPA 通常是 Pod 维度,如果 Sidecar 里内存已经很高了,业务容器的内存可能就无足轻重了,HPA 基本就失效了,这会导致系统稳定性比较差。当 Mesh 的规模增长以后,内存开销上升地非常明显。 11腾讯云技术实践精选集具体流程是,一开始限制所有服务的可见性, Workload1 不加载任何服务,有任何请求都会拦截到 Lazy Egress(类似网络里的默认网关)去,Lazy xDS Egress 会分析流量的特征,然后把流量转发到下一跳中,紧接着在 Egress 会把这次访问关系,以 Access Log Service 形式上报到 Lazy-xDS-Controller 中,由 Controller 分析服务依赖关系,并将其以 CRD 的形式写到 Mesh 。Istiod 更新了这些服务依赖以后,后续就会把 Service 2 的信息下发给 Workload 1, 后续 Workload 1 再次访问 Service 2 就是直连的。 对此,我们也做了对比测试:在一个 Kubernetes 运行两个 BookInfo,左边开启 xDS 懒加载,右边不开启,频繁下发一些它不需要访问的服务。最终的优化结果是 900 Pods 规模 Mesh,单个 Envoy 减少 14M 内存;10 万 Pods 规模 Mesh,单个 Envoy 内存降低约 1.5G,优化效果