Techo Day 云原生全栈开发与实践原创

类的主题为云原生全站开发与实践，旨在呈现腾讯更底层的云原生理念、成果、全站开发能力及最佳案例实践。本次活动涉及的层面广泛，可谓是干货满满。那么下面让我们进入今天直播的第一个环节，有请腾讯云副总裁刘颖先生进行主题致辞。各位开发者好，欢迎大家来到第二期Taco day腾讯技术开放日，我是来自腾讯云的刘颖，这期Taco day我们聚焦云原生全站开发与实践。生云云长于云，近几年随着企业上云进程的加快，云原生技术也在快速的发展中，一方面云原生技术能够帮助企业提高应用的开发。发布的速度，让企业能够在激烈的市场竞争中满足用户越来越高的期望。另外一方面，云原生技术具备极致的资源伸缩的能力，能够极大的发挥云的优势，让企业在新场景下能够灵活应对架构越来越复杂、资源越来越多、稳定性要求越来越高的挑战。

正是因为这些优势，云原生技术得以快速普及，并逐渐成为行业数字化转型的新底座、产业发展的新引擎。据嘎塔的预测，到2025年，云原生平台将成为95%以上的新数字化计划的基础，而2021年这个比例不到40%。未来几年，国内云原生技术仍然具备非常大的潜力和增速。腾讯是云原生技术的坚定拥护者，也是最早布局云原生业务的厂商之一。早在2015年容器和K8S刚出现的时候，腾讯内部就像这些技术引入到了实际的业务当中，其中最典型的场景有两个。第一个是离线计算平台，我们基于多可构建的一个离线任务平台，多可的可移植性让不同的底层异构的资源能够加入到离线的算力集群里面，通过多可的隔离性，让更多的细腻度的任务可以跑在同一台机器上，提高的利用率。

第二个是游戏的场景，游戏的业务有一个特点，上线刚开始的时候如果很火爆，可能会有大量的扩容的操作，运行一段时间之后，如果效果不及预期，可能会频繁的和糊。而K8S获得了快速启停、动态升降配的能力，非常符合这个场景。于是我们将K8S引入运行了很多游戏的业务。早期经过这一系列腾讯内部的业务的试点，腾讯云在这里积累非常成熟，之后我们逐步将云原生的技术放到腾讯云对外的服务中。同时进一步的在腾讯自研的业务中全量推进了云原生技术的升级换代。到目前为止，腾讯已经具备非常完整的云原生技术和产品的体系，涵盖了软件的研发的流程、计算的资源框架、数据处理和存储安全等五大领域的多个场景，拥有业界最大规模的云原生实践。

在内部，今年腾讯完成了自研业务的全面上云上云的底座就是基于腾讯云上的云原生技术。我们通过t ke k8S的技术，将腾讯内部数千万核心的资源拉通到一个大的资源持续调度和管理，在提高资源利用率的同时，也进一步的通过在离线混播的技术，使整个利用率从30%提升了65%，除了容器之外。云上的微服务和de技术也进一步的打造了统一的开发框架和营销的平台，极大的提升了业务的开发和运维的效率。腾讯会议呢就是一个非常典型的例子，从诞生的第一天起，基于云的腾讯会议技术架构便注定了基于云原生，作为一款SS应用，凭借着生育云、长育云的弹性的、扩容的能力，上线仅一年，用户数突破了一个亿，成为了中国人数最多的视频会议应用，今年秋季开学。

进一步对腾讯会议和云原生的一次大考。开学期间，腾讯会议的同时在线人数增长了五倍，其后台模块的容量和消耗也突破了100万盒，而这一切资源的准备、服务的伸缩都是在一个晚上完成的。在云原生的技术出现之前，这是非常难以想象的。除了会议之外，腾讯内内部包括QQ、微信支付、王者荣耀广告这些核心业务都跑在了云原生的基础上。腾讯丰富的业务场景和复杂的业务形态，让腾讯云原生在上云的过程中积累了丰富的实践的经验，在服务内部业务的同时。我们也把这些技术的积累以标准产品的方式进一步的放到腾讯云上，对外部客户进行输出。

在去年，我们基于腾讯内部超大规模分布式云的研发和落地的技术成果，发布了腾讯云原生操作系统熬持，该系统是目前业界唯一一个支持服务器容器函数混合调度的原生操作系统。单集群就是10万级服务器，百万级容器规模管理的CPU的核数超过了一个亿，为用户提供了高度标准化的海量的算力，以最贴合用户便利的方式让算力触手可及。在今年，我们基于腾讯内部业务成本优化的实践，推出了国内首个云原生技术的成本优化开源项目Korea Korea是基于分窝S理念的成本管理工具，从资源成本的洞察到利用率的提升以及持续的资源运营，提供了一整套优化工具，帮助数据中心提升服务器资源利用率。

随着腾讯云原生产品和技术的完善和成熟。越来越多的开发者和企业基于腾讯云的云原生应用构建它自身的应用。到目前为止，腾讯云原生产品所服务的外部开发者数量已经达到了300万，拥有国内最大的云开发小程序生态和开发者平台的工具，所服务的企业客户呢超过了5万，应用于金融、政务、教育、能源、交通等等多个行业的客户。小红书就是一个非常典型的例子。目前小红书80%的业务都是基于t ke容器部署，其中AI训练和推荐的场景的技术全站使用的容器化，总体的成本降低了40%，实现了稳定、灵活、低成本的底层基础设施的建设。在企业落地云原生技术的过程中，我们也看到了一些新的机会，例如云原生技术和分布式云的结合，让企业能够更好的随时随地的使用云计算。云原生技术与具体开发场景的融合演进，更进一步的提升了特定场景的开发的效率。

腾讯也将持续投入到云原生技术的研究和探索，推动云原生技术在企业的落地，为企业数字化改革做出贡献，谢谢大家。非常感谢腾讯云副总裁刘颖先生的致辞，下面让我们进入第二个环节，架构与原理专场的分享。第一位分享的嘉宾是腾讯云计算高级产品经理贾卷，为我们带来熬持分布式云操作系统如何实现任意位置皆可高效运营的主题分享，有请贾卷老师。诶好大家好，呃，首先自我介绍一下啊，那么我是来自于腾讯云的，讲，那么我在腾讯云的工作啊，其实是负责那个云产品的整个研发和落地工作，那么我自己呢，那么其实也是一个有十年经验一个开发者。

那么今天和各位嘉宾还有开发者分享的一个主题，啊啊是我们的分布式语音操作系统，那么以及如何实现任意位置的一个高效的用语。那么熬驰呢，其实我们在二一年发布的一个云操作系统的品牌，当然它背后呢，其实已经是我们腾讯云啊，整个呃，内部十年以及20年的这样一个技术的积累。那么下面呢，其实我就正式和大家介绍一下他吧，那么以及他能够可以给我们的各位开发者以及我们的创新企业可以带来一些什么帮助？那么首先想和大家分享一下，那么其实就是我们的云操作系统，还有对分布式云的理解，因为这两个概念啊，其实虽然我们可能会听，平时会听到过一些，但是很少有人会把它很具体的会把它介绍出来。那么其实我可以分享一下我的理解，那么第一点就是关于云操作系统的概念啊，其实它是来自于计算机的这个操作系统。那么它虽然形态和计算机的操作系统不太一样，但是其实它本质上是一致的。

我们其实可以看到图上面我可以看到1946年我们第一台计算机，它是非常庞大的，那么它是需要非常专业的演员才可以使用。那么但是我们随着我们像我们的操作系统当时，那么其实我们现在任何一个普通人都可以非常熟练的去使用我们的计算机。那么云操作系统其实也是同样的，那么它对内呢，它管理了非常众多的一些复杂的项目的设备模块。比如像我们的基础网络，还有我们的数据中心，还有我们的服务器虚拟化这些技术等等。那么对客户呢，其实我们提供了非常简单用的我们的控制台，还有API。啊，那么分布式语又是什么呢？那么可以参考下面我们一些像调研机构的一个介绍。那么以前的云啊，我们可以认为它都是中性化的。那么比如我们会在我们的北上广深这样的超一线城市，我们会建设我们一个比较大型的云数据中心，然后客户来上云。那么分布式云呢，其实是将这个习惯反过来了，那么不再是客户去上云，而是云向客户去做靠近。

那么为什么需要这样一个形态呢？那么其实是和我们的社会啊，还有技术发展是有关系的。那么这几年一个非常重要的趋势啊，其实就是我们所讲到的产业互联网以及数字化经济的发展。那么其实对于开发者还有创新者其而言，我认为其实这是一个非常好的机遇，因为我们有非常多的领域可以实现我们的技术。那我们的技术我还有我们代可仅仅一个网是。那么随着我们像数十种合的这样的深入啊，那么我们的代码可能直接控制一个工厂运作，那么也能去管理我们成千上万个交通设备。那么以下几个方向，其实就是数十种合理、非常典型的场景。那么第一个比如就是我们的智能制造，那么现在工厂的智能化的程度是越来越高，那么比如我们借助像AILT这样的技术，我们可以实现那种机械的自动化管理，那么为工厂实现降本增效。那么第二个其实就是我们的智能驾驶技术，那么现在其实智能驾驶已经不能说是一个新型事物了。

我们其实很多人自己买的车里面都具备一定层级的，我们叫自动驾驶或者辅助驾驶能力，那么在很多的城市啊，我们的无人巴士，无人物流车其实已经在路上开了。那么另外就是在我们的城市啊，还有企业的管理领域啊，像我们的数字化信息化的程度是越来越高。那么在这各种各样的我们叫政务APP，我们企业的SaaS化应用或者应用APP之后，那么以及还有我们前面提到的，在智能制造，智能驾驶里面，我们的智能这些应用，那么其实背后呢，都是我们开发者的代码在做支撑。但这些机遇，非常好的机遇啊，其实背后往往都是跟随了一些挑战的。那么当我们的开发者的应用的服务场景，我们从网站、APP，我们现在变成了我们的实体世界。那么，新的挑战其实就要来临了。那么首先其实就是复杂性的增长，那么以前我们服务我们叫C端客户的时候，我们其实像我们的很多企业而言，我们只需要在一个压线城市或者云厂商，我们上去购买一些服务，基本上我们就能满足周边用户的一个诉求了。

那么现在我们应用要部署的位置啊，那么不再仅仅是种中心区域，我们下沉到各个边缘，甚至是本地的位置。比如你有可能是一个三线城市的IDC，这里可能他没原来是没有云的，有可能是一个工厂的机房，那更加不可能有人帮你提前做好这样的基础设施建设。那么其实我给举个例子，在我们腾讯有一个智慧农业的项目，我们在沙漠里面去做那个沙漠，沙漠的绿色化。那么我们甚至在沙漠的中间，我们去部署了我们这样一个算力节点。那么这些基础创立这些问题啊，其实对一般的开发者，还有创新企业而言啊，其实是存在很大的挑战的，比如我们在写好自身的代码之外啊，那么整个你的基础设施，你要如何去做管理，如何去做运维，还有你的成本如何去控制。那么这会占据我们的，呃，我们开发者，还有我们的企业的一些人员的非常大的精力。那么另外一点就是啊，那么随着我们的研发，技术也是不断的在发展的。

那么我们对双利的需求其实也越来越丰富。那么原来呢，我们可能比如我们说你这有一个我们叫英特尔的可能CPU或者是什么可能满足需求了，那么现在我们比如我们可能会有一些GPU的需求。我们甚至还有我们算力形态上面，我们以前可能是比以虚拟机为主，那么现在呢，可能像我们容器像像低代码，那么这样的新型算力呢，其实我们如何去在我们需要的位置上能获取到，其实也成为了一个非常大的挑战。那么分布式的诞生呢？其实就是为了解决这个问题。那么，分布式云具备哪些特征呢？那么首先是啊，全域覆盖，那么其实无论是我们在云端，还是我们的二三线池城市这样的边缘端，以及客户的生产线上，乃至于极端边缘，我们都要能够提供我们这样的一个的覆盖。那么其次的特点呢，就是要统一同构，那么统一同构也就是说我们的分布式云啊，在我们刚才讲的不同位置是提供符的时候，首先你整个的里面的东西，你不可能是不需要，不能差异化太大，那么你需要提供一个统一架构，那么一次体验的服务。

那么也就是你无论是云产品的种类啊，那么还是功能来性能，以及还有我们客户使用的时候，我们的API控制台你最好是完全一致的，那么这样的优点是什么呢？优点就是我们的最大程度的减少我们的开发者去适配不同环境的一个工作量。那么最后一点就是啊，这个分布型需要具备跨环境，多算力类型的这样的调度能力，我们针对的不同针对因为我们在现实中啊，我们往往会对非常复杂的一个硬件环境，甚至至于我们整个我们要基于这样云平台，可能是不懂云的商的，甚至是你有可能都不是云厂商，你还有传统的一些啊虚拟化的平台。那么这个你有可能是无法去统一的场景，那么这时候呢，我们就要去分布式云，就能提供一个叫分布式云延伸的能力，可以去管理这样复杂的环景，那么你在硬件层，甚至呢，至于你的S层，可能你是不同意的，但是我最终可以在应用层。

用的管理上实现一个统一调度。那么正是基于刚才讲的这三个特征以及这样的理念，那么我们就推出了分布式操作系统。那么熬持呢，其实整合了我们整个腾讯云的一个技术和产品体系，那么可通过更一个更深层次的调度和整合，那么将腾讯云的我们不论是技术架构还是产品理念进行整合。我们打造了一个可以让云可以无处不在服务的技术和产品体系。那么可以让用户可以可以随时随地的去构建它的原生应用。那么它具有以下四个特点，那么是开源创新，那么全域治理，那么无限算力以及触手可及。那么技术保持啊，我们将腾讯云以及腾讯20多年的一个技术，还有产品能力的积累，那么可以提供到任意用户想需要的位置，并且我们是保证了统一一致的使用体验以及管理体验。

那么下面呢，我可能再介绍两个具体的啊，由熬熬持我们打造的腾讯云的产品体系类的产品，那么也让他感受一下，就是陶持真正的在现实中我们是怎么去落地，怎么去帮助我们的客户减少去减少他的。在基础上是以及这样的上的精力开销的啊，那么第一个呢，其实就是我们叫本地专用集群CDC，或们叫边缘可用区TC这样的两个产品，其实这两个产品特点的都是可以我们可以延展到客户的地以及边缘。那么他们的区别可能就是啊，一个它是面对于我们叫共享场景，也就是它我们在这里建设了一个叫我们的边缘可用区之后，很多客户都可以来这个边缘可以区上面去申请我们的云算案例，那而CC呢，这产品它是一个专属化的，因为比如像在客户的工厂里面，像客户的医院里面，我们要介绍一个云节点，那么这个云节点它本身啊，肯定不会是一个共享化的，他一定是个客户专属的，因为客户他首先他本身有一些安全的需求，一些数据敏感的需求。

那么这两个产品啊，他们其实共同的特点就是都可以向任意位置去延伸，比如我们刚才讲到的啊，我们可以在客户生产现场，比如客户的工厂，还有医院。那么还有学校，比如我们可以提供一个一到两个机柜的小型的边缘运营的形态，那么客客户，比如像一些呃，医院的his系统，像工厂的，我们像长线上at，还有一些我们的可能有一些简单的一些，比如说的啊训练我们都可以在这样的一到两个几位上，我们就可以满足客户的需求。那么呃，当当客户，我们的客户的一些，比如像集团总部，或者是一些大型的办公点，或者是大大一些一些需要或者是他们的业务研发中心这种地点，他们有可能需要更大规模的算力，那么比如在这，然后在这里呢，我们就可以提供一个十个亿十个机柜，100个机柜，乃至1000个机位以上的规模，那么我们都是通过像熬驰这个技术那个来打造我们的这个整个体系的，所以客户无论在刚才想到我们在工厂，还是把我们的啊这些办公地点，还是我们的研发中心，他们面对使用的云都是一样的，只是他们我们能提供的给到的规模不一样，客户也可以最大性啊程度的来享受这个弹性敏捷的优势。

好，那么其实这两款产品啊，我们的本地专用集群和边缘区，它都是我们由腾讯云提供软硬一体的全站云服务，这是，那么其实它是融合了我们叫公有云以及传统叫私有化的一种双重的优势，那么它既有公有云的这种项丰富服务，像我们极资的一个性价比以及低运维门槛这样一个体验。那么呢，同时呢，还还他还具备私有化的一个，我们叫任意IDC部署，因为我们刚才讲到了，你可以在你的工厂部署，也可以在医院，你可以在学校，然后你的总，你在企业总部哪些研发中心，你都可以采用相同的我们这同一套技术去完成我们的基础算力的部署。那么还有另外就是你采用这种呃，你的工厂这些部署的时候，我们可以提供一个完全安全，完全独立专属化的特性，那么可以满足我们像丰富的，像企业，就像刚才讲的生产线上云，像企业内部云以及行业地域云这样的丰富的诉求。

好，那么刚才我们讲到是有腾讯云提供的软硬一体的叫全站云服务的这样一个特点，我们前面其实也提到一个点，就是你在面对一些企业的或者是面你的客户，你看发的要去面对你的客户的时候，你的环境可能是他已经有，他基础设施已经不好了，他很很他很难说我现在花钱再去给你买一套新的，那么这个时候呢，我们就要需要能我们的啊分式去适应他的硬件以及套的云平台，那么这时候我们来选择的产品就是我们叫分布式云原生这样的一款产品。那么我们不仅仅可以提供软硬体化的，那么也可以在我们叫多元化环境位置，在那个上面提供我们的分布式原生管理服务。那么比如其实这个例子啊，是我们在现实中的一个例子，那么这是一家大型的光模化的生产的制造企业，那么其实它就是有非常多的一些历史的原因，它在它的云端，它的都采用了不同的方案，甚至是技术架构。

那么其实你分散在不同的位置，以及不同云上面的应用，那么怎样去进行一个高效的管理呢？其实就成为了客户的非常的一个大的难题。那么他就记住了，我们像分布式云T这产品啊，它可以将我们原有云边端上面的我们叫K8应用，K8集群以及应用可以进行款，它原来如果没有这种八，我们还提供T的一个可以帮助你在可以的一个们叫腾讯的T过T。那么这样就解决了客户原有的一个难题，那么实现了帮助他实现了一个我们叫多元化环境的开发管。么整个拉广，我们所有的容器集群都可以通过统一的控制来管理，那么客户他发布还有管理应用啊，他不但需要面向我们复杂的环境，比如你不同的云平台，不同的位置都不需要了，只需要我们T这面向就可以随时随地行们应用的运布。

那么最后呢，也分享一下我们基于熬分布式云的一个愿景。那么我们是希望通过熬瓷分布式云操作系统，这样，以及基于我们这个熬瓷来打造的整个产品体系啊，帮助我们广大的开发者，还有创新企业，那么只需要去聚焦于自身的像产品啊，还有他技术的打磨。那么无论是比如我们右边的三个场景，无论是你一个选位置，双力覆盖的需求。那么比如你的中心边缘本地对吧，乃至于还有一些，比如你有一些专有合规的环境的需求，比如有些你在工厂里面我敏感的客户，那个患者的数据。还有我们像工厂里面，我们像我们在苹果的，我们几乎就一些苹果供应链的工厂的客户啊，苹果甚至跟他们是有签那种合约的，他们是不能随便里面的东西，任何数据都不能泄露，泄露会有非常严重的罚款，那么在这样一个专有合规的环境，我们怎么去提供我们一个技术算力？

乃至于我们下面讲到的，我们一个跨环境多算力的环境上面，我们怎么去进行云生管理这三个三个方向，那么都可以借助通过我们的熬，以及做过熬打造的产品体系来解决。那么我们的目的就是帮助我们的开发者可以实现它的应用的一次性构建，可以在任意的位置，在任意的形式可以进行运行，那么我们通过让云的数班帮助我们的开发者，还有我们的创新企业，让他们创新可以无处不在，那么这就是我们做豪车这样的一个愿景。那么最后还有一个呃材料可以给大家分享介绍一下，就是大家如果是对分布式云这块有兴趣的话，那么我介绍一个材料给大家阅读一下，那么这个是由腾讯云联合信通院共同发布的一个分布式云发展白皮书，也是今年刚发布的，那么它是国内首个在分布式云为主题的一个白皮书。那么其实也是国内首次从趋势、标准乃至到我们整个技术发展以及实践的一个全方位的解读。

那么里面呢，其实有非常丰富的一些行业的真实案例，也可以供大家去参考复制，那么大家可以通过扫码获取，但也可以回去搜索，这个说明这个现在目前的下载量应该都有应该好几万次了，在网上面。好，那么我今天整个的关于我们的石，呃，分布式操作系统，以及他能怎么帮助我们的呃，开发者企业去降低它的运用成本以及it建设成本，那么分享到此为止了，也非常感谢大家的收听和观看。非常感谢贾娟老师带来的精彩分享，接下来由腾讯云监控高级工程师夏浩明给我们带来普罗米修斯云原生监控实践的主题分享，有请夏浩明老师。大家好，我是夏浩明，腾讯云工程师，目前主要负责腾讯云普罗米修斯相关的开发工作。本次分享给大家的呃，是腾讯云普罗米修斯在云原生监控上的一些实践。

嗯，本次我分享主要是三个方面，首先是呃，特点与架构，然后是应用与场景，最后是总结与展望tmp，这里是腾讯云普罗米修斯的英文的缩写。首先是特点与架构。这里是普罗米修斯目前，嗯，目前最新版的一个原生的一个架构，嗯，它在采集方面是一个破模型，再加上一些push get的一些呃，采集组件，存储上面是普罗米修斯字研的呃，一个TSDB，告警方面是采用的manager，查询方面是提供了一个叫普罗米Q的一个查询语言，以及提供一些例如普罗米修斯web UI以及国发的一些作为推荐的查询组件。然后普罗米修斯它原生的问题主要是因为成本较高，首先是一个采集的一个可扩奖问题，官方推荐的通过哈希莫的一个呃扩容方式是对用户的配置，侵入性是非常高的，它需要用户对每一个采集嗯任务的莱里面都去添加对应的哈是Mo的，是有严重的侵入，并且呃破模型它是没有办法去知到啊，需要采集的一个target给的规模的，嗯对嗯，千万级别service的一个采集来说，会有严重的热点问题，比如说库常见的K场景下的采集。

嗯，第二点是存储扩展方面，嗯，原生普罗米修斯是一个单机的一个模型，那么用户使用的时候需要提前根据指标数量，存储时长去提前预估，嗯嗯，存储的规模，那么同同时单机由于受限于机器内存，嗯，如果需要扩容的话，需要先停机，恢复的时候就需要进行普罗米修斯叫做预写日志重放的一个流程，这个重放流程时间是比较长，不可控的，那么会导致普罗米修斯的一个可用性有造成严重的一个损失。嗯，第三点是可视化啊，国发纳是作为普罗米修斯官方推荐的一个可视化组件的，嗯，那么在云上运维这个广泛，那需要考虑到数据库，域名证书等等，以及开放到公网的一个网络和安全上的一些问题。

嗯，腾讯云普罗米修斯监控无服务是我们腾讯云基于开源的普罗米修斯构建的高可用的一个监控服务，它高度集成容器服务K1嗯，并且兼容开源生态丰富多样的应用组件，能够为用户提供嗯高效免维的一个呃监控服务，它具有开箱即用、低成本以及可扩展性强和主动运维等特点。接下来我简单介绍一下T的一个架，首先是采集存储分离。采集方面我们采用了一个的va方案，这个方案它兼容了开源灯普米斯的一个源的方式，并且能够的去支持采任务的任意的横向扩扩展，去满足千万级别一个采集的一个需求。存储方面我们是做了一个集群化多副本的一个存储，并且对普罗米修斯原生的TS化，例如在索引，索引盘以及日志重放速上面。

可视化方面，我们孵化了腾讯云官方的托管服务，并且这个服务是与官方的lab官方合作开发的一个服务，它提供深度集成普罗米修斯的功能。采集方面我简单介绍一下K的这个方案是腾讯云开源的一个轻量级的普罗米修斯的横向扩缩方案，它是将服务发现与采集过程分离，然后并且将嗯，采集到的一个target，呃，动态的去给分配给每一个采集下的来生成动态的一个配置，来达到无侵入式的去支持普米修斯横向扩松的一个方案，并且去支持自动负载均衡。

这个图是kVA目前的一个整个的一个架构图，这里的里面的每一个下的都是一个原生的一个普罗米修斯的一个采集器，嗯，上面多出来的这个K的就是kVA这个方案的核心所在，它是通过提前去呃抓取呃用户配置里面的所配的那些target，然后去提前获得需要采集的一个target的一个service的一个规模啊，然后通过计算嗯，把它均匀的分配到不同的下的中间，达到一个横向扩速溶的一个效果。呃，这里再继续介绍一下瓦斯的内特的这一个具体的一个方案，呃，普米修斯它采集的一个呃流程主要是分成四步啊，首先是进行一个服务发现，比如K8S的服务发现，或者通过文件呃static的一个服务发现啊，然后呃通过这个服务发现这个方式去获得需要采集的一个呃目标地址以及端口等等。然后第二步是进行一个reliable啊，这个reliable是来控制呃是否需要修改一些原信息的，比如说呃，像K8S最常见的将嗯需要嗯抓取的一个目标的地址进行一个替换。

第三步就是去真实的进行一个抓取，第四步是进行一个叫magicric的一个步骤，这个步骤是将抓取到的嗯，抓取到的一些sample给他进行一些比如，比如说就是修改target啊，或者说啊，给他添加新的一些library。嗯，Coord所做的事情就是将这四步的采集当中的前三步给它单独提取到coor这个呃当中去，提前去获取到需要采集的一个规模，并且在一个协调周期内，诶，去将这所有的一个它给进行一个计算，然后均匀的分配到每一个采集下的当中，并且在有需要的时候对下的进行扩缩容，以及说就是如果有些target它是出现了热点情况，那么需要在下的之间进行一个迁移，它也会，他也会在一个协调周期里面去对它进行一个协调。

嗯，接着是存储方面的一个架构，目前我们腾讯云普罗米修斯是一个多租户的一个多集群多副本的一个存储架构啊，首先看这个架构图，呃，它在红色的这条线是存储写入路径，它首先达到到达我们的一个呃，Tenant getway的一个网关，然后会往tribu里面进行一个写入，然后tribu会压缩传输给in，然后这里面是的普修最近两个小时的数据放到内存中，如果超过两个小时的话，那么把它数据上传到cos做一个归档，嗯，接着是黄色这条线是一个查询的一个流程，嗯，首先到达我们的呃，查询的前端，然后这个查询前端会去做一些优化，例如说比如说我们查七天的数据的话啊，那么他会把这个七天会去按天去做并发，然后把任务分配给我们的worker啊，然后worker会去。

嗯，查进行一个真实的查询，如果它的数据是在两个小时内以内是在内存中，是就直接向in去发起请求，如果它是超过了两个小时，那么啊嗯去往cos进行一个历史数据的一个查询。除了这个存储架构之外，呃我们对普罗米修斯的原生的TSDB也做了一些深入的优化，首先是内存占用上的优化，我们对普米修斯的一个呃内存的里面的索数据做了一个落盘的处理，来大大幅度的减少普罗米修斯的一个内存占用。其次在浴水日志重放的时候也做了一些优化，首先是开启了呃下呃snap下这个功能是普罗米修斯现在原生提供的一个呃实验性质的一个功能，它的作用是在普罗米修斯重启的时候，首先将内存里的数据做一个快照并行，并且压缩存储在呃磁盘上，这样在重启的时候就可以直接去读这个呃呃快照呃，但是它在有一个问题是它在就是比如比如说就是。

异常重启的部分，或者说呃呃，或者说它的数据特别大，那么它的snap会诶会不可用啊，这个时候它会重新重新到预写日志重放这个流程，那么我们对写日志重放这个流程也做了一些深度的优化。嗯，预写日志重放比较慢的，它最主要的原因是因为他在里面为了去解决一个呃，为了去解决一个risk condition的一个问题，那么他在里面做了一个go里面的的一个阻塞，就是他会在那里去等待呃，每一个呃check point去每个check就是完全完了之后才会进行到下一步切check，然后开源社其对这个也有一些。比如PR10859这个优化是对这个预写日志重放的一个呃阻塞的从从一次一一毫秒给它修改成一秒，然后第二个pir是对这个做了一个按需的一个阻塞，就是只在切point计算，通过计算它有效之后，它才会去进行阻塞，然后我们重新设计了一下这里的一个并发流程，然后将这里面的一个阻塞完全去除了，然后这个PI是已经在今年。

嗯，今年嗯，就是这个月的10月5号，就是合并到普罗米修斯官方代码，并跟随2.39版本已经嗯发布，然后它的效果目前是预写日志重放的加速，有20%-50%的一个效果，效果是比较显著的。第三点是呃我们提供了一个官方的托管服务啊，来解决普罗米修斯查询方面的呃需求，首先这个服务它是呃云的一个点，然后使用EKIC解决部署在用户VPC里面的成本的问题。嗯第二点是它会比较安全，因为它是直接部署在用户VPC内，那么它可以利用VPC的一些安全能力，比如安全组或者AC来保证这个实例的呃安全性，那么如果用户他需要呃提供公网访问的话，我们也提供公网域名以及证书来保证，还有IP白名单来保证用户公网访问的安全。当然我们绝大部分用户是选择是说关闭这个公网访问，然后在VPC内进行一个安全的一个交互。

呃，第三点是我们对这个做了一些的适配，我们通过Co来监听map，呃，这这个会存它需要的资源，比如呃，Source，比如说它自己的一些配置，那么通过计算之后就是判断是否需要这个进程来进而来管控这个国发来进行一个秒级的重启，来达到大幅减少破的重建次数的一个效果啊。第四点是我们积极的拥抱开源生态，嗯，从国方纳8.4开始，我们向方的官方回援了一个企业微信的一个告警通道，现在用户已经可以在最新的国方里面通过一个叫微的一个呃，Contact point去达到把告警直接投放到企业微信里面的效果。并且在集成上面，我们高度集成了腾讯云监控国外方大插件来补充可视化能力，这个插件目前支持50多种云产品的一个基础监控数据。

嗯，第二部分我简单介绍一下具体的tmp的一个应用与场景。首先是监控自建或者跨云的一个K8S集群，嗯。T它是原生支持腾讯云T的一个呃，容器监控的，那么如果他用户要监控自建的或者一个的，那么用户他可以在腾讯云的云原生分布式应用中心T里面通过注册的方式来把这些集群注册上去，这样在T这边就可以向监。

第二步是我们提供了一个呃，集成开源的功能，这个功能在我们的系统里面叫做集成中心，因为开源的第三方的，它需要用户自己去部署，比如说自己去管控对应的的一个资源占用，或者自己去管控相应的的版本，那么在我们这里的话就可以提供，嗯，提供用户在界面上直接编一键安装的方式来采集相应的数据库，中间件或者基础设施的指标，并且我们提供优化过后的国家方面板的安装。第三点是来监控腾讯云的CVM的这个场景，我们扩展了托米修斯的一个抓取任务的一个配置，现在用户可以使用C速C这个C一个配置支持C筛选条件，嗯，列如如图所示这里的一个标签，那么它可以支持云服务器的标签自动识别，这样在机器扩缩容的时候，用户不需要来更改这里的一个采集配置。

第四点是我们支持导入云监控的基础监控数据，嗯，我们自己了一个叫Co的一个第三方的，这个也在源支持C。接着是呃基础设施及代码，嗯，如果用户他想将他非常多的一些监控资源纳入版本管控，怎么做呢？我们提供嗯，T form的呃provider这样的一个资源，让用户可以在呃它的代码里面来管控整个tmp的实力，以及相应的资源的生命周期的管理，例如常见的容器采集、配置预计和告警策略，或者说像国外发的生命周期也可以纳入文件版版本管理。

最后是深度集成腾讯云国家发，让用户可以在呃国家发里面去查看实例的呃指标预计和以及告警规则的状态，然后以及让用户可以在国家发里面去来管控manager的一些能力，比如如图所示这里的来管控国家发的一个呃告警意志，这里在国家发展里面配告警抑制，实际上就等同于再去配了啊配，配置好了普罗米修斯里的manager的抑制功能。嗯，最后是tmp的总结与展望。总结方案，总结方面我们是采集上面采用了一个kVA的一个自动扩缩容方案，存储方面是一个按量使用资源池化的一个集群方案，可视化方案是孵化了官方的托管服务啊。展望方面，我们希望在日常迭代之外，继续去继续提高容器采集或者非容器采集下的一个白平化配置水准，来进一步降低用户使用普罗米修斯的这样一个使用的门槛。

啊，这是我本次分享的所有内容，感谢大家观看。非常感谢夏浩明老师带来的精彩分享，接下来由腾讯云微服架构师严松柏给我们带来北极星灰度发布时间的主题分享，有请严松白老师。大家好，很开心今天能给大家带来腾讯北极星灰度发布实践，我是微服架构师严松柏，那么我们今天的内容会分为两个方面去讲，第一个是灰度发布的技术原理，第二个是灰度发布的实现方案，那我们先来看一下灰度发布的技术原理。

呃，首先我们来看一下什么是全量发布，我们在早期的呃，机器资源比较紧张的时候呢，机器都是预先静态分布的，那我们在发布应用前呢，我们的这个应用A会在呃某些机器上，然后发布之后呢，我们的这个新版本也还继续在这些机制上，那这样的场景它适用于这个单体应用，或者是一些非关键的应用，或者是开发测试环境，那么它存在的问题是什么呢？它有可能会造成我们在升级过程中服务中断，然后出现问题，也比较难回滚，试错成本比较高啊。那我们来看一下为什么会需要灰度发布呢？首先我们看一下新版本发布会存在哪些问题，第一个就是我们功能设计问题，影响可能过大，比如说我们某个新闻APP新增的推荐功能，那么我们因为设计问题导致了推荐的信息过多，干扰到了用户，那全量发布后有可能会引起用户的。

的不满，那第二个就是后台故障的扩散，比如说我们某个后台系统新版本开发时引入了一个问题，那在特定条件下会触发这些问题，导致系统负载提升，那么业务提升，呃业务的请求也会受到影响。那第三个问题就是我们在发布过程中服务会中断，那么每次发布新版本的时候都需要停服，那停服的过程中业务就会没法响应，那这就是新版本发布时候存在的问题。那我们解决的方案是什么呢？那就是我们灰度的去发布新版本，那灰度带来的好处，第一个就是说我们可以按需的推送新功能，我们新功能前期只针对有强烈需求需求的这个用户去开放，那通过用户的反馈持续的去进行功能优化。那第二个就是我们在我们可以按照百分比控制这个变更范围，比如说我们这个，呃，可以控制流入，新版本的流量初期只引入少量的流量。

进入新版本，然后如果存在任何问题，我们马上立刻回滚，能够控制故障的影响范围。那第三个就是多分组不停服发布，我们在灰度发布过程中，通过精准的版本路由可以实现新老版本同时共存，这就是我们为什么需要灰度发布新版本。那我们来看一下什么是灰度发布，灰度发布的定义其实很简单，我们就是按照一定的策略去选取一部分用户，让他们能够先行的去体验我们新版本的用户，然后我们通过收集这部分用户的对于新版本的这个反馈，然后我们来慢慢的去扩大这个新版本发布的影响范围，直到所有的用户都用上的新版本。那些灰度发布带来的好处，其实前面也总结到了，其实总结起来就是两点，第一点就是我们能够降低发布带来的影响，让这个少部分的用户提前的去使用新版本，如果他们发现任何bug或者性能问题。

我们可以提前的修复，可以把这个影响降到最低，那第二个好处就是有效的控制并观察新功能带来的效果，我们可以对比新老版本的功能，更好的去观察和记录新功能在用户中的反馈，让我们在后续的这个优化产品的演进中可以提供一些参考。好，那么灰度发布的分类呢，主要有三类，第一种是金丝雀发布，第二种是滚动发布，第三种是蓝绿发布。我们先看一下金丝雀发布，其实金丝雀发布的原理相对来说比较简单，我们在发布的过程中呢，我们会先升级一部分的实例，然后呢，我们把这个流量，呃，切换一部分的流量到这个新实例里面，然后我们再升级第二部分的实例，然后再切百分之，比如说60的流量到新的这个实例里面去，那么不断的重复这个过程，直到百分百的流量全部切换到新版本里面去，那滚动发布是什么意思呢？滚动发布就是比如说我们如上图所示，我们现在有三个实例，那么我们第一批先发布第一个实例，第二批发布第二个实例，第三批发布第三个实例，直到所有的实力都分批的发布到了新版本，这就是滚动发布，那么蓝绿发布是什么意思呢？蓝绿发布。

图上图所示，我们啊，我们第一个老版本的啊，这个应用呢，我们把它归属到这个，呃，绿色这边，那么我们会创建一些新的机器或者新的节点来部署新版本的这个应用，那么我们把它归属到蓝色这边，那当我们蓝色这边发布完成之后呢，我们做好了完整的测试，如果没有问题呢，我们再通过负载均衡去把流量一键切换到蓝色这边，这样做的好处是我们不会造成这个服务的停机，那也同时能够完成我们的新版本的升级。

这就是灰度发布的三种常见的分类。那我们来看一下灰度发布的实现方案。首先灰度发布的实现的话，主要分为下面几个步骤，第一个就是我们先要完成实例的达标，然后我们会通过网关去进行路由，然后再到微服务中去路由，然后在这里面会涉及到标签透传，那最终就可以达到灰度的完成，那我们先来看一下实例达标。什么是实力达标呢？实力达标指的就是我们通过打入实力标签等手段，将新版本的应用与稳定版本的应用给区分开来，可以看到右图就是我们通过呃，Spring cloud Tencent自注册的方式以及K8S标签同步的方式去对实例达标，我们这里标记的是version2.0版本，那么啊，框架自注册的方式其实就是我们在标签配置，在这个框架的配置文件中所应用的类的启动，自动将这个标签注册到注册中心，那K8S的部署标签同步呢，其实就是实例标签作为K8S部署标签进行配置，那随应用部署后呢，自动同步到注册中心，那这就是实例达标。那我们看一下网关路由啊网关什么是网关路由呢？啊，网关作为这个我们这个流量的入口，它负责将外部的流量按照一定的比例啊，通常是啊，按照一定的规则，通常是按照一。

定的比例或者是用户的一些特征来去切分这个流入灰度版本和稳定版本，然后并对这个灰度流量进行一个打标。可以看右图所设，我们的用户的请求进来之后会经过云原始网关，那么云原始网关会把流量分为两部分，一部分是稳定版本的请求，另一部分是灰度的请求。那么我们如何进行网关路由呢？呃，通常会使用云原生网关在配置这个原生的一个路由规则，然后通过啊网关直接将流量拆分到不同版本的实例中去。那么在在腾讯云上呢？我们推荐使用TS云生网关，因为它支持图形化的由规则配置，也支持直通注册中心。

好，我们接下来看一下微服务路由，什么是微服务路由呢？啊，我们前面有了这个网关路由，把请求转发到后端之后，那么在后端中我们会通常会有不同的服务，那么服务与服务之间会进行一个调用，那么微服务路由指的就是在服务调用链路中，将灰度请求固定在新版本服务之间进行这个传递和处理，可以看右图所示的这个部分，我们服务A分为稳定版本和灰度版本，那当我们服务A去调服务B的时候，我们期望稳定性版本的服务A调稳定版本的服务B，呃，然后灰度版本的服务A调灰度版本的服务B，那这个时候就是要做的就是微服务的路由了。那么呃，如何进行微服务的路由呢？其实有很多的这个方式可以做，那这里其中我们就介绍一下北极星去做的方式，北极星是我们腾讯开源自研的一个服务治理框架，那它提供这种自定义由的能力。

支持通过图形化配置规则的方式实现服务之间的流量的这个调度，可以看到右图下面我们就是通过北极星来去做流量调度来去实现呢，我们啊这个在服务间的这个流量路由，那在在这里我们推荐使用TSD的北极星，因为它支持自动托管以及服务调用流量实时监控的能力，可以精确掌控灰度发布的这个全流程。那我们接下来看一下标签透传，标签透传是什么意思呢？我们在网关进行了这个流量染色之后，然后在微服务的调用过程中，我们需要将染色的标签在每一条之间能够进行一个传递，来使得所有的微服都可以识别到这个灰度流量，并进行一个处理。可以看右图所示，我们在微服务网关染色了之后，啊，我们这个染色之后的这个标签我们到了服务A，然后从服务A到服务B，那么接着往下传的过程中，我们是需要把这个标签也跟着透传的，那么在这个过程中，这个就是标签透传，那标签透传怎么做呢？

通常有几种方式，第一种就是框架来去透出啊，应用集成的服务框架，通过这个服务框架完成服务间的一个标签透出，另外一个就是我们可以利用流量代理透传，我们在服务网格的这种应用模型中，用户需要在应用内编码完成流量标签从接受到转发的一个透传过程。那么。在腾讯云上呢，我们在使用北极七星的时候，我们是更推荐使用视频cloud特的，因为它的好处是它能够自动完成标签透传，支持跨线程的透传模式，无需用户去感知。

好，接下来我们来看一下要如何判断灰度已经完成了，首先第一个我们需要确认流量是否已经按计划切换到灰度实例的分组，第二个是呃，确认切换到灰度分组的请求是否能够正常执行，那么呃，最后就是我们推荐使用TS北极星的服务治理监控能力，它支持可视化的看到这个流量实时切换的情况，然后以及流量的成功率等延啊等成功率时延等关键指标啊，这这样我们就能够判断说我们的灰度发布是不是已经完成了。那么啊，灰度发布之后我们会通彻还会做一些什么样的处理事项呢？比如说我们如果是蓝绿发布，那我们当所有的流量全部切换到新版本之后呢，我们会将老版本的分组的实力全部下线来节省资源啊，如果我们用的是金丝雀发布呢，我们将我们需要将稳定的这个版本服务分组全量升级到这个新的。

版本，那全链路灰度的情况下呢，我们将新版本涉及到的稳定版本分组中的呃，多个服务全量需要升级到这个新版本，这个是灰度完成之后需要处理的一些事项。好，那今天北极星关于这个怎么去做灰度实践的内容就到这里，感谢大家的观看，谢谢。非常感谢严松白老师的精彩分享，接下来由腾讯云资深解决方案架构师郭志红给我们带来cream基于fanos理念的极致降本主题分享，有请郭志恒老师。呃，大家好，我叫郭志红，呃，负责腾讯云原生产品的解决方案和架构工作，那今天给大家分享的一个主题呢，是CRA，基于里面的极致降本。那我今天的主题主要有以下三个方面，第一个是我们看一下云原生资源利用率的一个现状，第二个呢，是我们一起深入理解一下孔的一个资源管理，它给我们提供了哪些，呃，降本的一个手段，其实同时它也有哪些不足，然后基于这些不足呢？第三部分我们会看一下我们腾讯内部，或者是create这个项目是由提供哪些解决方案，以及我们的技术手段，还有我们的最佳实践。

那第一部分的话，我们先看一下云原生资源利用率的一个现状。那我首先会分享两组数据哈，第一个呢，就是呃，原生基金会在2021年的一个调查报告显示啊，目前有96%的一个组织已经在使用或者在调研cooper，这也创了一个历史的一个新高啊，那同时啊，Flex这个报告也指出，其实有30%-35%的云支出是被浪费了，这个浪费还是非常严重的，所以我们带着这两份报告也去把腾讯云上的真实的用户数据看一下。

呃，我们抽呃抽取了三份呃数据样本，第一个的话就是我们的物理机这个样本，那物理机的资源利用率大概是在10%左右，那虚拟机的话是在12%左右，那我们知道呃容器的话，它是一个更轻量级的一个虚拟化技术，那加上Co这种细力度的资源调度和编排能力，我们觉得容器场景下应该可以大幅度提升的一个整体资源利用率，但其实实际情况啊，我们看到只有14%，其实并不理想。那我们其实我们也分析一下，那么为什么在云原生时代啊，在这种cocker这种云原生技术的加持下，在资源利用率还是不高。那其实我们呃觉得核心原因啊，有这么几个部分，那第一个的话就是说，比如说我们在呃物理机时代，或者是没有上云之前，没有云原生技术之前，那我们是怎么管理呃成本的呢？是怎么管理资源，往往是有一个it团队，或者有个财务团队，那在年初或者年终的时候去做下一年的一个预算，那这个成本是固定的。

那有一个中心化的一个一个方式去统一规划，那上云或者使用原生技术以后呢，就是把这个资源申请和使用的权限往往下放给了我们的业务团队，那业务团队可以按需使用，那虽然这个方便了很多哈，但是的可控性也会差很多，所以就导致业务的不断增长，导致我们成本也会成倍的一个增长。那这是一个原因，另外一个原因的话就是虽然我使用了云原生这个技术，但是他在呃业务在使用的时候啊，还是像以前申请VM或者申请物理机那种方式去去申请哈，往往申请的偏多，所以就导致了整个浪费比较严重啊。这也是为什么在后原生时代，我们成本管理还是有非常多的一个挑战。

那其实这块也给大家分享一组数据哈，就是在腾讯从2018年产品变革以后啊，资源业务全面上云，那其实我们到今天为止啊，差不多四年左右的一个时间，整体呃，上虞那个规模达到了五千万，其实大部分都是通过容器化原生的这种方式去去做的。那通过我们的一系列的混部技术，那整体的一个资源利用率可以可以达到65%，帮助整个集团节省成本大概有30多亿。这也是我们在今年做的一些成绩单啊。那我们相信相信大家也对Co也都比较了解哈，那这块主要是为了后面我们的一个切入哈，先简单带大家回顾一下Co他做资源管理的一些能力。那我们知道Co它是啊，通过生命式的API定义它的一些资源，在节点的话，它叫node，那我们是看一个，比如说一个四核8G的一个no的，那其实它有一些是被给分配个系统的，这些叫system serve，或者是community serve，这些是没法分配给业务，能分配给业务就是这些，剩下这些，那我们调度完schedule，调度完以后，那往往可能还剩了一些，比如说这些，这些我们叫leftover，就是因为一些碎片或者是对吧，调度的一些机制的问题导致这些。

资源无法被调度，无法被分配，这些资源可能就会就是被浪费了。你看这是K8提供的一个节点的资源管理能力，那它同时提供了有两个重要的概念，就是request和limit request就是说我这个资源啊。我申请了多少，这个是K8调度器，会根据这个资源去去申请。啊。还有就是它有一个limit，就是说我这个po或者这个容器，我最大使用可以到多少，那我通过这两个request limit可以的控制啊，它的一个比例的控制，可以去对集群的资源或者节点的资源做一个超卖，这也是K给我们提供的可以提升利资源利用率的一个一个核心的一个手段。

那其实我们看一下一个典型的一个资源利用率，它是什么样子的，比如说我们有一个40盒的一个节点，那它资源总量，它实际利用利用量，那中间这部分都是浪费的，那我们看一下它到底浪费在哪里，那第一部分的话就是说我们这个没有分配出去的leftover这部分因为一些碎片或者调度的问题没有分配出去。第二部分的话就是。呃，这方过多分配的一些资源，就是说我申请的申请多了，但实际利用的并没有那么多，那就是过多分配了，我们想能不能把就是这条线尽量往下拉，能不能把这个过多分配的出去的，再重新分配给更多的业务去使用，这也是我们第二个可以优化的一个点。那第三个的话就是我们在这块可以看到有一个在线业务往往都有一个波峰波谷，那波谷这部分往往是就是被浪费了，我们想能不能把波谷的这部分也利用起来。

那这也是我们整个提升资源利用率的一个，从通过现状我们可以看到我们的一个解题思路，就提升这三部分的一个资源利用率。那其实同时Co也提供了这种弹性的能力啊，比如说hpa和VPA去帮助我们在业务高峰的时候去弹出来，那在业务低峰的时候去说一些一些破，用动态的使用资源，提升资源利用率，那其实有了像request limit这种超卖，或者是动态的弹性伸缩，那我们是不是就可以很好的。提升整个集群的资源利用率呢，其实在我们实践的过程中发现其实并不是非常理想。那核心的问题，其实我们总结下来有三个，第一个就是那资源在配置的时候，比如说request和limit配置多少到底合适，那这个其实。

啊，很多业务它是往往很多客，呃或者是业务方或者是平台方，它都是根据一些历史的一个经验值来配的，比如说之前我在物理时代配多少，那我上了容器以后还配多少，这个肯定是保险会出问题，但是往往会会比较配多哈，那或者是他就拍脑袋随便配配一个，那这个肯定是不准的。那所以也就是不会配的一个问题，那还有一部分的话就是弹性哈，弹性那存在的一个问题就是它有一个滞后性，比如说弹性往往都是目前的一些弹性，都是通过一些监控的指标啊，那我比如说complete或者S去采集这些节点上的一些指标，我给met server这个采集往往是有一个一个interval的一个时间间隔的，这个时间间隔上报给magic server，它会去计算，这个计算又有个时间，那我。呃，计算完以后触发了这个阈值，触发了阈值我去扩容pod那节点，如果资源不够的话，还得扩容节点，那这一系列的。

的流程其实非常长的哈，往往需要五到十分钟，那所以导致了一个它弹性滞后性的一个问题，所以很多业务也不敢被弹性，弹性去影响业务。还有一块的话就是，呃，我们知道CPU它都是一个公平调度的模式，那我在如果是一个节点上装，装的太满，部署的业务太多，那在业务高峰的时候，有一些敏感性的业务，就可能会因为CPU的挑战啊被影响。所以很多业务也不敢配，担心会被影响业务。这是我们觉得原生它可能的呃的一些不足哈，导致业务不会配，不敢配，不能配。那其实这是我们在没有去做通过或者通过我们降本方案去做业务优化之前的一个资源利用率情况，那其实看到某个业务的CPU利用率只有15%，内存利用率只有25%，那过去一年的弹性也只有10%。

所以这是导致它核心资源命中率低的一个原因。那我们Korea是怎么做的呢？那基于前面呢，我们讲到的我们的呃，三个解题思路，还有我们。会配，不敢配，不能配这样一些现状啊，我们提供了一个全链路的一个降本方案，那其实就是三个步骤，第一步的话，我们提升装箱率就是。让这个节点装的更满一些，那第二的话就是我们去提升整个节点的一个峰值的一个利用率，然后在峰值的时候。可以啊，让这个节点跑得更满，那第三步的话，就是我们进一步提升整个均值的一个利润。那有了这些呃理念以后，其实我们在实践的过程中，往往需要一些理论的一些支撑哈，那这个理论其实就是films，那其实films他定义了一系列云财务管理的规则和最佳实践哈，他有一些原则，就他提我们团队合作，他提倡我们团队，团队中中的每一个人都要有成本优化的一个意识，他同时也有一些一系列的一个角色，比如说有的从业者去制定这些规范。

还有就是也也有管理层去推动去落地，还有就是我们的业务人员或者产品人员去去具体的做一些实施。那其实它也有一系列的一个一个阶段和步骤，同时想要取得film的一个成功，我们也需要，就是他也提供一系列的能力模型，你比如说我要理解成本和用量，我要去做绩效跟踪和展示这块，为什么要做绩效跟踪和展示呢？因为比如说在一个大的团队，像腾讯内部有。这种呃，有有几大BG，还有不同的每个BG部不同的业务部门，那那可能一个业务线就有几万到几十万个pod，那这么规模大的一个场景下，怎么去推动让更多的人去朝着一个共同的目标去一直持续的一个努力，那其实这块就要制定一个核心的KPI。

同时也要实时的去把这些效果、成果和展示出来。那其实还有的话，就是我们需要一些一些日报或者报表去帮助我们业务团队或者平台团队去实施做决策，还有就是一些费率优化或者用量的一些优化，同时需要我们整个组织的去做一个支撑。这是。的一个它的一些理念，那其实我们的CRA就是cloud resource anatics and economics，就是云资源分析和优化，它是完全基于off能力模型去呃做的一个成本优化的一个框架和解决方案。那其实Korea它有这么几个部分，核心就是两个部分，有CD和create agent，那Korea d的话提供了四个模块，第一个模块就是我成本的展示啊，我要明确的看出来，我当前的资源利利用率怎么样，我哪些是浪费了，我哪些可以优化。

那有了这些以后，我们还去做一些一系列的资源推荐和副本数的推荐啊，那这块其实我们可以知道，如果是一个在线的业务啊，那他。往往是有一个利用率的一个曲线的，那我们就可以基于的一些呃，一些资源的预测的算法，比如说DSP或者滑动窗口的算法去预测出来，你在就是根据我们的历史的数据，比如说未来一周或者未来一个呃，过去一周或者过去一个月的数据去预测未来一段时间内，你这个业务可能需要的一个资源利用率。可能需要一个资源量，那这块其实就是可的一个核心哈，就是提供一个资源预测的一个能力，还有就是。

通过这种去解决我们前面提到的它业务不会配的一个问题，那还有第二部分的话，就是我们也可以基于历史的数据去预测你未来可能需要的一个副本数。这块我们叫EPA或者EVPA智能的弹性。那通过这个去解决前面我们提到的一个延迟，就是弹性延迟的一个问题哈。那还有一部分的话，就是呃，资源的一个预测，我们也是根据历史的一个监控数据，可以分析出来，或者预测出来这个集群在未来一段时间内，它哪些资源，哪个时间段的资源是空闲的，我们给这些资源打上一个external resource这样一个呃，一个自定义的一个资源。这些资源就可以被一些其他的业务，比如说离线业务或者的任务去使用。

那这也是我们在离线混部的一个核心，那有了上面这些，呃，我们基于预测，我们也说预测为王啊，这是奎运的一个核心，那预测出来，那我们其实还有一部分啊，就是create做的，那我保障业务的一个稳定性，那这块是我们扩展了pre class，就提供了更多的一个业务的优先级。呃，那业务方可以通过业务的一个实际情况啊，给它配置上不同的优先级，那我们基于t Linux底层的内核啊，它提供了一个全资源的QS隔离能力，包括像CPU、内存、GPU、磁盘L和网络L的一个QS隔离能力。那在业务高峰或者是资源紧张的情况下，那高优的任务可以抢占低优任务的一个资源，那在一些极端场景下，我们也可以驱逐一些低的任务去把这些资源释放出来，去保障高优任务的一个稳定性，这也是我们认为在做资源或者做资源优化的过程中一个核心啊，就是提升稳定性，所以我们也说稳定性是根。

那这是C的一个整体的一个能力模型，除了我们前面提到的一些能力，它其实还有一些一些比如说控制台提供的一些能力，那控制台这块的话，我们有平台方和运维方的一个两个视角，那在平台方我们提供像成本的分布啊，优化的预测，聚类的分析啊，应用的画像等等一系列的能力，那这块比如说应用画像哦，那我们就可以很根据历史数据，可以看到这个应用它到底是一个CPU密集型的，还是一个网络IO密集型，或者磁盘IO密集型。那知道这些英文画像以后，我们就可以根据我们的调度策略，把一些。啊呃，CPU密集型或者网络密集型的调度在一起啊，让它充分利用这个节点的资源。

那我们同时比如说还有一些像一些部门的排名啊，为什么要做部门的排名，那这块就是呃，可以通过一些组织架构层面的一些约束和推动其他的业务部门去，呃。去积极的去配合我们去的一些工作，比如说我们给业务打分，那这个业务打分，然后做排名，那排名高的我们可能给一些呃，激励或者是一些鼓励的一些措施，比如说我们价格给的更便宜，比如比如说它的呃。答辩或者晋升他他可以有一些有一些呃一些优势啊，比如说一些排名第一的，我们当然可能会有一些相相应的一些措施啊，那这个就是通过部门排部门排名去做进一步的去推动。那当然还有一些业务，呃，维度的一些视角。那下面的话就是还有一些像，呃，这个其实前面都已经提到，像一些资源推荐啊，副本数推荐啊，当然我们还做了很多调度增强的一些能力，那比如说我们有负载感知调度，就是根据真实的一个资源利用率去做调度，还有就是拓扑感知调度，就是解决就这种case，默认情况下跨new的调度，带来了一些可能业务访问延时的这样一些问题。

那这块就是性能隔离，就是基于我们内核层面做的。全功能力，QS隔离能力，那在离线混部这块的话，我们也做了很多像干扰检测和主动回避的一些能力。那这是整个的一个能力模型。那我们也提供了一个。呃，对外的一个DEMO，大家可以通过这个地址去访问一个空的一个DEMO。可以看一下我们提供的一系列的能力。那呃，有了整个昆的一些能力，我们为了更好的去满足内部客户或者外部客户的话，呃，我们也提供了一个产品化的应用，那这块呃我们知道不管是用呃我们云上的产品t ke，还是我们自建的这种Co，它其实都是这种so否的一个模式，那这种模式下，当然优势的话就是我们自主可控，那它有很多缺点，就是说我需要自己去维护整个集群，我需需要投入很大的一个维护或者升级的一个成本。

那与之相对应的话，就是这种service的模式，它这种模式可能比较简单，它全托管，他不需要去我业务方或者平台方去维护，那他也提供这种啊。按需使用这种能力哈，可以降低成本，但它也有一些问题，就是我so否像service模式迁移过程中可能并不是那么平滑，它需要一些业务的适配和改善，那同时它也不可控，那嗯，那平台方说我看不到这个节点，那可能我需要更可控一些，那其实基于这种so和service的优点和缺点，那我们创新性的提出来这种一个新的模式，就介于这两者中间的一个，我们叫原生的节点哈。

就是既具备这种呃稍的一个可控性，也具备这种类的一个呃，运维简单这样一个能力啊。那原生节点就是我们的核心理念，就是像可以像管理pod一样，通过KS的生命式的方式去管理一个note，那原生节点其实主要提供两部分的一个能力，一部分是呃帮助客户降低运维的成本，一部分是帮助客户提升整个集群的资源利用率，那在运维这块的话，我们提供了。呃平台方平台提供了像呃K8S的内核运行时还有它的组件的一个升级能力，这块只需要用用户去触发，我们会平台方去自动升级，还有我们在呃帮助客户呃去排查或者是解决问题的过程中也积累了很多的经验，就比如说我们可以把提供了更多的像节点的异常的事件，比如像呃文件系统异常，或者内核死索，或者是file PID，或者max大于最大值的一个80%，这些异常我们都会通过k event暴露出来，那用户可以根据这些。

他异常事件做一个节点的自律，或者是一个一个告警的一些能力。所以其实我们总的来说就是通过我们产品化的能力啊，提供一个专家的一个建议。帮助我们的业务，或者帮助我们的用户去更好的去啊维护这个集群，提升整个集群的稳定性。

那在资源利用率层面的话，就是我们集成了前面我们的cream的一系列的能力，包括像智能request推荐，智能副本数的推荐，呃，智能的一些额外的一些调度器的调度的能力，还有在临性混部，还有节点的一些QS隔离能力等等。那同时也你也提供了一个可交互式的一个资源大棚啊，那比如说我们有一个集群，我们发现它资源利用率不高，那我们去怎么去优化它呢？我们这块有几个步骤，第一步的话就是我们先通过我们资源管理大盘分析一下这个业务或者这个集群哪些是浪费的啊，现在的资源利用率怎么样？那第二步的话，我们筛选出来，那比如说我们提供了一个多维度的一个指标，可以看到节点装箱率低的节。低的一些节点，或者峰值利用率低的一些节点，或者节点负载，比如说po的少的一些节点，我们去选一些我们要下线的节点，那选完这些要下线的节点以后，我们也要看一下这个。

节点上的pod能不能被驱逐。核心就是。这些我们都如果不能驱逐的话，我们都会展示出来。那然后就是怎么去安全的下线，那这块我们提供两部分的一些能力，第一部分的话就是我们可以看到这个节点下线的一个进度啊，那我们有整体的把控感，第二部分的话就是我们提供了啊一个友好的一个驱逐策略，就是K8S默认其实的它的驱逐其实是不是很平滑的，它是先Q掉一个pod，然后再起来，那我们的一个优化方案就是先起来一个pod，然后再Q掉一个pod，让这整个驱逐更平滑一些。那就可以安全的把这个节点给下行掉，那下行掉以后，我们怎么避免后续再出现这种资源利用率啊低的这种问题呢？这块我们也提供了一系列的能力啊，比如说像配置节点放大技术啊，像request推荐啊，像原地分配啊，像我们的一些调度能力啊，重调度能力啊，这块就是根据我们提供了一系列能力，用户可以根据自己的场景啊，去选择不同的一个优化手段。

那最终我们也可以通过一个报表显示出来，我们的优化效果怎么样啊。那这是我们整体的一个，呃，优化流程，那如果我们自己去做的话，其实会涉及到非常多的一些一些难点，那这块就不一说。那其实呢，可以看到这个可交互式大盘的话，我们提供了两个map，一个是no map，一个是map，就是节点维度的一个的资源。一个DA，还有就是workload维度的一个资源，Daport可以很方便的看到，就说你这个业务当前的，呃，申请量是多少，申请量是多少，实际使用量是多少，我们推荐的是多少。

还有就是我们提供了呃一个专用的调度器，根据不同的场景，我们也可以选择不同的一个调度策略，比如说有些业务就希望我们每个节点的负载都是均衡的。那我们知道Co它本身是一个按照request调度的，那时间长了以后，我的request或者limit page的不合理，那久而久之就会造成，那有的节点负载高，有的节点负载低啊，那我们提供的负载均衡调度，就是说可以根据真实的呃历史。监控数据啊，根据真实的一个资源利用率使用情况去做掉。那第二个的话就是，呃，有些业务觉得可能需要提升整个装箱率。就是说它这个场景就是那节点其实已经装满了，但是还是发现资源利用率不高。那这个场这个时候，那有的做法可能就是我让业务去把request调低。

但这种那业务方那可能非常多，那业务去一个一个调，可能也不切实际，很难推动，那我们就在平台方提供了一个能力，就是说可以把你这个集群的某些节点的资源去放大。比如说我可以把CPU放大到两倍，或者是把内存放大到两倍去放大，让业务更多的去调度上，那同时我们也提供了像这种呃。像这种节点的一个最大的一个限制啊，就是说呃。防止它这个节点调度太多，那经常利用率在高峰的时候，那它出现了一个一个水崩，水崩的一个状态，我们有一个水位的一个限制的一个能力。那第二第三个能力的话，就是说我可以比如说业务想规整这个业务有些节点的资源利用率比较低，那我就有一个请说优先的一个调度策略，就是说我可以优先把一些节点调动嘛。

那从而把一些其他的利用率低的节点去去做一个回收啊。那这我们提供了不同的一个调度策略。还有就是有也前面也提到智能负载，就是说是快速推荐，那这块其实核心是还是根据预测。它本质上其实是根据历史的一个监控数据，去根据一些预测算法去推荐一个合理的值，那这块其实是简单来说，就是我们根据你历史的数据，找到你资源利用率的一个P99的一个值，在这个P99的一个值上乘以一个安全系数。这个就。我们认为是一个非常安全的一个并且可以提升资源利用率的一个合理的request。那这个request也是可以根据你历史的一个负载去动态的去调整。

那还有一个能力，就是我可以做到节点的一个原地升降配合，就是说在不重启呃pod的情况下，我去修改。我这个资源的request limit1配置，那这块其实核心场景有两，一个是降配，一个是升配，我降配的话就是说我之前可能配多了，然后为了一些冗余buffer冗余的太多，我需要降配。但是又不影响，不想影响业务，我就直接可以通过原地降配，还有的话就是原地分配，然后我可能之前配的少了，那为了应对一些突发情况，比如说某个pod，它的内存在。根据一些请求量逐渐升高，那为了不影响它触发OM，我可以临时给他调整它的一个request limit，一个值。那这是我们原地升降配提供的一些能力。

还有其实整个原生节点里头也默认集成了我们的在离线混部和QGPU的能力，那在离线混部就核心解决我业务波峰波谷情况下，在波谷，尤其是夜间和在线业务没有流量，我通过混布的方式把夜间这部分也利用起来，这一块其实可以很大程度上去帮助我们提升整个节点的资源利用率。那我们评估至少可以提高三倍的一个资源利用率。那同时我们也提供了呃，我们自研的在内核层面做的一个QGPU虚拟化的一个能力，那这块。就是提供了详细力度的，呃，显存和算力的一个隔离。和共享农业啊。同时也可以做到一个性能的无损耗。好，那今天主要就是给大家分享了一些呃，我们在呃腾讯内部的一些实践，还有在资源利用率提升方面的一些手段哈。

那其实我们主要就是我们看了一下当前金融资源用的现状与一些不足，还有我们C或者腾讯内部的一些解决方案以及技术手段，还有最佳实践，同时为了更好的服务内外部客户，我们也把这些亏的能力，呃，包装成我们t ke公有云上的一个产品，叫原生节点啊。啊，那不管是TK的用户或者是非TK的用户，都欢迎大家去体验，或者或者是我们的原生节点。那其实我们做了这么多，本质上还是希望让更多的用户去享受到云原生给我们带来的一个技术红利。好了，谢谢大家，我的今天我分享呢，就到这里。非常感谢郭志红老师的精彩分享，接下来由腾讯云高级工程师卢家辉给我们带来coding CI3.0云原生高性能C实现的主题分享，有请卢家辉老师。

大家好啊，我叫卢家辉，是腾讯云coding CI平台组的研发leader，今天我想给大家分享一下我们coding CI3.0在研发过程中的一些思考与实践。今天的分享就会分为这三个部分，第一，讲一下我们在云原生时代的一个CI设计理念。第二是我们如何使用OLAFS这个技术实现一个高性能的CI。第三是我们在C上实现的一个远程开发服务，这背后的思考和逻辑究竟是什么样的？首先是第一点，云原生时代的CI设计。嗯，讲到语言生，我想大家都会想到这样的一些技术，比如说容器啊，声明式API。然后我们在设计coding c3.0的时候，也都参考或者使用到了这些技术，让用户在使用这个CI的过程中有延伸的一个体验。

嗯。这里具体到第一点是，我们是通过一个yam文件来声明和描述流水线的。这样的好处是显而易见的。比如，对于开发者而言，它可以更方便快捷的管理流水线配置。因为这个配置文件是跟代码一样，都是放在代码仓库里面管理的。所以就是每个开发人员都可以很容易。知道我的整个就是线的配置是什么样子，就不用又要跑到去另外一个CI系统去查看，那查看时候可能就涉及到一系列的一些权限管理。然后直接在仓库里面的话，就非常之方便。第二呢，作为一个仓库的文件，它是被版本管理和控制的。这。这里的一个好处就是，如果我们修改流水线的时候小心改出问题了，那么我们可以很方便的通过我们的仓库的一些版本的回溯，马上的去调整到原来。

正确的一个一个版本，而且也可以知道。呃，有问题的这个版本就是发生什么时候改成什么内容，就可以很方便的去定位问题，去重新去修改。同时因为它是一个仓库的一个文件嘛，那我们也可以走一些我们仓库现有的一些CI的流程。那就保证我们每一个流水线配置都是经过走查之后才能去。然后去修改。并且很会造成复。然后最后第三点。是作为一个。代码文件吧，当然它其实就可以通过一些代码化的方式实现一些配置的复用。比如我们想在A仓库里面引用一个在另外一个仓库的一个配置文件，我们这里会提供一种叫类似于include语法，可以直接把另外一个仓库里面文件引入进来去使用。

然后再讲一下我们的第二点，我们基于容器技术去去进行的这个CI的设计。这里又分为这样三个点。第一点是doer as environment，第二点doctorers practice，第三点native doctorer support。那这三点具体是什么含义呢？我们来一来说明一下。啊，第1.isinenvironment，就是说容器环境。这我们可以看到右边这个图。啊，就在我们流水线的每一个阶段，我们都是可以升级一个dock容器作为运行环境的。这样的一个好处是，就相比一些。通过在虚拟机上面跑的一些CIA，它往往就需要我们预先去定制好一个那种虚拟机的一个镜像，但如果遇到一个镜像里面没有，就有一些依赖是没有安装的话，那我们可能还需要在流水线里面写一个命令啊，比如说去安装一个。

一个依赖。那如果通过do这种方式其实非常方便，你可以去直接声明一个我们用到的一个镜像就好了。然后同时我们也是可以支持直接的去指定一个。那这样子就会更加灵活，就不需要可能一些镜像里面没有，我们要重新去打开镜像，上传到一个镜像仓库，那现在就不需要只指定一个就可以完完全全满足到你需要的另意的环境了。然后第二点是ER，就是说容器插件。这里就是相当于说我们整所有的这些流水线的插件，它其实本质上是一个容器。就跑这些插件，其实就是把一个包跑起来去运行。这样的一个好处就是说。开发者在编写插件的时候，其实是可以使用任意他自己熟悉的语言去编写的。

那相比一些，比如说呃，一些类似金的一些CIA系统，他们只能就通过那种Java的语言去编写嘛，而且编写插件的时候，可能还要去整个起来熟悉的规范。那整个开发起来是有一定的门槛的，那如果通过docker的话，就用开发者可以直接用他自己熟悉的语言去开发，那整个就非常之方便。它除了是支持任意的一些语言去去编写，那同时也是可以直接用到我们现在上面有的时候的一些插件，比如说我们也是可以支持。这样的一个插件的一个生态。这里也有很很多很多款这种这种插件可以去使用。嗯，第三个点就是就是说。我们整一个流水线上实是原生支持执行这种们dock的命令的，可以看到我们这个配置，然后去声明了一个dock的一个服务service，那在这个流水线里面就可以直接跑起来这个do的命令。

就比如说这些talk in啊，Dark的push want。同时也是可以支持直接在这个上面跑这个包括comp命令来去做一些。一些服务的一些编排，就比如说这样一个场景，我们需要在C上去跑一个这种自动化的测试的时候。如果是需要依赖到一些比如说MYSQL啊服务的话，那我们可以通过一个compose先把这些服务编排提起来啊，然后再去实行执行我们的那些自动化测试。嗯。讲完了一个CI设计之后，我再讲讲一下我们。我们基于一个OS的技术实现的一个高性能的一个方案。嗯，想到说要做性能优化，那我们首先想到的一种策略就是。

加缓存。那这里的缓存有分为说代码缓存和构建缓存。对，是什么意思呢？就就如果没有缓存的话，我们每次流水线构建的时候。比如说这个代码，那我们都是需要去全面去克隆一遍这个代码。那如果那代码仓库小还好，那如果那个代码仓库其实挺变到挺大，几百或者几百G甚至上百G的时候，那你整个克隆其实都是要几十分钟的那种级别去去克隆。那这样子非常的慢，如果有了那种有了代码缓存的话，那每一次我们考虑的线的时候，只是在缓存的基础上直接进行一次这种更新操作，那其实就会非常之快。这个就是这个代码缓存的一个意义。第二个是构建缓存，构建缓存就比如说我们在进行一些代码编译的时候，它会是有一些中间的一些产物，那如果把这些产物缓存起来，下一次同样去编辑，编译的时候可以直接复用这一些中间插件，那我们整个一个构建的过程也会变得非常之快。

那加缓存其实是很好理解的，而且效果也很好很明显，但这又会遇到一个问题。当我有多条流水线并行的时候。怎么去保证这个缓存不冲突呢？这里冲突是这里为什么会有冲突呢？我也可以讲一下。就比如说我第一条流水线，我正在去读这一个缓存，但是我另外一个流水线刚好是要把这个缓存给它删掉，或者说进行一个修改。那如果这样的一些操作，其实会会影响到，另外就原来第一条流水线，他正在读的这个操作。所以我们就在想，有没有一种方案可以去避免这种流水线缓存的冲突。嗯，解决这种缓存冲突常见的一些解决办法，主要有这么三个，第一个最简单。

也最直接就是直接给离子线枷锁那。那它的问题很很明显，那就只能同时只能一条线再跑嘛，那就相当于把整个并行的系统变成一个创新，都要排序的去执行，整个系统会变得非常之慢。然后第二个方案呢，其实就是在一的这个基础上，我们把这个缓存多留。多留几份，那就相当于可以有多条的队列去排队。那那那如果这个系统本身它的量不大还好说，那但是随着和我们这个流水线的使用，那。其实这个并发数其实会越来越越大的，那这时候可能就需要我们不断的去增加这个缓存。同时那个缓存的副本数的话，也是需要有一定的成本，你是要有很多硬盘去去支撑这一些存储。

那第三个方案，那如果我们不。提前提前准备好多份缓存，而是每次出现一条并行的流水线的时候，我们先复制一份缓存。这样的话，你就可以可以解决掉我们刚才说的要实时的保持很多份缓存这种高成本的一种一种方案。这个方案的话，其实如果我们的缓存的大小，存的这个文件的。大小不大的话，那其实也都还好，因复制应该也还是挺快的，但是如果你的缓存数据非常是大的话，那本身复制这些文件就会变成一个非常耗时的一个。操作。嗯，所以这里我们就在想，有没有一个更优的一个方案呢。嗯，其实有的，我们利用了一种叫OLAFS技术去实现的一个瞬间复制，那讲这个瞬间复制的技术之前，我想先给大家讲一下OLAYFS技术是什么样的。其实在工作的本质上是一种copy外的一种策略。

啊，就是说，嗯，这里可以看到一个图。通过FS技术呢，它是可以把多个目录。把它叠加在一起，然后变成最终生成的一个一个目录出来。然后叠加的时候，它的一个策略是这样的，就是处于上层的一个文件，它是可以覆盖到下一层的文件的。然后如果。如果我们要改写到底层里面的某一个文件的话，他会把这个文件。先复制到最上一层，这个叫做一个可写成的一个。一个目录里面去，然后再进对这个文件进行一个修改。这样子的话就可以做到，就是说如果我们单纯去读文件的话，那那那其实都是读对底层的一份缓存的文件，就不会说要额外复制。只有在。真的需要修改某一个文件会产生冲突的时候，我们才会把这个文件复制上，然后再进行一个修改，其实这可以利用这样一个技术去实现，一种啊，缓存的瞬间复制的。

这是它的一个基本的一个原理。就刚才说到，我们是可以把我们的缓存附录作为这里的一个底层目录。然后在这在它这上面叠加一个空的一个目录。然后这样子就可以生成一份这样的一个缓存的副本。比如说这里我可以得分别的去叠加一个目录，生成多个副本。这样的话，在这两个副本上面进行的文件的读写，其实都是不会影响到另外一个副本。同时这个文件叠加的操作是非常之快的，所以我们就可以理解为它是实现了一个缓存的瞬间复制。这里插一个题外话，包本身也是利用这样一个技术去实现，说在一台机器上面同时运行。多个一样的镜像，然后就保证这个容器里面的这个文件是不会冲突的。

嗯，啊，我们这个并发量上去了之后呢，所以我们就遇到了一个新的一个问题，就是磁盘I法形成的一个瓶颈。那问解决个问题，我们还是在原来这个OS的基础上再加了一个内存盘。我们就把刚才中间这一层这个空目录，直接通过一个内存，然后就会把它虚拟成一个目录这种方式来去实现。那大家都知道内存的性能是远远比我们的磁盘性能好的。那这样的话，我们其实就可以在这个系。在这个我们的系统上可以实现到一个很高的一个IO的一个性能。嗯，前面讲完那种瞬间复制的话，我们再把这个技术再拓展一下。来来实现到我们。就刚才前面说到的那种，我们要使用这个代码缓存，我们其实是怎么来实现到一种这种代码秒级克隆的。

这是大体的一个方案。有兴趣的同学是可以自己去拍个图里面再再看一下。嗯，我这里就直接代购啊。这是一个这个秒级代码克隆的一个效果。比如啊，我们原来是用的一种叫个方案，这个方案其实类似于就是把这个缓存复制多份这样子。但换成这种OLAYFS的趋势的时候，我们可以看到。一个原先大概是有两点多G的一个仓库。他原先如果要进行这种代码克隆的话，那其实是是需要进行40秒。那如果我们看到了这个新的这个技术之后，它是可以进行到五秒左右。基本上这个五秒就是一个SH，一个更新的一个操作，一个时间，所以我们也可以理解为它其实。

整一个代码仓库本身的大小是没有特别大的一个关系的。嗯，这里可以再看一下我们。整一个目前整一个系统上的一个一个流水线，平均启动耗时的一个数据。这个启动耗时其实就是包含我们流水线资源初始化的时间啊，然后还有刚才上面讲到一些代码克隆或我们叫做准备的时间。然后还有一些流水线，我们启动时候可能会需要有一些服务的一个创建时间，这可以整体看到我们整个平台的一个平均启动耗时，其实在几秒钟就能成了。然后这个是我们在目前平台里面跑的一些仓库的一些数据。现在这里我们看到我们。第一个最大的一个仓库其实都已经跑到了100多G，但这其实是100多G的话，然后这上面有个大的一个。

代码克隆的一个速度，其实只要20多秒就能完成。你这其实就是一个挺快的一个速度，因为你单单只是完完全全从一个仓库去克隆这里，可能就是要几十分钟或者三小时级别的。好，讲完上面的。呃呃，一个设计，还有一个高性能。然后这里我们就发现，诶，其实用CI来去跑一个远程开发服务，也是一件非常合适的一个事情。为什么呢？就因为我们CI就刚才说到，其实它会具备这样一个能力，比如说高并发，可以支持快速启动啊，然后是一种生命的一个配置。同时也是在一个高的性能，高性能的一个构建级上面去考。而这样一些能力也是我们做远程开发是需要的，比如说我们做一个远程开发，其实是需要多个人一起进来启动开发的。

然后也是需要快速启动，那我我无论在任何一个地方，我想打开一个浏览器，或者打开一个编辑器，一下子就能进入到我的开发环境进行开发，那是最好的。同时也是支持这种开发环境配置化的。就是。就是我最好是我我每个我开发的仓库，它依赖的一些环境啊，比如说比每个环境的一个版本，然后这个好的时候依赖些哪些服务啊，比如说买些服务都是配置好写好的。那每次给我。创建起来这一个远程开发的这个工作区的时候，相应的这些环境都给我配置好，能启动好，那我们直接开发，直接去进行就很好。这个非常方便。然后同时最好也是一个很高性能的一个开发机。那可能对一些。比较大的一些项目，可能几几G或者上百G的一些项目，直接在自己本地去跑一次构建值可能是非常之慢。但如果可以跑到。

云上面这种高性能的一种构建，构建集群，然后充分去利用到一些构建缓存的话，那整个构建的速度就会变得非常之快。所以我们就要写，那我们是不是就可以直接把这个云开发服务给到CI下面。啊，当然是可以的，这里是目前我们的一种用法。我们在这个仓库里面写了一个流水线配置在仓库。有创建新支的时候。就去考一个眼前开啊。就会去跑一个远程开发的一个服务，这里我们演示一下，就创建一个分支。这背后他就就会去跑取一个流水线，然后去创建一个远程开发的服务，在这里我们可以看到，诶，这个远程开发服务创建好了。这里一点，那其实它就可能进到这样一个刚才创建的那个分支里面去。

进行一个开发。然后这个分支里面的这个环境，其实就是我们在流水线里面的一个要用的哪个这里。这就作为这一个我们整个的一个开发的一个环境。大致是这样一个效果，这样子的话，其实就会非常方便的去做，去开发。因为我们平常。比方可能做到遇到一些需求啊什么的，那我习惯就是拉一个分支，然后就进行开发，开发完就把这账码提交。五分之就完成了。演完的话，那就再大概讲一下我们目前在西开发的一个架构图。嗯，大致是这样子的，就是可以通过一些。Get事件，或者说一些openpi触发一条流水线，然后就跑起来。我们。在流水线的配置里面理好，我们需要跑一个远程开发服务。然后这里就把它跑起来。

发起来之后呢，我们CI平台就做了两个事情，就可以把在构建机里面的这个服务转发出来，然后可以在浏览器里面去，或者这面进行一些访问，那这里会有一些健全的一些逻辑。着跑。大体上的一个架构是这样子的。嗯，最后这里再看一下我们一个近百G级别的一个仓库进行远程开发的一个效果，你可这里可以看到，其实这一个仓库其实是三到120多个区。那每次同步个线跑起来，准备开发环境，其实也就只有20几秒就能跑起来，然后这个27秒就是直接可以打开，我们打开个浏览器啊，然后进行直接跟开发的一个时间。那我今天的分享就到这里，谢谢大家观看。非常感谢卢家辉老师的精彩分享，接下来由腾讯安全云顶实验室高级研究员姜国龙老师给我们带来千万核心规模下的云原生架构安全与运营实践的主题分享，有请张国龙老师。

嗯，各位嘉宾，各位专家大家好，呃接下来由我来给大家分享，然后我们在呃云原生安全这块的一些个呃架构设计和一些个这种实践啊，我是呃来自腾讯安全云顶实验室的姜国龙。啊，我今天的分享主要分为三部分啊，那么第一部分就是啊，看一下在云原生的这样的架构下啊，那么我们呃整个的安全哈，那么它会有哪些的风险啊，以及啊这样的一些个设计，那么给我们的安全运营带来了哪样的一些个挑战啊，然后第二部分就是呃，介绍一下我们的呃一些个安全能力的一个体系化的一个设计啊，然后最后一部分就是讲我们在啊面向云原生服务哈，那么我们如何去开展相应的一个安全的治理，以及我们的一些个呃运营实践。

首先我们来看一下啊，那么在云原生架构下，那么我们啊，面临哪样的一些个安全风险，以及这样的这个架构设计，那么给我们的安全运营带来了哪样的一些个挑战啊，那么我们。根据我们的一些个调查哈，我们发现啊，那么呃在这个呃攻防对抗下哈，那么这个整个云原生，那么其实他所面临的安全风险哈，那么是呃越来越严峻啊，那么其实有超过一半左右哈，那么我们调查的这个实际的用户啊，我们会发现它是呃真实的遭受到了容器的一个攻击啊，那么同时在我们的一些个这种呃这种红蓝日日常的这种啊红蓝对抗哈演练中哈，我们也发现针对于与原生架构哈，或者是针对于容器这些相关的技术哈，那么所进行的这种攻击，那么其实也是啊，数量很大啊，那么包括我们在全网上哈，我们也会去做一些这样的一些个啊，这个安全的这样的一些监测哈，那么其实我们发现针对啊容器环境哈，那么所发生的这样的一些个攻击，那么其实它是啊，真实存在啊。

或者是现在啊数量哈，会越来越多。啊，那么在这样的一个情况下哈，那么我们呃，腾讯那么其实它在整个云原生的这块啊，那么它的产品体系已经架构哈，那么现在已经是啊，非常的完善啊，那么我们基本上覆盖了所有的哈约生的相关的产品和服务啊，那么我们在前段时间哈，那么也是正式的对外去做了发布哈，那么我们海量的这种资研业务啊，也已经实现了全面上云啊，那么规模也是啊，千万盒这样的一个很大的一个规模啊，那么打造了国内。

最大规模的这样的一个云原生的实践啊，那么在这样的一个呃背景之下哈，那么其实是给我们的安全带来了很大的一个挑战啊，那么比如说啊，对于我们安全运营来讲哈，那么我整个的容器集群里，对吧，我有多少个炮的有高权限哈，或者是假如说我的啊一些个pod发生了提前操作，我怎么知道是哪个业务对吧？然后我的这些个pod。好在访问API server哈，那么我知道这是正常的访问还是被入侵了啊，那么等等的这些个问题哈，那么其实是我们在原来的哈，我们进行安全运营的时候，那么其实是啊，这个没有啊，不存在这样的一些个问题的，或者是说啊，云原生架构上，那么其实是给我们带来了这样的一些个新的这样的一些个问题和挑战。啊，那么为什么我们会在云原生架构下哈，我们会。发出这样的一些个疑问啊，那么其实跟它整个的呃设计哈是有很大的一些关系的，比如说呃，在这种云原生或者是容器环境里啊，那么我们的工作负载哈，密度会变得更大哈么，工作负载的频率啊，也变化的频率哈，那么也是更高啊，然后呢，我们整个工作负载之间的这样的些个调用关系哈，也变得越来越复杂啊，那么这些个新技术，新架构，新模式它等等的这样的一些个新的东西哈，那么其实给我们的包括安全能力的建设哈，包括安全运营的建设哈，那么其实都是带来了啊重大的这样的一个挑战。

好，那么在这样的一个背景之下哈，那么我们啊，针对于云原生服务哈，那么我们进行了首先进行了这样的一个体系化的一个能力建设啊，然后来支撑那么我们的啊，安全的这样的一个治理和运营啊，那么首先啊，我们来看一下我们是怎么样去进行能力的这样的一个建设。啊，那么面向云原生架构哈，云原生服务，那么我们是啊，首先确定了我们的这样的一个安全体系设计的原则啊，我们在这里把它总结成是四大设计原则啊，那么第一个就是安全能力的一个原生化啊，也就是说我们啊，首先就是我们要在这种原生的啊，那么基础设施上哈，去实施我们相应的这样的一些安全能力啊，也就是把我们的这种安全能力去进行原生化啊，做到我们的一个啊启动及安全上云及安全哈这样的一个目标啊，那么这是我们第一个设计原则，那么第二个设计原则就是哈，啊也是现在啊，大家提的比较多的也就是安全左移啊，左移就是说啊，我们会去投入更多的安全资源和安全能力啊，在这个更早期的阶段啊，那么也就是呃，比如说在开发的更早阶段哈，那么我们去进行相应的这样的一些安全检测哈，那么这样的话，我们能够更早的去收敛哈，相关的这样的一些安全。

全问题，那么第三个原则就是呃，全生命周期的这样的一个安全防护啊么，我们会从开发到部署到运营啊，那么我们全生命周期的去融入到啊dev OPS的体系中哈，那么最终那么我们实现啊dev setos的这样的一个啊这个。呃，这个这个完全嵌入哈，嵌入安全的这样的一套敏捷的模式啊，那么最后一个原则就是啊，零信任的这样的一个架构啊，也就是说我们会采用零信任的这样的一个思路哈，或者是方法啊，那么去，呃，通过全面的这样的一个身份权限的管理哈，那么最终去做到啊，持续的一个检测和响应。啊，那么在这四大这个原则的这个指引下哈，那么我们啊，设计了整个的安全体系的一套框架啊，那么在这个框架里，那么我们是把我们的安全能力啊，那么我们分成了三个大的一个层次啊，那么首先就是呃，最下边的这个基础安全啊，那么基础安全其实是。

嗯，可以可以把它理解成是我们啊，在没有啊云原生之前啊，那么我们所进行的相应的一个安全建设啊，因为从安全风险的角度来讲，那么云原生其实它所面临的安全风险是我们在呃，这个通常意义上讲安全风险的一个增量啊，那么所以你在安全建设上哈，那么其实也是做一个呃，相对来看是增量的这个安全的一个能力的建设哈，那么呃，对于我们传统的，比如说像这种内核层面上的安全，主机安全啊，或者是从网络角度的挖哈，抗地哈等么等等这些安全能力啊，那么这也是必不可少的啊，那么这时候我们会把它归结到基础安全能力的建设这一层啊，那么基础安全能力之上哈，那么我们就会面向啊。云原生架构，它所特有的这样的一些个啊，这些个特性或者是问题哈，那么我们进行啊相应的这样的一个能力的一个补充啊，比如说我们这里把它分成了三块啊，那么第一个就是对于容器和编排哈，那么在这一层，那么我们去进行啊相应的这样的一个能力的建设哈，比如说一些基本的啊加固哈，配置加固，一些基本的这种隔离和身份管控，权限管控等等这些啊，那么再一层就是在网络，网络层啊，网络层呢，就是我们会去做这种零信任的一个网络安全啊，那么包括基本的这种网络的隔离啊，入侵检测哈，这种行为检测哈等等这些啊去解决啊云源生下的一个网络的安全问题啊，那么再一部分就是这个运行时的安全啊，那么包括典型的这种哈入侵检测，对吧？H hids类似的这样的这种入侵检测哈，包括一些个这种准入的控制哈，包括一些异常的行为检测啊，那么这是我们在运行时哈，也就是容器。

那run起来之后哈，那么我们去进行相应的这种系统层面上的这样的一些个检测啊，那么基础架构之上哈，那么我们面向云原生应用哈，那么其实我们主要是从两个维度哈，去进行能力的这样的一个建设，一方面就是这个软件供应链的这个安全啊，那么这里我们会更多的聚焦在这个容器镜像的这个安全的一个检测上，比如说这种镜像的扫描啊，然后一些这种。

啊，签名啊，然后包括一些这种安全的通信等等的这些，然后再一个就是啊，API安全啊，API安全其实啊，更多的我们是会关注在这种海量的微服务之间的这样的一些个API调用哈，怎么样保证我的这个API调用的这样的一个安全性，比如说基本的这种隔离哈，以及一些异常调用的这种检测啊，那么除了这个基本的能力建设之外哈，然后我们还会去啊，这个更。更多的哈去啊，因为我们讲前面的原则讲哈，我们是去原生化的，去实现我们相应的这样的安全能力嘛，对吧，所以我们也会啊，去跟我们整个云原生架构下哈，比如说像可观测哈，那么我们会去跟他做一个深度的一个融合啊，通过可观测哈，那么我们拿到相应的一些数据哈，去支撑我们去进行相应的这样的一些安全的检测和管控啊，那同时我们还会去做一些相应的这种安全治理层面上的一些能力叭，如说一些策略的管理，密钥的管理，漏洞的管理等等这些哈，那么去真正的去把我们的能力跟我们最终的治理哈，去实现一个这样的一个结合，最终呢，我们会把这些个东西统一的哈，去融入到我们dev OPS的这样的一个体系中哈，那么去实现我们这样的一个安全的一个闭环啊，这是我们在整个的安全能力的这种体系框架上哈，所进行的这样的一个设计。

啊，那么在这套设计之上哈，那么我们的呃，技术架构哈，那么其实相对来讲看起来还是比较简单啊，我们是分成了这个控制平面和数据平面这两层啊，那么数据平面其实我们是会去做基本的这样的一些个数据采集哈，以及策略执行啊，那么我们也会尽可能的啊把我们的这个啊资源开销哈，因为我们这个数据平面基本上是会运行在我们的业务的集群的里边啊，我们会尽可能的把我们相应的这种资源开销哈去降到最低啊，我们会把我们更多的这样的一些个决策性的哈，计算类型的这样的一些任务哈，我们会放在控制平面，比如说我们的一些异常分析，比如说我们的一些个这种基本的管控啊，那么最上层哈，我们会有强大的这样的一个情报啊，来给我们做支撑，比如说这种漏洞库哈，各种的规则库哈，那么等等的这些啊，那么这是我们一个啊，这个简单的这样的一个技术架构。

啊，那么最终我们会啊，基于这一套的技术架构，然后通过一个容器安全的服务，然后去把我们整个前面讲的这些个能力啊，去给它做一个融合啊，去给他做一个类似于我们可可落地可使用的这样的一个产品级的东西啊，然后去统一的实现啊，这种资产的管理，镜像的安全入侵检测等等这些能力啊，那么其实也是呃。

整体的流程哈，就是从控制台哈到agent啊，那么做这样的一个。做这样的一个这个这个部署哈。啊，那么最终哈，那么通过我们这样的一个容器安全的服务，那么我们实现啊，对于整个云原生架构下啊，容器的一个全生命周期的这样的一个啊安全的一个防护哈，包括从构建阶段哈，保证我们的镜像安全哈，从部署阶段保证我们整个的配置哈，保保保证我们整个啊运行环境的这样的一个安全，包括运行的过程中哈，那么去实现相应的这种入侵的检测，网络的隔离啊，异常的一些检测哈，那么等等的这些啊，这是我们在整个的呃，安全能力建设上哈，那么我们所。做的这样的一些个设计和实现啊，那么最终那么我们的目标哈，其实还是为了实现我们的安全治理和安全运营啊，那么最后一部分就是介绍一下，那么我们在这样的一套能力建设知识上哈，那么我们是如何去开展哈，我们相应的这种安全治理和运营的。

啊，那么首先就是基于这种安全服务，那么我们是从呃，这种方法论的角度哈，那么我们构建了全生命周期的这样的一套云原生的安全运营框架啊，那么这也是经典的这种IPDR模型哈，那么在这一套模型之下哈，那么我们去细化了啊，那么面向云原生的这样的一套架构啊，我们应该在每个阶段啊去做什么，怎么做，比如说在这个识别的阶段，对吧，我要去识别相应的我们的这种啊资产哈，包括集群层面上的一些资产哈，包括我们这个纯容器层面的一些资产，包括业务层面上的啊一些个这种风险哈，级别的一些划分，对吧，那么我们是比如说在防护阶段啊，我们会从系统层面上哈，去加固哈，那么安全的一些策略的配置啊，那么等等的这些哈，怎么样去配防火墙对吧，怎么样配袜服哈，我的隔网络隔离策略怎么样配啊，我的入侵检测怎么配对吧，然后我们会在防护阶段事前哈，把这样的一些个策略和相关的加固。

工作都做好啊，那么在运行起来之后哈，那么我们就会在检测的这个阶段啊，从系统维度哈，网络维度哈，包括应用维度啊，去进行全方面的这样的一个异常检测啊，那么当我们检测出来问题之后哈，那么我们怎么样处置啊，那么这个呃，相对来讲还是比较经典的一些处置方式哈，比如说我把你的这个pod啊，或者容器啊，去给你隔离掉啊，或者是直接Q掉啊，那么。除了这种基本的处置之外哈，那么我们还会去进行一些这种相应的一些个告警分析哈，确定一些路径啊，那么其实我们还是会做一些在做一些溯源类的工作啊，那么这块结束之后哈，那么就是相当于是我们的一个修复阶段啊，那么修复阶段一方面是解决我们当前存在的问题啊，另一方面也是啊去还会回到我们的这个事前的这个防护阶段，还就是说我们比如说通过我们发现的一些个啊问题哈，然后我们在这里边去完善哈，我们补充完善我们这块的这个，呃，前期的这样的一个安全策略的一个配置哈，那么保证我们之后这样的问题不会再被啊入侵了。

啊，那么这是我们的一套运营框架啊，那么基于这一套运营框架，那么最终我们是实现啊整个云原生安全的可观测性啊，那么我们包包括哈，那么事前的这样的一个风险的可观测哈，那包括啊运行过程中哈，那么整个威胁的一个可观测啊，那么最终哈我们实现啊整个持续的一个安全的一个治理。啊，那么下面我通过这个具体的几个例子来讲一下啊，那么首先就是这种镜像的安全啊，那么镜像安全其实啊，它是一个呃，从原生角度来讲，它是一个相对来讲比较新的一个问题啊，那么这里我们会去从呃像这种基础镜像这个维度哈，然后我们去收敛相应的镜镜像的这样的一个安全风险啊，因为我们知道这个在整个仓库的这个角度来看啊，那么镜像其实它是一个森林的这样的一个存储结构啊，那么基础镜像的安全性其实啊是镜像安全的一个重要的来源嘛啊，我们把根的这个问题解决掉啊，那么其实对于整个呃仓库内的镜像哈，那么其实收敛起来，那么就会呃相对来讲容易一些。

啊，那么除了解决这个呃，这个基础镜像之外哈，那么另一个就是哈，我们要通过我们的这种镜像扫描能力，对吧？我们去对镜像中的相关的一些漏洞哈，然后配置包括一些密钥，敏感信息，病毒木码等等这些啊，我们要去对它进行一个啊全面的这样的一个安全检测，去发现哈，相应的这样的一些个问题啊，再一个就是我们在镜像安全这一块呢，我们还会呃去。

呃。寻找这样的一个契机，也就是说在像去年的这种重大漏洞的这样的一个契机哈，那么我们会把这样的一个呃事件哈，去作为一个抓手哈，然后去呃。能够通过这样的一个事件更好的去推动啊，我们去啊，在发现问题之后去解决问题的这一个步骤啊，那么这也是我们在啊整个镜像运，镜像安全运营这块，我们采取的这样的一些个类似于我们可以管它叫小技巧吧。啊，那么除了镜像之外哈，那么下一步我们就是通过这个安全的基线的检测哈，然后通过安全基线的这样的一个能力，然后我们去定期的哈，对我们整个所有集群，包括像K8S层面上的，包括主机层面上的啊，镜像以及容器workload层面上哈，那么我们去进行相应的这样的一个配置的检测哈，那么去保证哈，那么我们当前的已知的这样的一些个攻击面的这样的一个收收敛。

啊，然后就是我们还会有通过一些集群安全的这个能力，然后去同样解决呃，K8S这样的一个，呃，除了配置之外的这样的一些个问题，比如说组件的这样的些个漏洞哈，以及workload的这样的一些个啊，这种配置的检测啊，同时还会有这种workload的这样的一个准入的控制哈，那么保证那么我们在整个。集群底座层面上的这样的一个安全啊，通过安全集群安全的能力，以及我们极限的能力来去做这样的一个保证。啊，再就是在运行时这块哈，运行时这块其实呃，可能就没有什么过多可讲的了哈，其实就是对啊，整个针对容器层面上的这种入侵事件哈，去做监控哈，那么啊去实施上报相应的这样的一些个攻击行为哈，然后我们啊去做相应的这样的一些处置啊，那么这里的处置前面有介绍到啊，一方面我们会去啊从网络层面上哈，去做一些个这样的隔离的处置哈，那么再一个就是从系统的维度哈，我们也会去对一些这种高危的入侵操作哈，那么我们可以去自动的去做一些拦截啊，去保证把我们的这个啊这种攻击的风险哈，或者是啊影响哈，我们给它降到一个最低啊，那么最后就是在这个网络的层面上哈，那么我们去。

呃，这个对啊，整个的啊。微服务啊，那么去做一个这样的一个网络的隔离的一个设置啊，因为我们知道在啊，不管是docker这个维度，还是KBS这个维度哈，那么基本上它在网络层面上的这个隔离和管控的这个能力哈，相对来讲还是比较弱的，而且它在设计上哈，包括它workload这个设计哈，那么其实我们传统的这种基于IP哈，那么去进行相应的这种网络啊，访问控制的这样的一些策略的配置，其实也是啊不现实的哈，那么所以我们是基于label哈，那么去对整个的啊微服务哈，那么去进行相应的这样的一些个隔离策略的一些配置哈，那么保证啊我的一个零信任的这样的一个网络啊，那么比如说我去可以原生的哈，去支持K8S的这种network policy啊，然后在多种的这个网络插件之上哈，那么我们去做更好的这种。

隔离策略的这样的一个管控哈，那么保证我啊在。我在可以在不同的这样的一些个啊集群哈，因为我们会，因为本身我们的集群就是会各种各样哈，那么大家在尤其是在网络哈，那么它的各种的这种定制化的东西又比较多哈，那么我们也会尽可能的哈，去能够支撑多种的这样的一套网络架构哈，那么去实现哈，实施我们的这样的一套网络的隔离的一个能力。啊，那么以上就是呃，我的一个分享啊，然后感谢大家。非常感谢姜国龙老师的精彩分享，下面进入第三环节成长场主题分享，第一位分享的嘉宾是腾讯文档基础架构专家邓芝莹，他给我们带来腾讯文档与人生之路的主题分享，有请邓志颖老师。

大家下午好，我来自腾讯文档，今天我给大家分享一下腾讯文档在云延伸实践上的一些探索和经验。首先分成五个部分。首先，先简单介绍一下腾讯文档这个产品，然后评估一下腾讯文档在上云之前和之后的研发体系。后面是两个重点，分别介绍一下腾讯文档在上云过程中的一致性建设和C实践。最后总结一下腾讯文档的业务价值和整体数据。腾讯文档是一款可以多人随时编辑的在线文档工具，拥有文档、表格、幻灯片等众多功能，同时打通了QQ、微信等多个平台。

在上云之初，我们我们通过这五个方面进行了评估，首先是开发框架，开发框架之前非常混乱，C总共有四个语言，七八套框架。看，混乱的开发框架给排查定位问题带来很大的困难。监控日志调用面都无法对齐，而且不一致的体系下完全没办法做到。自动化和和标准化，流水线和自动化测试是几乎没有的，完全靠纯手工，所以效率非常的低。然后呢，部署环境也是比较混乱，测试环境都是混合部署的，每一个服务都会可能出现相互覆盖，相互影响的问题。然后发布平台是基于物理机和虚拟机的一个二进制打包发布系统。没办法做到弹性扩收容，资源利用率也不高。所以我们在上云之前，首先要需要解决的问题是一次性建设，建立统一框架的一个代码大仓，然后实现everythings code的自动化流水线、自动化测试、多环境以及发布平台。

一致性建设首先需要建设强一致性的代码大仓，作为单一真实信息源，统一版本，方便代码搜索、复用和重构整个文档所有的代码都在同一个get大仓里面。包括客户端和后台，以及一系列的cicd脚本。文档所有的信息都能在这个大仓里面检索到。由于大仓里面不仅仅只有后台多个语言的代码，还有客户端代码，所以我们采用统一构建以应对跨语言、跨平台等场景，以及更好的执行依赖分析和变更影响检测。

由于北走他的上手门槛高，使用人数少，所以我们专门成立了北走先锋队，输出背走最佳实践使用指南，并且积累了很多的常见问题，以供开发同学参考。在开在上云之初，我们的开发框架是非常混乱的，同一个团队就有七八套框架，七八种协议，不同的协议给开发联调带来了很大的麻烦，需要要去解析它的协议，所以我们急需统一框架TRP机构是腾讯自研的。微服务标准框架微服务RPC框架。功能非常强大，然后插件设计的非常灵活，可以支持公司内部所有的系统。呃，使用范围也很广，我们基于TRB购这一套插件体系，也开发了很多腾讯文档的插件，所以我们进行了一次大刀客服的重构，将T腾讯文档所有的后台服务几乎全部重构成了TP客服务。

TM，它的核心包括RPC框、RPC能力以及服务治理能力，包括服务发现、负载均衡、过载保护等等，其他的模块都是插件化设计的。同完框架以后，我们需要建立强一致性的代码。首先通过建立有质量的Co review机制来统一规范，以此为核心提供代码CR服务，建立部门级的三级履热机制，然后挖掘CR骨干，沉淀CR文档，分享代码可读性和可测试性知识。每一个MR发起的时候都需要经过三级的旅用，每一级分别侧重不同的关注点，层层把控业务逻辑、代码架构和可读性。

然后我们最终通过一个代码评审指南，沉淀一个标准的很权威的一个规范，然后以供大家同学参考。最后我们通过脚手架工具来保证服务的标准化、规范化和自动化。在开始起初没有服没没有脚手架之前，开发一个新务的时候，需开发人员需要先手动的拷贝老的服务代码，然后再三三改，改成新的空空服务。从零到一创建一个新务需要耗时将近一天的时间和14个步骤。所以我们快速建设起了脚手架工具，屏蔽细节，简化流程。从源头减少，从源头减少错误的发生，从而一键生成标准化服务。然后下面这一块是一个重点。

我们充分集成了公司成熟的基础设施，深度实践实现I自动部署，从需求编码、构建、测试、发布、部署、运营、监段监控等各个阶段实现了基本实现了everything s code。首先是流水线。腾讯文档使用orange CR进行流水线的配置与管理，并且将流水线配置代码作为项目源代码的一部分放在代码仓库中，以及CR code项目源代码作为一部分数量可控，版本可追溯，然后清晰一读，便于多人共建与长期维护。我们将流水线的各个步骤通过配置文件的方式提交到代码仓库中。从从左边这张图我们可以看出这个流水线的具体步骤是什么，首先是先执行的代码编译和测试，然后是执行代购源的代码检查，也就是代码规范检查，然后是BVD流水线自动化测试。

每次发起MR的时候，就会自动触发流水线的，流水线的执行并且开始，并且会通知到群的，并且会通知到发起的负责人。实时通知他的结果。长久以来，测试环境相互干扰，相互的干扰测试环境不稳定，然后等环境开发，长期花很长的时间在环境准备上，产品则需要花很长的代价去配置环境体验，体验产品的时候，在多个需求并行迭代的情况下，这种效率的损失将会极大的放大，严重影响项目的迭代速度。所以我们开发了这么一个持续部署的一个多环境，包括四套的基础的、稳定的环境，以及无数套的特性开发环境。

首先，每次需求开发的时候，我们会新建一个开发分支，然后每一个开发分支对应一个临时的特性环境。在开发需求的过程中，都在这个特性环境里面进行联调和测试，当测试完成以后，开始部署到sta环境，Sta环境既是我们内部员工的环境。然后在内部员工环境里面验证一段时间以后没有问题，才开始进入环境。环境是外网的1%的流量的外网用户。然后外网用户灰度一段时间以后啊，才正式进入环境生产环境。当这个都全部稳定以后，我们的这个特性环境就可以销毁了，那个特性开发分支也可以删除了。基础设施及代码自动化部署则是以则是以get为核心思想，将码配置作为系统的唯一来源，Orange CI telephone及s ke进行I级别的一个自动化续的部署。

首先在C阶段开发，写完代码以后提交到代码库，然后开始触发OCR流水线进行编译服务，然后构建都可镜像，然后再推到公司的一个镜像镜像源里面。开发要开始发布服务的时候，CI的流水线就CD，流水线就会开始拉出可发布。可发布制品。然后调用telephone的插插件开始去点开始调用T呃底层的s t ke的API实现发布制品的个容器发布每个环境对应一个环境，实现环S布制品的详细内容我们通过telephone的一个语言写在代码文件里面，提交到那个环境分支上面。

监控后台文档后台广泛使用天机格作为可观测性的基础设施，天机格实现业务服务的监控告警和自定义面板等代码设置。我们将告警这些配置全部代码化，写在配置文件里面，提交到大仓里面，比如主调异常率大于5%就就开始告警，以及这个错误码对应的type是成功还是失败，已经还是逻辑失败等等，全部设置到配置文件里面。好，下面总结一下我们的实践过程。目前文档总共上线了200多个微服务，资源部署在十几个集十个集群，总共400多个，工作负载上云三万多盒。我们通过一性建设和实践，实现了研发、构建、部署、运营等多个阶段。

云延伸自动化运维。首先在研发阶段，通过大量的工具来自动化研发过程中的基础动作，提升开发效率，然后沉淀的各种组件工具规范，切实落实CR制度啊，坚决执行一致性建设。在构建阶段，我们建立了低门槛的构建工具，然后深度实了CI code，然后实现了分级的自动化测试开发，自己负责测试。在部署阶段，灵活的多环境隔离与切换系统，实现IC级别的自动化持续部署，动态的资源的高效交付，提升资源利用率，可以节省成本，在运营阶段，深度实践监控告警C加强运营阶段一个质量管控云原生体系下服务获得的快速扩容，弹性伸缩能力啊抗压能力增强，自动化运维，高可用运转。

好，我的分享就到这里了，谢谢观看。非常感谢邓志颖老师的精彩分享，接下来由招商金科pass平台研发部副总经理黄龙华给我们带来招商云云原生平台赋能产业转型时间分享的主题分享，有请王文华老师。大家好，我是来自招商金科的黄龙华，我这次分享主题是招商云营商平台赋能产业。转型实践。整个分享室外以外，一一批物流核心系统有去划散。有机化改造上永久。我整个分享分个有有三部分，第一部分是招商云生平台整体建设成果，第二部分是外运一批物流核心系统有容器化改造上云，第三个部分简单介绍一下招商云生平台的未来规划。首先我们先开始第一部分就是招商云营商平台的整体建设成果，呃，从行业呃，形态来看来看，招商级集团是一个产业多元化企业，板块众多，涵盖有港口公物流啊海，海工制造以及光贸易等等领域。

中心化的云计算平台难以满足集团产业边缘侧控制类和操作类业务系统三云需求。为实现全集团云上集中式和云下分布式的数字化基础设施大一统，需要打造云边端一体化的分布式混合云，满足集团多元化、多样性的产业应用需求。从规划来看，就是目前有深圳市中心和地中心两个中心云，然后香港A中心作为那个海外的汇汇聚，还有规划中的一中心作为那个区域云，同时引入了公有云作为那个区域云和边缘云。第二，其实从那个技术角度来看的云原生技术是以那个云计算的再升级，是云计算作为通用变革性计术发展到第二阶段的产物，也是当前云技算行业行业主流的技术方向。以KBS为核心的云基云原生技术体系，向下可以屏蔽异构基础设施的差异性，向上可以承载多样化的软件应用负载，向外可以扩展至终端边缘错原生与一套技术体系支是任意负载运行意任意那个云计算，从而解决了传统企业长期面临的分布式异构基础设施难题。

招商云原生平台是以应用为中心，构建云能力，打造一款云原生操作系统，向上支持各个板块基于原生架构的板块差异化系统。从无状态应用到。和企业核心应呃企业核心应用到数据技能应用。我们在规划和建设过程中，是立足于招商局产业实际现状和需求，基于先云先先进的技术架构，以自主研发为主，构建云边端一体化分布式原生平台，实现集团研发过程、技术标准和那个应用标准的统一，打造集团覆盖中心云、边缘云终端设备和对一体化云生应用管理平台。

建设面向未来的数字化先进基础设施平台。最上在最上面那个资源城市通过分布式混合云统一管理底层基础设施，提供以面向资源为中心的呃编排管控机会优机会优化和运监控运维中间的应用运运行时程。通过那个K8S容器技术，统一云操作系统，屏蔽底底层资源差异。将底层异构的基础设施封装成标准化的应用开发交付服务能力和全算命周期管理能力，通过以应用呃以应用服务为中心的跨平台，多举行自动化。自动化管理调度层，屏蔽底层不同基础设施的差异性。从而实现。

就能实现那个应用的一次开发，构建全平台，任意部署和自由迁移全流程，那个统一管理，必须将开发部开发和部署的那个权杖敏捷。企业数字化转型还有一个重要方面就是研呃研发一体化。为了支持全集团的那个研发商云和那个提升那个集团的研发效率，招商云营商平台精神，云原生时代的以用为中心的产品设计理念，践行那个第二敏捷思想，基于云生技术自主研发软件应用全生命周期管理管理平台实现应用，从创新想法到开发措施到交付上线、运行维护和运营。和运营分析全流程、全自动化的云人生应用开发运行管理一体化平台，通过数据驱动来提升全集团的那个研发管理，提升那个全集团那个。

研发效能。简单介绍完招商云商品的那个建设成果之后，接下来分享一下那个一批容器化的实践。关迎一聘平台致力于拼向货代公司以及相关方提供一站式、端到端、线上和线下的一体化的物流服务和解决方案。目前已经在全国共设立了14个中心窗，30个多个那个卫星窗，逐步实现通过远海、港口等口岸单位带动中心窗业务发展，并形成南北贯穿东西中型的业务战略布局，构建了点、线、面一体化的国际极品网络。一品主要由以下四个核心系统组成，第一个是那个速韵达，速韵达主要是商业模式创新，探索那个拼向交易的公共撮合模式，为客户提供订单交易、支付保、保险、金融、数据分析和系统信息等多方面增值服务。第二个就是一站通，统一对外的那个客户服务系统，提供一个对外的公共窗口，让相关的上下游企业可以方便通过系统获取各自各自关注的信息，除了活跃那个客户外，还有运输公司、报关公司、政府部门、海关、商人等，后续还我后续还会介入那个码头和船公司。

第三个是CF操作中心，那么C操作中心是操作中心，是那个外一频业务模式的主要操作系统。那么主要是针对那个面上那个窗户端的对该系统进行重构和提示优化，目的是提升那个业务线上的操作体验和业务操作运行效率。线象化和信息化共同支持和推进外1P业务模式在全国范围内的复制推广。最后一个是那个cfs运营中心，CF运营中心是实现业务操作中心化和规模化，为标准化产品提供统一的后台管控和支撑，实现业务的那个全网管控。

我们根据一聘业务特点以和需求，然后结合招商云的规划，那么根据那个小城端大后台呢，整整体架构进行改造，吉平总部系统主要是一站通系统和运营中心系统。一家人通系统是统一的对外服务窗口，那么为客户、供应商等外部用户用户提供网上订单、包货、交易可视化等标准化服务，满足那个客户对更高透明度和更高效率的线上要求。进而运营中心系统是实现1P业务的全网一体化、标准化的运营管控，主要是将业务集中和资源共享，将那个系统功能上升到那个那个集团总部，那个集品总部汇聚那个集合成一体化、集中化的系统管控平台，这是大后台或者叫强后台部分。

极品总部系统和那CF操作中心，主要是将现场业务下沉到那个各个业务分中心，专注于现场那个业务操作和那个服务。极品总部系统和业务分中心那个cfs系统从职能定位和功能上完全不同，是相互协同关系，以小前端和大后台的模式搭建了平台，在分布式架构体系同时实现了外1P业务的线上和线上的一体化操作。根据总分这个两层架构，我们是一批系统采用了那个分布式部署，那么管理总部系统部署在招商营地中心，这个中心营。分中心业务操作中心系统就就近部署在那个腾讯云。那么在数据方面，就是结合业务拓展，各分中心业务数据，通过数据走向同步到那个中信云。一方面是作为那个各个分中心的操作系统，那个灾备环境，比如华南，华南操作中心出现问题的时候，可以快速切换到低中心的那个，呃，低中心对应的那个超在备环境。

那么从而减少对那个现场业务的影响，提高整体的系统的那个可用性。同时，业务数据也会归集到大数，归集到大数据库，为运营管理系统提供实时和离线的分析结果。我我为我极品总部那个实时掌握底层那个超额应个业务数据，要加强总部的那管控提供那个条件。采用分布式部署之后，如何打通那个各个业务分中心到那个中心云的网络，呃，成为一个问题，我们是基于招商云已有的物理专线。结合腾讯云联网能力，快速打通各个分中心，到中心云的那个通道，集成业务的那个趋势扩展。目前招商云这两个中心云，市中心和地中心和腾讯云都有专项，然后需要搭建那个过分中心的时候，只要通过是只要通过我云联网，然后通过这些，通过这两条专线和那个中心云。

那个打通就可以了。然后个一方面就是大块两个分中心的建设，呃，另一方面就是也提升两个这两个中那个两个中心的专项的利用率。在云端管理、边端运行、小前端大后台的产业互联网时代的主流应用分布式架构上。一个应用横跨多个数据中心，横跨多个容器集群，如何快速分发这个应用，以及如何有效的对这个应用进行。进行统一的运维，那成为一个痛点，为了解决这个这个通用的问题，招商云自主研发那个云边端异构多集群分布式应用的中心化统一分发广管理平台，实现云边端多样化的分布式应用在云中信云端的一键式自动化分发和已部署。

以及分布式应用的国控，那个滚动升级和远程监控运维。通过应用模板和容器应用市场呃，为应用提供多云场景下的那个应用分发和和应用复制，应用迁移能力。通过统一应用容器日志，统一个容器监控呃，为应用提供混合云场景下的那个统一应用呃，应用监控同时提供统一统一的那个。门户为应用提供那个运维？这样减少了那个到现场，或者是通过那个。不切换不同的云云呃云操作云门户来来进行那个运维，大大降降低了运运维出错率，提升那个整体的那个运维效率。最后简单分享一下那个一片容器化的效果。

关于一批平台在人员深化之后，在交付效率、稳定性、资源利润上得到了较大的提升。首先交付效率上面，由于前个前面是采用那个虚拟机部署改，有的时候还需要到现场进行那个操作。改造之后，采用了第二次研发平台，统一管理中心云和边缘云的应用版本，构建骑士集成和骑士部署流程。同时由于采用小前端大后台架构之后，团队分工明确，提升整体交付效率大概30%左右。第二，在稳定性方面。整个改造按照云用生最佳实现改造应用，比如添添加健康检查，然后应用需要支持优雅关机，然后还有那个增加那个自然，那个自源限制等，充分利用了那K8S自源能力，再进入监控日制调用量等，结合云端统一那个运维和管控，整体稳定性，稳定性提升大概20%左右。

最后一点是在自然利用率方面。那么由于系统全部呃，全部上云了，减少那个肌间机房，同时利用了云原生弹性伸缩的特性，根据实际负载动态调节那个中心云和边缘云业务。业务应用实例数，提升整体资源利用率大概40%。最后一部分简单介绍一下招商云商平台的未来规划。随着K80生生态以及那个边缘设施的发展，那么K80版本越来越多，同时也出现了那个基K80的容器发生版本和衍生版本，比如open变容器K3S等。我们以K8S为中心，设计规划一套放容器多执行管理平台，管理K8S多个多个版本，以及那个各个衍生版本，打造招商云统一的原生管理控制平面。

对于设置版本会做完全兼容，那也就是对于那个K80各个版本会做兼容性完兼容性测试，对于open那个发行版本只通过K8API进行集成，支持双数版本并做兼容性测试，也就是只会做OCP4.84.10做兼容性测试。对于库这些衍生版本，那么既通过KAPI集成常规功能会保证，其他功能需要在业务证中保证。我们前期规划了容器多执型管理，市面上pass平台化的应用市场中没有开放接口。放容器。多集群管理不仅仅考虑pass平台自身使用，还要开放接口给其他产品使用，同时也考虑API接口的兼容性，因此规划了多集群管理网关，通过该网关实现不同版本的K8SAPI统一管理，向上支撑用户技术门户和管理运营门户，为用户提供统一的标准能力，同时支持业务自定义的。

集群管理。从技术角度来看，向上开放标准的K8API，其他信息通过的来补充，向下兼容1.18以后的所有K8API。中间通过那个配置处理不同版本的那个差异。最后，在应用生态建设方面，我们将那个应用市场作为招商云应用的统一入口和基础平台，将DOS开发者云原商运行时基础应用和中间件全部迁移三家级应用市场，同时将大数据服务、人工智能等产品三家应用市场。从而形成那个平台的核心能力，支持业务，业务应用和外采应用，基于平台的建设建设工作。琴电，琴电集团内部行业的能力，引同时也引进那个外部优秀能力，形成一个真正的赋能平台，确确实实实赋能各个板块的那个。

产业，呃，产业转型。我的分享到此结束，谢谢大家观看。非常感谢黄文华老师的精彩分享，下面请英特尔高级软件架构师冯小天给我们带来英特尔助力服务网络安全的主题分享，有请冯小天老师。大家好，我来自英特尔CESG，那现在主要负责嗯英特尔呃，原生以及安全相关的技术架构，那这次分享主要想介绍一下，嗯，英特尔在服务网格安全这部分做的一些呃性能优化和技术实践。整体上大概会分为三个部分，那第一部分主要是介绍，嗯，服务安全，网格安全一些，嗯，一些基本概念，主要是一相关的一些安全架构。

那第二部分主要是介绍呃，英特尔在艾这台服务器上做的一些安全相关的一些呃，软件结合的性能优化和嗯。功能扩展。第三部分主要是介绍英特尔和嗯，在。应用这些软件优化和新特性去致力于呃优化辅网格安全。在这边做的一些技术实践。那主要包括一些性能优化，还有SCS的一种密钥保护的方案。首先会简单介绍一下服务网格安全的一些基本概念。那这里边这张图是来自于一那个官网的，那主要是一些整个安全理念的一个介绍。那。从单体应用，就是在云原生时代，从单体应用拆分成非服务之后，那其实给整体的服务带来了很大的开发运维效率的提升，包括系统稳定性的提升。

嗯，这是呃为服务带来的一些好处，那其实。这里边因为这种微服务架构的改造呢，那个原来传统的那种通过本地调用的这种连接方式，就变成了基于网络的API这种接口来调用，那其实对网格内部的这种业务业务其实会带来一些安全方面的风险。那整个一四的安全目标是，嗯。应用程序代码还有基础架构、基础设施，无需更改，能够提供默认的安全能力。嗯。它能够与呃现有的安全系统。集成提供深度防御的能力，那能够在嗯。不受信任的网络上构建安全解决方案。那其实整个呃安全有两大核心的功能，那第一部分是说嗯，在无无代码密的情况下实现流量的加密，那另一部分主要是所谓的3A，就是认证授权和审计功能。

那一的这种3A其实是在呃，现有的安全协议和标准之上的那些个标准，包括了双向TLS，包括GWT和open ID这些。嗯，通用的功能，那接下来介绍一下一四安全的整体构，那其实从这张图上可以很清晰的看出来，一四整体的思是在网格内部通过MTS，就是双向TLS提供。嗯，加密流量，流量加密的能力，那在网网格外，除了MTS以外，在这上是通过GP去提供用户的就。来源，身份的验证。那刚才提到了MTS，那为了提供这种呃业务无需改造的这种呃加密连接能力，那这里面牵扯到呃服务之间的这种证书管理。平台一直整个的证书管理，就像这个图所示的，嗯。

因为这种作为一个赛卡，它发起密钥发起发现的服务，那那去通过。这这种收到呃来自的请求以后，会生成私钥，然后并且向D去发起嗯，证书签名请求，那e sod收到这个请求后，通过外部的CA去生成签发证书，并且把相应的证书返回给A会。把私钥和证书一起返还给，那这种情况下，整个service的这种证书签发就已经完成了。那。刚才提到的3A这种安全功能，呃，第一部分是说A的认证功能，那它主要有两部分。第一部分是呃，服务和服务之间的，然后它是基于双向TS的这种加密的传输认证。另一部分是面向请求的，它其实主要是面向最终用户的一种验证，那它是基于T的这种请求的这种验证功能。

然后一思也支持，就是授权管理功能，也就是我们常说的访问控制，那这里边访问控制它的作用范围可以是整个麦的级别，就是网格的级别，那也可以是整个呃命名空间的这种这种级别，也可以是特定的工作负载这种级别。那具体的访问控制策略是由三部分组成的，那它包含一个选择器，呃，具体的动作就允许啊，或者是拒绝，那还有相应的规则列表。然后近期其实一泽社区也开始支持，呃，正则匹配这种，嗯。防控的策略。接下来我会介绍一下英特尔艾斯列处理器上的一些新的安全特性。这里面。主要是艾在传统的aei这种加速指令集上，嗯，增加了AS512的嗯，一些加速的新特性，那主要是包括了向量化的，就VEAES，向量化的AES包括嗯。

一些大数计算，还有嗯，GI指令，那它基本都是基于上一代的这种指令进行一个向量化的扩展，提高单令的并行能力。那它可以作用在公钥加密的场景。还有数据传输的这种加密的场景，那还有这种哈希的这种这种场景，主要是这三类的这种性能优化。除了刚才提到的这些，呃，指令集的这种，呃，新指令集的一些优化，英特尔也在软件层面做了大量的这种，结合这种新的指令机，嗯，在软件层面做了大量的优化，那第一部分主要是马buffer，也就是我们所说的多缓冲区的优化，那它本质上是把原来串行处理的这部分，嗯。能力变成异步的并行化去处理，提升整体的，嗯，这种算法处理的性能。

然后还有一部分是呃，函数拼接优化，就是传统的也是两个串行的执行的那个函数那。把它切成小的这种。然后能够拼接在一起来加速它的整体的执行，那对CC啊，或者是MD这种场景可能产生较大的性能提升。Int特在那个S的机器上也支持，呃，SG就是软件防护扩展，它能够帮助保护敏感的这种代码和数据，嗯，满足这种主流工作负载场景的需求。他其实是在内部建了一块飞地，那这块飞地的那个。内存基基本上是完全加密的，然后。嗯。未经过授权访问这部分内存，它其实是嗯拿不到嗯详细的这种数据的。

那即使是说这个机器被物理上呃破坏了或者侵入了，那这部分数据也是完全保保密起来，然后不能被恶意用户去访问的。嗯，接下来主要介绍一下Intel尔在呃，艾在机器上做的这些软硬件优化，怎么跟服务网格安全的一些功能，嗯，安全功能的引入对性能会产生非常大的影响，嗯，Service ma来说，它的整个安全性能主要来自于两部分，那第一部分是双向TS认证引入的。第一部分是TS握手的这部开销。那另一部分是整个请求加密的这部分开销。那认证策略主要是来自于正则匹配这部分性能影响。Intel尔在艾CPU上，嗯针对加载密，还有正能计算做了大量的优化，那相关的优化，呃正在逐步的，嗯推推给一和另一方面在搜那里面也存在大量的这种呃隐私数据，比如说各种密钥，那这种密钥怎么保护起来，尔也有一些技术实验，那基于S去为这些设备提供。

为这些密钥提供安全保护。那第一部分主要是嗯。在一思场景里面，呃，正则表达式，嗯，存在大量的使用，那它主要是在请求路由和访问控制策略中。那这些场景都是通通过智能表达式来去进行径啊，或者是cookie啊这种匹配检测，那目前U使用的是嗯I兔的正则引擎。那英特尔其实在政治引擎领域，嗯。通过大量的这种高效算法的呃优化，还有CD指令的使用，嗯，重新设计了正则引擎，那嗯哈量引擎其实在2015年，嗯英特尔已经开源出去，那目前在安全领域，比如外部防火墙，然后申包检测，然后入侵检测系统，包括入侵防御系统都已经在大量使用，DPDK已经。

成熟使用了很多年，那整个的整个的引擎的稳定性和性能是非常好的，那。它其实相比I兔来说，在多模匹配，流失匹配，还有嗯多智能表达式的场景，嗯不管是延迟还是处理量都存在大量的优势。嗯。英特尔其实已经将因外的呃哈斯政治引擎。那这部分改动提交了给社区，嗯，当然目前默认还是I，如果有需要的话，可以调整成。那这部分改动其实需要做一些改动。刚才提到的呃，整个的MTS的引入会给呃。

虽然提提供了呃请求加密的这种这种优势，但是它其实带来了性能上的影响，那第一部分主要是TS的这部分影响，那TS握手阶段是使用非特性加密技术来。协商出一个绘画密钥，然后在数据传输阶段会使用这个绘画密钥进行数据的加密，那这部分主要是对称加密的事情，那第一部分非对称加密，其实英特尔也在尝试说通过呃，之前提到的多缓冲区指令技术，就马T巴法技术来集中批量的异步去并发处理这部分请求，那像这个图所示的那。我们把每不同连接的R请求，然后放到呃一的这个buffer里面，那部分buffer的内容，嗯。超时达到一个一定的时间，或者是八分满的时候，会触发一次批量的请求，那这种情况下来提升整体性，整体并发的访问能力和性能，嗯，那巴巴巴支持在open s SL、包SS还有N的和DPDK其实都已经嗯包含了这部分优化，那在包瑞SSO这种场景，因为是通过嗯嗯。

私钥的provide来来进行一个异步的处理，那这种这种场景下，嗯，SL相当于说嗯。异步的来来，把RC相关的这种请求放到嗯，Buffer里面，那当整体的。RC这种握手完成的时候再回调返回给呃因外的T的上下文，那整体的这个主要是比较适合在英定位这种场景，它处理大量的这种新建握手连接的这种场景。这部分改动，呃。已经提供给了社区，就现在的，呃，可以通过这个MB是要provide的来进行嗯，对应的优化。

那除了刚才提到的这部那个非对称加密的优化，那在配的场景，其实我们有大量的这种对称加密的这种。呃，性能开销，Intel尔在机器也有了向量化的AES支持，那这个图上主要讲的是传统的AES的场景。那主要。A指令主要支持128比特，呃，192比和256比特的这种算法，那在S上机器我们做了一个向量化的这种优化，那它最多可以支持四个128里的的这种ES指令并行的去处理，那最好的情况下它可以其实可以获得整个四倍的性能的提升。嗯，目前支持的加密套件主要有ae e CTR cb cag cm和a cmi，那现在主流的，因为默认使用的这种加密套件是E128GCM。

嗯。Open s SL已经包含了那个VEEES的指令级的优化，但是包SSL这部分，因为我默认使用的是包SSL，那这部分改动我们还在推进社区去支持相关的这种合并相关的改动。暂时还没有，呃，合并到社区就是如果有兴趣可以。去基于openl这种态去做一些调整。那刚才提到了斯曼里面其实存在大量的这种密钥，那第一部分主要来自于呃。CA这种，嗯。密钥，嗯，第二部分是来自于嗯，双向T认证，那服务和服务之间的这种双向的密钥，那第三部分是做ink的场景，它可能需要呃保存大量的外部那个服务应用的这种密钥。那这些其实在，嗯。Ma内部都是铭文保存的，那其实在麦内部可以很轻松的去获铭文的，获取这部分密钥，那通过这些密钥我们可以呃，很容易的去。

不同服务的这部分，嗯，请求做解密，那其实对这个安全来说，就对麦C内部来说，多租户的场景可能会有一些安全的风险，那Intel在这部分也在尝试，因为STX对这些，呃密钥做一些保护的事情。那主要有三部分，那目前完成的主要是C这个密钥的保护那。英特尔主要是引入了一个外部的，嗯。的，那他来支持基于S设计了一套呃证书的签发保护机制，那只有嗯经过访问授权的这种请求，才能够去拿到具体的这种呃C的密钥。那未经授权的这种程序，其实看到这个这部分密钥都是加密的，嗯，这部分改动其实已经做一个外部的服务开源出去了，那它天然支持多CA，那通过是外部斯曼一个外部的艺术人来支持的，嗯。

另外就是呃，作为一个赛卡场景，那MTS就是双向TS里边这部分密钥，嗯。英特尔已经有一个初步的整体的设计方案，包括架构设计，那这部分已经提交给英沃设区，嗯，还在讨论整体的方案，那方案差不多会投入一资源去进行开发，那这块暂时还没有完成。然后另外一部分是作为场景，可能保存了大量的应用程序的密钥，这个可能来自于嗯。比如像云产品是外部的这种服务，它的密钥是是托管在那个一搜给上面的，那这种情况下，那这部分密钥也有一整套的方案去进行保护，那这部分在一次上也是有一个，嗯，整体的设计方案，但是具体的实现还没有开始，目前英特在云生斯斯曼场景做的一些优化和技术探索，主要就是这些，我的分享就到这里，谢谢。

非常感谢冯小天老师的精彩分享，下面进入产品发布环节，第一位发布的嘉宾是腾讯云微服务架构师严松柏，给我们带来腾讯云原生网冠重磅发布的介绍，有请严松柏老师，大家好，我是微服务架构师杨松柏，欢迎大家来到我们腾讯云云原声网关的发布会，那么我们今天会给大家介绍一下TS微服引擎云原生网关的相关的一个介绍，那我们来看一下云原生网关的介绍。首先啊，云原生网关是腾讯云基于开源网关推出的一款高性能高可用的API生命周期管理的产品，它百分百的去兼容了开源网关控的API，嗯，用来减少用户自建网关开发以及运维的成本。那么我们可以看一下下图啊，下面这个图就展示了我们云原始网关的一些相关的功能，可以看到我们前面的调用者非常的丰富，可以从这个web到APP到小程序以及第三方的合作伙伴都可以发送请求到这个云原生网关控里面，那么控提供了相很多的功能啊，比如说像由转发认证、健全参数转换、日志监控等等一些丰富的功能，那么经过这些功能之后啊，网关会把请求转发到我们的业务后端，那我们支持的业务后端也非常的丰富，从云音这个云主机，到容器集群，到腾讯微服务，到微。

服务平台，甚至其他的一些公网URL，我们都可以支持啊，那这就是一个云原生网关的一个整体的全景图。那我们看一下云原生网关有哪些特点呢？它主要有四大特点，第一个就是啊，完美的兼容的开源云原生网关基于开源网关控来设计的，而控在get上的开源影响力已经达到了啊，几十万的star啊所所以我们百分百的去兼容了啊。

控网关的API，让用户从自建网关迁移到呃云原生网关，无门槛。然后第二个特点就是高性能高可靠啊，腾讯云拥有呃独有的多种架构优化算法来保证可用性，然后也提供多种规格的实力支持，无缝扩容，轻松应对流量红峰。然后第三个特点就是高性价比啊，首先云原始网关采用了啊腾讯云底层资源，性价比超高，然后由腾讯云来托管啊，无需要去关心咱们自建网关的人力成本以及运维成本，提供了极高的性价比。第四个就是腾讯云特色的相关功能，比如说我们提供与腾讯云环境，腾讯云产品的标准对接方式，然后对接云上的资源会更简单，然后我们也提供相关的特色插件来提供高级的功能，这就是云原生网关的四大特点。

那我们来看一下相比自建开源的价值是什么呢？首先我们去做开源自建的话，它有三大痛点，第一个就是开源组件功能可能不满足，第二个就是运维成本可能会更更高，第三个就是高可用建设更难。那么相比这些痛点的话，我们人员生网关的竞争力主要就在于四大方面，第一个就是呃高性能，我们提供一键部署，无损扩容，还有同城多活等等相关的一些能力来保证我们的可用性。然后第二个就是呃高可用啊，我们在这个原生网关的基础上提供了像啊监控告警，自动升降配，然后以及架构高可用和数据高可用来保证我们的可用性。然后第三点就是啊易用性，我们提供了很多可视化的功能，比如说我们在这个控制台数据日志上都。

做了啊很多的可视化的工作，然后提供了不少免运维的能力，来提高整体的易用性，然后第四点就是安全性，我们做了很多的安全性的这个加固，以及包括说提供更细腻度的健全，那我们能在更多的场景里面去使用安全的使用我们的产品，那么这就是我们原生网关的四点价值。那么原生网关的主要使用场景呢？就分为下面这四类，第一个就是啊，流量控制，比如说我们想做精细化的限流，然后以及流量的监控，那么都可以通过原生网关来实现。第二点就是灰度分流，比如说我们想通过条件路由来去分流不同的请求到不同的业务后端，那么呃，原生网关也可以轻松的去实现。第三个就是安全控制，比如说我们想提供一些健全的功能啊，应用的认证，或者分发一些密钥，那么这些都可以实现。然后就是IP的访问控制，比如说我们想要创建IP的黑白名单，或者说配置一些IP的网段，那么这些都是原生网关所支持的安全控制功能。

那第四点就是自定义插件啊，比如说我们想要去修改我们的请求体或者响应体，来去实现更多的自定义的业务功能，那么自定义插件可以很好的支持咱们去使用这样的功能。好，那么云生网关还有丰富的内置插件，那么下面我简单介绍一下，呃主要分为五类，第一类是呃访问健全，访问健全的话提供了像一些basic的，还有O以及甚至ADAP的健全能力。那么运维支持方面呢，我们除了对接常见的日志监控组件以外呢，我们还支持普罗米修斯呃，State d啊等等相关的一些啊运维呃监控的接入，然后并且我们支持腾讯云上的日志监控组件的对接。然后第三个就是安全控制了，安全控制的话，我们呃有丰富的插件支持，比如说像跨为请求，IP拦截，机器人爬虫类的访问拦截，还有GWT的支持等等都是支持的。然后第四点就是报文的转换啊，我们支持一系列的报文转换能力，比如说通过HTTPS的接口去访问GPC或者甚至反。

过来加PC去访问HTP啊，这样的这种报文转换啊，我们都有相关的内置插件去支持，嗯，最后一个就是流量控制，流量控制的话，我们支持丰富的场景，比如说像限流，熔断，降级缓存等等都是我们所支持的场景，那么除了上面列出来的五大，呃，这个内置插件以外呢，未来我们还会支持更多的插件的能力，去不断的去丰富我们的插件。

那么除了内置插件以外呢啊，我们的用户也可以通过自定义插件去自己去实现自己的这个插件场景，比如说我们啊有四种场景可以公司用户自己去实现，第一个就是业务逻辑，比如说我们想要去啊，修改我们的请求的一些逻辑，根据一些由条件呀，或者是其他的一些条件来实现，修改报文，或者是自定义响应报文等等，这些都是啊，可以通过自定义插件去完成的啊。第二个就是自定义日志收集，我们通过对接cossdk可以实现自定义请求的header以及八的内容收集，然后导保证呃实现日志不落盘，提高传输的效率。

啊，第三个就是豹纹的转换，比如说除了我们啊内置的那些豹纹转换以外，咱们想要去实现啊更多的豹纹转换的能力的时候，就可以通过自定义插件来去完成。第四个就是外部服务的集成啊，我们通常在业务的开发过程中可能会去呃调用外部的第三方服务，那么这样的服务就可以通过自定义插件来去实现，那么相比啊这个COB的实现路径的话，我们云原生网关的实现路径在这个自定义插件的这个场景上会更简单，我们主要都是通过呃像撸R脚本来去做的，那么做到了简单应用，快速的去实现自定义插件。呃，左上图就是我们自定义插件在整个云原生网关中啊发挥作用的一个位置，可以看到请求进来之后，会先通过内置插件，然后再到自定义插件，再到再会转发到后端，这就是整个自定义插件所实现的一个呃场景。

好，那么今天的介绍就到这里，感谢大家观看，谢谢。感谢严松白老师给我们带来腾讯云原生网关的精彩介绍，同时严白老师将继续给我们带来腾讯服务治理产品北极星重磅发布的介绍，下面有请严松白老师继续，大家好，欢迎来到腾讯服务治理北极星重磅发布现场，我是微服务架构师严松柏，今天会由我给大家介绍一下我们北极星的产品。啊，北极星是腾讯开源的服务发现和治理中心啊，截止2021年9月，在线节点数已经超过500万个啊，它每天的服务调用量也超过三十万亿啊，调用成功率是五个九，然后覆盖了腾讯内部90%以上的业务部门啊右图可以看到这是啊我们腾讯内部正在使用北极星这个产品的一些产品，像啊QQ音乐、微信支付、王者荣耀都是北极星的用户。

啊，那么北极星啊是以注册配置中心为基础，扩展了服务治理功能以及相应的控制面，各个部分的功能可以单独使用。那么从下图可以看到，我们基础的功能主要包含了服务发现、服务注册、健康检查以及配置管理，然后我们扩展的一些功能就是服务治理相关的功能，主要包含了像流量调度、熔断降级、访问控制，还有可观测性上的一些功能的扩展。那么在数据面上我们也支持多语言的SDK，甚至支持S还有的方式，然后开发框架知识也非常丰富，可以看到主流的像GPC呀，Spring cloud呀等等都是我们支持的。

啊，那么啊，北极星采用了计算存储分离的架构，然后性能可以做到无限的扩展，左边是传统的注册中心，比如说我们以呃UR卡为例啊，它的这个呃数据同步的方式维护集群的数据一致性，所以说呃呃单集群管理2000以上的节点就会出现高负载，那么8000节点以上可用性就无法保证了，呃原因就是计算呃存储计算合一，不支持数据分辨，无法平行扩展带来的这种啊性能瓶颈。那么北极星的这个注册中心是怎么做的呢？就看右图可以看到啊，北极星是支持存储计算分离控制面无状态的，可以随时接入节点的增加，平行扩展能够轻松支持百万节点啊，这就是北极星在性能上面的优势。

那么我们看一下北极星的能力啊，北极星首先它提供服务熔断降级的能力啊，故障熔断能力是服务框架的一个必备功能，它可以保证服务在线网运行的过程中，当故障发生时，对故障的资源进行隔离，从而最大限度的保证服务的高可用。那么北极星主要是通过两个手段来实现熔断降级的功能，第一个就是啊，我们会基于服务调用的失败率或者错误数等信息来对故障的这个资源进行剔除，如左下角的图所示，当这个请求客户端去选择我们节点A的时候，如果节点A啊出了故障，那么我们的熔断器就会去熔断，然后我们会让他去调用节点C啊。那么第二个就是服务降解能力，当啊支持当资源不可用时，我们去进行for back操作啊，防止出现超时或者雪崩的这个现象，可以看右图。

啊，当我们的请求通过北极星去调用服务A的时候，服务A不可用，那我们就可以去做服务的降级，执行本地的方法来去保证我们能够有一个呃正常的响应。好，那我们看一下第二个能力就是啊访问限流的能力啊，北极星会为业务提供多种维度的和高精度的，这个流量限流的策略，包括说服务接口或者标签方式的，那我们在限流的过程中主要会分为两类，一类是单机限流，另一类是分布式限流。那我们看左图单机限流，单机限流就是针对单个被调用的实例级别的限流，限流的限额只只针对当前被调用实例生效，它不会共享。那么分布式限流就是指我们针对服务下所有的实例级别的限流，多个服务实例共享同一个全局。呃，流量限额可以看业务图，就是分布式限流的，呃，这个架构图，我们在分布式限流的时候会有一个限流服务来提供统一的流量额度分配，来保证所有的服务实力都会被响应。

那么另外一个就是啊，北极星提供流量治理的能力啊，北极星首先是基于服务实力标签以及调用关系的流量治理的能力，基于这样的流量的治理能力的话，那么用户就可以实现下列的几个场景，第一个就是优雅上下线，那么它是指服务在启动到正式上线或者服务下线到停机的这个过程中，切走访问流量，提高服务访问的成功率。第二个就是我们实现灰度发布啊，如下图所示，当我们的请求、外部请求进入到网关之后，那么呃，我们的这个北极星可以去息一定的规则，通过不同的路由规则路由到不同的后端服务中去，那么就实现了一个灰度发布的能力。第三个就是单元化，单元化是指我们可以把服务按照不同的逻辑set进行单元化部署，Set之间会进行逻辑隔离，在容灾情况下允许跨set调度。那么。

就可以实现一种单元化的效果，这就是我们北极星提供流量治理的呃，三大场景。那么北极星的使用方式也非常的丰富多元，我们支持代码入侵的方式和代码补入侵的方式，那我们首先来看代码入侵的方式，第一个就是比如说我们支持多语言的SDK接入啊，像主流的购物、Java啊等等语言都是我们所支持的，那么用户只需要通过代码接入北极星的SDK就可以了。第二种就是一些弱入侵的方式，比如说我们支持一些依赖于框架，像spring cloud呀，GRPC啊等等，像我们北极星也发布了SP cloud Tencent的SDK，来来方便用户更快速的去接入北极星。

那么下面介绍一下代码无入侵的方式，嗯，代码入入侵的方式有三种，第一种就是通过set卡的模式来去呃接入我们支持的接入方式，第二个就是啊，我们也通可以通过注册中心API兼容的方式来接入，比如说我们支持的注册中心有瑞卡日，瑞卡接入到北极星是可以无缝。支持的啊，最后一个就是我们可以通过DNS的方式接入应用，只需要进行DNS接入的相关配置就可以实现接入北极星的，所以说可以看到我们北极星的接入方式支持是非常丰富的。好像下面就是北极星的产品的一个，呃，概率介绍，那感谢大家的观看，谢谢。非常感谢严松柏老师给我们带来的精彩分享，接下来由腾讯资深容器解决方案架构师郭志红给我们带来云原生运维新范式腾讯云容器服务创新升级的产品介绍，有请郭志红老师。

啊，大家好，我叫郭志恒，负责腾讯云原生产品的解决方案以及授权架构工作，那非常高兴呢在今年的泰国背上和大家见面，那今天给大家分享的主题呢，是云安生运维新范式，腾讯云容器服务创新升级。那在。啊，2018年腾讯930变革之后啊，腾讯集团内部全部上云，而且我们也尽可能的推动业务使用原生容器化的方式，那经过大概三年的努力，腾讯自研业务已经全面原生化啊，规模超过了五千万盒，那在这个过程中呢，腾讯原生团队也积累了非常多优秀的一个技术方案，我们也在逐步把这些技术啊，通过公有云的方式在对外输出。

那也为了让这些技术更好的服务腾讯的外部客户，我们综合考虑了外部客户的需求，以及我们现有的一个产品形态，创新性的提出了原生节点管理新范式housekeeper，那主要包含原生节点、超级节点以及注册节点。那作为容器的解决方案架构师，那在拜访客户的过程中和客户沟通发现虽然很多客户已经在使用原生的技术，但是运维效率以及资源用率提升并不是非常明显。那核心的原因就是不管是使用t ke还是使用像这种自建的Co，其实核心都是这种so的一个模式啊，这种模式下其实节点管理及运维的工作量其实非常大，比如说需要维护和升级内核容器的运行时以及Co的各个组件。为了提升资源集群的管理效率以及资源利用率，也需要进行频繁的节点扩缩容，以及复杂而且专业的一个资源规划以及调度的工作。

那这种service模式呢？呃，使用简单，因为成本低啊，隔离性好，弹性速度快，而且可以按需使用，还啊，可以很大程度上解决上面提到的一些问题。不过由service模式像service模式过渡其实并不是非常的平滑，会涉及到比较多的业务改造以及适配的一个工作，那所以我们啊推出了这三种节点类型，帮助客户从service的模式向service模式过渡。那下面我分别会介绍一下这三种节点类型背后的技术在腾讯自研业务落地这个情况，以及我们如何满足外部客户的一个需求。那首先看一下什么是原生节点，我们知道ACO是通过声明式API的方式去定义资源啊，极大的简化了整个运维的流程，所以我们也希望呃，客户可以像管理pod一样，通过声明式的方式去管理note。

那原生节点主要是解决运维效率提升和资源利用率提升这两个问题。那运营效率提升方面呢，原生节点提供了一个半自动化的一个内核运行时以及Co的一个运营方案，那客户可以选择一个升级的一个时间窗口，那我们的产品自动化去升级，或者是当然可以用户去手动去升级。那另外原生节点也提供了更多的节点以及组件的异常事件，比如像文件系统异常啊，内核死索，PID file max达到最大值的80%等等哈，那可以通过这些事件做一些告警或者是一些自愈的动作，其实类似的一个异常事件大概有几十个。那这些都是我们在大规模集群运维过程中发现的一些可能影响节点稳定性的一些核心指标啊，那总的来说就是我们通过产品化的方式提供专家级别的一个运维建议。那在呃，资源利用率提升方面呢？原生节点提供基于理念的一站式成本优化解决方案，包括提供基于历史监控数据预测的request和limit，基于历史监控数据预测的智能hpa和智能VPA，那帮助客户解决request配置不合理或者弹性不及是这样一个问题。

那呃，并且我们也提供在理性混部以及QS隔离的能力啊，解决提升混部密度以后，整个集群或者是业务互相干扰的一个问题，那并且提供细力度的一个GPU虚拟化的一个方案，那解决GPU资源利用率低的问题，并且提供了可视化的一个资源大盘哈，让客户很方便的可以看到我的资源浪费在哪里，我的优化效果又怎么样。那目前原生节点已经在腾讯内部支撑了上百万盒的业务，节点的一个平均利用率大概提升了1.5倍，那在2021年底啊，原生节点的一个核心技术，我们也通过这个项目对外做了开源，是业界首个PHOPS理念的一个成本优化项目，并呃获得了国家级科技卓越奖。

呃，那超级节点的前身其实就是t ke的虚拟节点，也就是说这种solid形态的Co，那t ke，呃，So容器技术也是完全由腾讯自研的，那虚拟化的一个安安全沙箱保障了容器间的一个强隔离，那基于TOS呃，内核深度优化后的轻量运行时也保障了业务的技术弹性和高性，那利用弹性网卡提供啊功能丰富且高性能的一个容器网络。那t ke上线以后，也在自研业务中快速的一个推广落地，目前已经有大几百万盒的一个规模，那在2020年我们对外发布以后，P PE service将清运为高性能技术，弹性安全隔离，呃，100%装箱，这样一些特性也受到了外部客户的一个认可。

满足了非常多客户像离线计算啊，技术弹性啊这样的场景，当然现在也有越来越多的客户希望把呃在线的常驻业务也跑在t ke上，那微章这部分客户可以更好的使用，并且平滑的迁移，我们推出了t ke超级节点这种啊节点形态哈，也就是说用户可以像使用大号云主机一样去使用一个service集群，并且我们提供包年包月这种计费模式。能让客户理解简单并且运维简单的同时，也享受到这种service技术带来的一个成本的一个优势。呃，那不管是像腾讯资源业务上云，还是不少IDC客户上云，那其实都有这种资源力就的一个需求哈，那其实注册节点就是让这部分IDC空闲下来的资源再加到云上的TK集群里头，也同时具备t ke系列的一个高级特性，帮助客户在资源力就的同时，也通过原生技术让业务可以更平滑的往云上去过渡。

那总之，不管是原生节点、超级节点还是注册节点，我们的初衷都是为了更好的契合客户的需求以及场景，帮助客户享受到云原生技术带来的一个红利。好了，今天的分享就到这里，谢谢大家。非常感谢郭志红老师给我们带来的精彩分享，接下来让我们进入最后的主题对话环节，本环节由腾讯云副总裁黄俊红以及CSDN副总裁邹鑫给我们带来对于开发者云原生意味着什么的主题对话，有请两位。大家好，欢迎来到，这是对谈节目，我叫周鑫，是CS的副总裁，我们负责建立中国it。

最广大的一个技术交流平台。今天很高兴和黄俊宏、陈俊的副总裁一块来聊云原生。大家好，我是黄俊红，来自腾讯云，然后今天很高兴跟呃周总一块，我们一起聊聊啊云原生这一块的话题。啊，这个非常高兴跟这个黄总能够聊一下云云生啊，为什么我特别特别想聊这个问题呢？因为从过去的几年来看，我们CSDN这个整个的内容平台中，关于云原生的博客问答以及这个论坛的帖子是越来越多，然后呢，当然我们知道有不同厂家的云云生，云云生呢也有很多的技术，对吧？然后呢，它不断的在变化，每天每个礼拜都有新产品出来。然后那我们就想问一下这个，从这个腾讯云的角度，那么黄总你看什么才是真正的云原生呢。

OK，目前云原生啊，确实还没有一个统一的定义，那CNCF认为说微服务加容器加持续交付加dev OPS就是云原生，那友商呢，也有提出说云原生呢，更多应该是从客户应用的这个视角来看，部署到云上的应用必须用到只有大规模公共云实践才能提供的三类能力中的一类或者多类，也就是说弹性。API的自动化部署和运维等等。那因此他们呃认为说云原生它是一个呃软硬一体化的架构，那其实这是相对于传统企业，我们it的这个物理环境而言的。那我腾讯云的云原生的这个定位，我们主要的目标是致力于成为企业数字化的转型的一个助推器，让用云更加简单。企业在用云的这个目的呢，归根到底还是在于利用云厂商在技术和资源这里面的积累和规模化的这个效应，来帮助企业去降低它的经营成本，来提高企业的这个效率。

那腾讯理解的云原生主要有五个维度，分别是开发云原生、计算云原生、架构云原生、数据云原生和安全云原生。好的，那我们知道，呃，现在很多企业都在做数字化转型，那从这个有了互联网的时候开始，就已经有很多企业在上云，对吧，把它的服务搬到一个以网络为核心的一个架构上，那这个上云和云原生有什么区别呢？就什么才叫才叫原生，对吧。你们能不能再对这个问题再做一些解释，嗯，上云跟云原生啊，确实是不能画等号的，那上云只是简单的把基础设施能够搬到云上，而云延伸呢，是上云的更深层面，它需要借助的是云的弹性伸缩的能力，还有按量付费的这种模式，去实现云上的开发、运维、测试、部署等生命周期里面能够享受的这种原汁原味的原始系统，那只有充分享受到云计算红利的这种模式，我觉得才是要叫云原，真正的云原生。

OK，呃，我们CC呢，就很多用户都是做开发的，就是码农啊，那我们在以前在学习编程的时候呢，都是在自己的电脑上对吧，写一些hardwork的这个程序，那么对于开发工作，云原生带来了哪些根本性的改变呢？嗯，OK，其实我们可以看到说云原生呃这样的话题，在近两年来其实也日渐啊成为一个呃非常火的一个一个话题了，那我们可以看到其实像呃微软的code，呃那个code space，像谷歌的呃呃呃cloud shell，然后包括AWS的code star，对吧，像这类的这种呃IDE，或者说这些云原生的这种编程工具，在这两年来已经呃成为一个非常热门的话题，或者说因为成为一个云原生的开发的一个主流关注的一个一个一个话题吧，那。

从我的角度来讲呢，从呃原来我们传统的在本地化的这种编程的体验，转到云原生体验，相当来说我们可以把云呃开发环境都可以搬到云上面，我觉得这是第一步，那同时基于我们云原生的这里面的一些基础的能力，比如说容器化的这些能力，资源的这种编排跟管理的能力，那其可以通过这种方式，在通过IDE跟这种资源编排的这里面的这种结合，其实可以大大的去降低。呃，开发者在这里面的这种呃呃比无论是代码的编呃编写还是服务的部署，这里面的各种各样的这种成本，包括资源管理，这里面的成本能够得到大大的降低，让开发者能够更加具焦代在他自己具体的啊业务的开发的层面上面来。所以我。

从我的角度来看呢，云原生的发展，本质上它是解放了这个开发者这里面的生产力，让他的这种代码的这些开发工作得到一个有效的一个质的一个提升，让他能够更加聚焦在有创造性，还有创造力的这些真正的业务逻辑跟业务场景的理解跟开发上面来，我觉得对于整个行业来讲是一个呃，非常大的一个提升，跟一个一个一个质的一个变化。好的，那我想腾讯也是中国的一个很有名的企业，也很有历史，那他自己也有很多的研发人员，那他自己的腾讯自己的原原原生历程是怎么样的呢？王总能不能分享一个你们具体业务的。

云原生转型的故事嗯，OK，腾讯云的这个云原生，呃，我们的发展呃，是从2018年开始的，大概能够分为三个阶段吧，那2018年到一九年是我们整个云服务器上云的阶段，那2019年到二零年是我们自研业务容器化改造的一个阶段。那到了呃二一年到二二年，也就是今年，那我们整个的腾讯云的业务也在全面的去推进呃云原生化成成熟度模型的2.0，通过这种方式来进行呃降本增效，那在这个转型过程中呢，我们也有很多的呃一些呃有很多的这种业务方面的故事，比如说大家呃熟能详的，比如像视频号，还有腾讯腾讯会议，这些都是我们生长在云上面，长在云上面的这种呃标杆的这些业务跟产品。

比如说像呃视频号，我们之前呃大家也都知道，到周末的时候有很多的演唱会，比如说像西城男孩，周杰伦，还有崔健等等这种大型的这种明星演唱会，曾经也在国内创造了几千万人在线的这种。呃，直播的这样的一个一个规模，那在这种大规模高并发的这个场景下面，它依背后依托的这个技术是什么呢？那背后其实就是我们云原生的，比如说弹性伸缩的这个能力，包括我们在音视频方面，我们给直播的这些产品所做的这种底层的这些核心能力的这些基础支撑，包括像腾讯会议也是一样，它依赖我们在业界领先的这种实时音视频的这个产品，比如说TRTC，有效的去保障了我们几亿用户在复杂的这种网络环环境中，怎么去流畅清晰的这种会议视频会议的体验，那这些背后都是我们云原生产品，或者是云原生基础能力在提供非常有利的这个支撑，才才能够让我们的产品能够在千千万万的用户里面能够得到一个非常好的体验。

好，谢谢，事实上我自己也是这个呃，视频号的一个用户，然后呢，我们现在正在用这个腾讯会议来交流，我觉得他们这个质量和体验都是非常不错的啊，也感谢这个腾讯的研发人员开发了这么好的产品，而且呢，听了黄总讲的故事之后，发现事实上云原生能够帮助他们，帮助这个腾讯能够降本增效，对，那腾讯呢，应该算是一个比较先进的企业，对吧？那很多传统企业呢，都在做数字化转转型，那么他们当然云原生是他转型的一个方向，那么传统行业这个云原生的转型，它的动力来自哪里呢？这个当前处于什么样的阶段呢？

要不要我们黄总也给大家讲一讲看，在我看来，我觉得呃，传统企业现在也是处在一个呃逐步数字化转型的一个阶段，我觉得对传统企业来讲呢，它是转型的动力，主要有两个方面，然后一方面呢，是来自于自身业务发展的需求，第二方面是来自于啊，企业降本增效的一个需求。那从具体的这个业行业的这个场景来看，我们可以看到无论是金融、政务或制造业等等，那随着我们数字化的深入，单独的这种爱的云服务其实已经远远不能满足传统企业数字化的这种需求，那实体经济的转型呢，其实更需要的是贴近业务的这种pass化和S化的这些能力，比如说在政务领域，我们需要更多的去结合AI、大数据等能力来创造更大的价值，包括金融领域在多云部署还有混合云这种场景下面，怎么去解决快速扩容的这些问题，包括制造业领域里面怎么去提高云资源的利用率。

怎么去提高协同性，对吧，包括怎么用AI来解决比如说工业质检等等这样的问题，来提升效率等等，那么。近年来呢，我们云厂商呢，也在不断的去加大在微服务、容器化、service跟分布式云的等等领域的这些投入，来帮助传统企业来解决这些问题，那我们腾讯云呢，尤其加大在pass的能自研能力上面的建设上面，比如说像音视频的TRTC，容器领域的t ke，数据库的t t circle等等，来帮助企业适应未来业务发展的云原生服务平台。对，我觉得腾讯云事实上给这个呃用户提供了很多强有力的工具，帮助他们做数字化的转型，然后呢，码农本身可能也要转型，比如说我是一个大四的学生，或者是研究生三年级的学生，那我在学校里呢，通常是用传统的方式来学习编程，那我作为一个即将工作的一线开发者，在这个云原生的时代，我要做哪些准备和哪些改变呢？嗯，OK，云原生确实对于开发者来讲，我们提供了很多的这种原生的这个云化的能力，来帮助开发者去提效，或者说让他能够聚焦在业务开发，那反过来呢，我觉得在未来的话，那云原生可以说已经成为未来开发者可能必备的这个能力之一。

甚至说如果不懂云原生，其实呃在找工作方面可能相对来讲就比较困难，那从具体的能力上来说，比如说像微服务的这种拆分能力，容器化的这个改造的能力，服务治理的能力，包括以及像de bos的这些能力，其实都是开发者需要去必备的一些技能，我觉得这些对云原生的知识的的一些积累跟储备，我觉得对于开发者来讲还是尤为重要的。

好的啊，我觉得黄总刚才讲了，事实上是非常重要的一些云原生入门的一些基本的呃概念和基本的操作，那么就是很多学校学校啊，我个人觉得可能没有在这方面没有很好的衔接，那么就是呃。腾讯云在这些这在腾讯云在这方面有什么样的计划，或者说有哪些比较有效的方法和途径帮助我们开发者快速的融入到这个云原生的时代呢？嗯，OK，云原生的开发模式近年来已经日渐成为新的这个行业的趋势，像微软的code space，谷歌的cloud she，还有AWS的Co star等等，最近呃，这两年都是比较火热的开发工具，那核心还是让开发人员去摆脱本地开发物理环境的束缚，更方便的去远程远程协作，那腾讯云推出的class studio是国内第一款将底层云资源和在线开发环境融合的开发工具，同时也进一步升级为腾讯云开发者生态的入口。

整合云资源和等pass能力，为开发者提供高效、稳定、全面、便捷的开发者工具。啊，我觉得这个class非常好，就是能够真正的帮助我们的啊，准备工作的人，以及从传统的这个开发模式转到云原生的模式的人，能够快速的衔接。啊，我认为另外一个痛点，对于开发者来说，就是当我好程序之后，我怎么样帮他，怎么样能够把这个程序快速的部署到一个云的服务上，对吧，这叫，那么S呢，在落地应用中还有哪些痛点呢？呃，我听到很多人抱怨说现在的up事实上是有非常纷繁冗杂的，这样是各种工具可以选，大家这个出错的机会也很大，那么腾讯云是从哪个角度来解决这些问题呢？

OK啊，这是好问题啊，确实工具确实永远没有最好的，也只只有最合适的，那企业或者开发者需要根据自身业务的特性来选择适合业务发展的de off工具。但无论是企业使用的是一体化的还是开放式的这种工具链de off流程都需要使用正确的工具来解决de生命周期的各个关键阶段所面临的问题，包括像计划构建、持续集成、持续交付、可观测运营、持续反馈等等。那腾讯云呃，Coding的de这个产品呢，我们提供了一站式的这种开放、开发、协作的工具。

那帮助研发团队能够快速落地敏捷开发和OPS的开发方式，实现研发效能的这个升级，那主要的优势包括呢，比如说呃是用多种的研发场景，开箱即用，免部署，低成本，涵盖了软件呃开发从共享到交付的一切的所需。包括安全性，我们提供了动态和静态的安全的这种代码跟制品的扫描的能力。包括更敏捷的协同开发过程，包括自动化的持续的交付能力等等，可以说在整个的软件开发生命周期里面，我们提供了更多的一站式的这些工具来帮助开发者去解决它在开发过程中所面临的这种持续的交付跟部署跟运营一系列的问题。好，听起来这个cloud studio加上coding是一个很强有力的工具，就能够帮助我们的开发人员用一个比较简明的方式去来处理这个单al up碰到很多问题，然后呢，刚才你也提到，事实上我们这个这些工具呢，就会让我们的工作变变得比较简单，然后在现在的这个业界呢，还有另外一个啊方向就叫低代码。

那低代码呢，是能够让他让这个企业更加专注于他的业务，然后呢，没有太多编程基础的人都可以开发应用，那有很多程序员就会问了，那第一代码这个解决方案的新梦是否意味着对于开发者的需求量会减少呢？那作为一个开发者，我的出路在哪里呢？能不能跟跟大家解释一下，OK，好问题，因为低代码确实可以提高开发人员的这种工作的效率，但确实他不是取而代代之的，事实上我们低代码是被设计用来替代重复的过程和功能，呃，我理解它更多的是过去的一些技术的经验的积累和沉淀，并且形成的这种呃功能性的这些呃能力，那在很多的一些特定的场景里面，其实我们仍然需要手写一些代码来解决我们的业务的需求。

那应用开发的本质呢，其实还是呃创意、想法，还有怎么去实现的这个逻辑，所以开发人员的价值的高低，不是取决于说我实现的时候到底是用纯代码还是用低代码，只能说低代码未来也许会成为呃更加有用的这个生产工具，那开发者应该将更多的精力投注在说我们更有创造力，还有更有创新性的这个事物上面去，我觉得才是呃开发本身的一个更需要关注的一个事情上。好的，对，就是最终我想很多的客户还是要我们这个腾讯云或者是别的工具能够解决问题啊，然后呢，刚才黄主任也提到，事实上我们有很多的新的工具啊，每天都在出现，每天都有更新，然后呢，这个云原生事实上也是一个方兴VR的一个技术发展的方向，那么如果我们看得远一点，它未来的方发展方向在哪里呢？呃，程序员本身啊，在这方面有什么计划呢？能不能和大家分享一下。

云原生技术呢，从微服务架构大规模的应用开始，融合了容器、服务、网格、get options技术，到了今天已经进入了一个相对成熟和大规模应用落地的阶段了。现阶段我们可以把云原生抽象理解为，比如说云原生就是等于微服务加de off加持续交付加容器化，那这些都是以资源管理为中心为核心的，那面向未来呢，我觉得应该逐步会过渡到以应用为中心这样的一个目标，那除了具备说初代的云原生容器、微服务deos的这些特征之外，更多的强调的是对资源的配置和对应用效率的一个最优解。

那展开来说呢，我觉得未来会有几个发展的变化，比如说更高效的资源管理与调度，比如说在腾讯云的cloud studio中中，我们会通过声明式的这种开发环境和生产环境来一键管理和编排呃开发容器资源和生产环境资源，来大大提升开发资源的管理和对生产环境的资源进行调度。那第二点呢，是。更敏捷的应用交互和管理。比如说在腾讯的云op的云原生应用管理的模块中，通过云原生这种应用标准的模型编排企业应用与云产品，通过get up的呃自动简配和可靠且灵活的发布流程来保证发布的这个可靠性。

那第三个呢，是更呃完善的这种安全可信和合规。那。如果从我们的面向未来的话，我们在cloud cloud studio这里面呢，我们还有呃几个方面的这些规划，比如说第一方面的是云上开发安全提效，能够面向企业的这个开发上，云能够更加简化，并且能够深度的去融合腾讯的云产品。让开发者在上云的过程中，能够解决掉中间不必要的这种开发流程和环节。并且能够更充分的去利用衔接好的腾讯云产品的各种调用，比如说我在开发的时候可以很方便的去调用腾讯云的底层的各种呃，产品跟pass化的能力，对吧，那让开发的这个体验更加简单，可以更加专注在业务的逻辑本身。

那采用这种IAC的这些呃现代的开发理念呢，可以让呃企业团队开发更一致，能够更高效，那也由于我们代码开发不落地，我们可以主打安全开发代码和的工作度量等等能力。那第二个呢，是云上部署的get UPS，一键的部署来降低啊运维的成本，那通过iacc跟get UPS的组合，我们让开发到构建能够变得更加的顺畅。那我们可以方便的在呃某个环境里面能够进行快速的部署我们集成的云原生的local host的优的优秀的能力，并且包并且组合出基于云原生能力的云调试的套件，让复杂的云原生团队成员之间的这种调试就像本地一样的调试一样方便。那第三点呢，我们也会深度的去集成腾讯云的各个产品呃，成为腾讯云开发者的一体化的这个平台，那cloud studio呢，会深度的融合其他产品的能力，并且在各个领域里面去组合出更呃若干个的解决方案来帮助开发者，无论是在呃。

高校也好，电商也好，还是在科研也好，还是在医疗也好等等的行业里面，我们能够针对这些行业的这个场景，为开发者提供更多更加高效的能够开箱即用的这些能力，那帮助开发者在各个领域领这个领域跟行业里面能够去非常高效的去做，呃，完成他所需要解决的。业务问题。好，谢谢谢。感谢屏幕前的观众朋友们耐心观看我们今天的直播活动，相信大家在参与完今天的活动后都会有非常大的收获，最后再次感谢各位的参与，疫情期间也提醒您多多注意防护，保持身心健康，待到疫情好转时，期待在现场活动能与各位线下相聚，各位朋友们，我们下期活动再见。