亮点回顾：降本增效最佳实战，揭秘TKE容器助力企业降本秘诀原创

各位现场的朋友们大家好，欢迎参加腾讯云企业创新在线学堂系列课程，是本次会议的主持人Lisa。腾讯云企业创新在线学堂是围绕企业业务需求，聚焦在数据管理、AI、安全、办公协同等8大数字化需求场景推出的系列课程，携手腾讯云创新动无限可能，共同开启企业成长新长。随着业务的快速发展和数据量爆炸式的增长，传统的it架构以及难以满足高效、灵活、安全的需求，云原生技术以及独特的优势正在成为企业优化业务流程，提升运营效率、降低成本的关键，在各行各业啊得到广泛的应用。而在此过程中呢，企业也面临着诸如啊技术复杂性高、成本控制难、安全性要求严格等诸多痛点，特别是在容器管理、微服务架构治理以及消息队列的安全扩展方面，企业往往缺乏成熟的经验和解决方案。本次直播呢将为企业提供具体的云原生向本增效安全集成实战案例与解决方案，助力企业在激烈的市场竞争中脱颖而出。好了，那首先呢就有请我们今天的第一位分享嘉宾，来自小鹅通的容器负责人张安哲，张老师从参与大型的开源pass项目研发，核心参与了小鹅通容器化0~100，对弹性弹性伸缩UPS领域有深入的研究，现在负责小鹅通的容器调度及集群稳定性。今天张老师的分享主题是云原生维稳降本容器集群计算资源调控实践，有请。

嗯，好，谢谢主持人，那我今天演讲的主题主要就是涉及到维稳降本，以及呃，利用容器集群计算资源调控进行一个维稳降本的一个分享。

然后简单介绍一下目录吧，然后第一第一部分会讲一下我们这边小额通的一个多模型，以及高体量的一个业务场景。然后这个其实也是我们去进行一个资源调控的一个业务背景，因为你有足够大的一个体量，以及足够一个复杂的一个业务场景，才会诞生对应的一个需求。第二部分的话就涉及主要讲到我们这边的集群的资源调控，集群资源调控呢，其实大部分都会用到我们腾讯云的一个service，也就是超节点。以及常驻节点的一个搭配，但是大家在使用的过程中呢，其实对应的一个配额比。是没有一个很好的一个，就是经验的一个落地，然后主要是讲下我们这边的一个实践，以及达到高效的一个效果。第三个的话就是服务资源，也就是说H去解决一些业务场景及对应的一个成本点。

到了这一部分，会详细讲一下我们这边是如何去管理服务，它对应的一个弹性的一个配置。第4个第4个部分就是关于以上的一些已经落地的一个成果，然后未来的我们这边关于小儿通的一个的一个发展方向，以及对未来的一些的一些规划，嗯。然后，首先我们来介绍一下第一部分，多模型的高体量的业务场景。首先我们这边做一个自我介绍，嗯，刚刚其实主持人已经帮我介绍过了，嗯，我这边就重点讲一下，嗯，我这边呢，主要是之前就是专门在pass领域这边的进行进行一些开发，以及对应的一个建设。之前呢，其实也是就是做监控这方面的，所以说有了监控之后，那我们这边的其实其实也跟呃监控有很大的一个关系，因为我们有了对应的一个数据之后，才能建立对应的一个模型。

有了对应的经验之后，才能开发对应的一个算法，有了算法和模型之后，我们才能研究对应的一个策略，并且进行一个对应的一个资源调控，或者是对应的一个降本。现在主要就是负责小额通这边的一个容器调度及稳定性。先简单介绍一下我们多模型以及高体量的一个业务场景。小鹅通的话，其实是一家以知识产品与用户服务为核心的一个技术服务商，至今B端用B端用户已经服务百万余家。然后现如今的话，其实嗯，小鹅通作为私域的运营一站式工具，解决产品和交付服务，营销获客，用户运营以及组织角色管理等。

在企业经营过程中发挥了重要的一个作用，企业数字化经营的一个好帮手。然后我们主要的业务场景呢，其实主要是这几大块，一个就是秒杀场景。考试场景以及对应的一个直播场景，他们其实是有对应的一个关联性的，比如说直播场景及秒杀场景，直播场景呢，因为直播作为就是私域运营的一个重要的一个手段，它其实是大部分的一个商家都会用到的。一个场景。主要的场景呢，它这个场景有什么特点，其实就是它的一个流量随着呃是非常符合，就是大众的一个习惯，比如说晚高峰是全天最高的一个流量的一个点。然后。

嗯，秒杀场景呢，其实是我们最近开始拓展的，呃，一种场景，也就是说我们。有这么多的一个流量，但是如何商户把这些流量转化为实际的一个价值，那其实就是可以通过我们对应的一个，呃，直播间里面的就是小黄车，类似小黄车进行一个就是在线下单以及购物，以及对应的一个抢券。以及对应的一个活动考试场景呢，也是就是作为我们B端私域运营的一种手段。比如说商家去进行一些嗯知识付费的一些发布知识付费的课程，那其实会形成一个对应，就是嗯学习效果的一个跟进的一个闭环，那其实就衍生出了我们这边的一个考试场景，考试场景商家发布定时考试就是用。一间的话，大概有几十的一个用户会进行一个，呃，进行一个做，所以说里面其实是比较具有挑战的一个业务场景。

第二部分呢，就是讲一下我们service以及常驻节点的一个高效利用。那刚刚其实说到直播这边的一个业务属性是非常符合，就是大批量的，呃，一个用户的一个习惯，也就是C端用户的一个习惯，那其实可以看到我们这边的一个集群资源业务影响是。受直播业务影响是比较多的。他早上的话其实是有一波流量的一个高峰，这里的话其实是一些，嗯，比如说一些老年健康或者是一些考试。呃，打卡之类的一个业务场景，所以说他会这边有一波的一个，呃，资源利用的凸起，然后下午以及晚上其实也是一样的，那到了凌晨的时候呢，基本上流量就已经很少了，它存在明显的一个波波的一个场景。

集群资源呢，其实波峰波谷它的一个差值可以达到百分之百以上，也就是说我们整个集群的一个高峰期的。资源利用的资源用量其实是低峰期的2倍及以上。然后集群的一个显示资源。这种明显。在业界的场景里面呢，这种场景是大部分都是会搭上我们及技。其实我们也不例外，但是我们这边的话，利用之前其实做了一些调研。就是常驻节点，以及它的一个优缺点到底在哪？优点的话，其实就是常驻节点，因为是包年包月的一个场景，大部分，所以说它单位时间费用较低，就比如说你买了一个包年包月的一个机器，它换算平摊到就是每小时的话，它相比于其实是成本更低的。

然后另外一个优势就是支持care care的话是那个，嗯，腾讯云开源的方案，其中集成了节点放大等核心的一个功能。其中节点放大，它这个其实是已经在我们小额通全面进行一个落地了，然后其是也是嗯，比较有用的一个方案吧，它其实这两个加起来的话，可以极大的去降低就是说是一些常驻资源的一些成本，以及提升我们的一个呃，集群资源的一个利用率，那less呢，它其实。呃，好处其实各家云厂商都一样，就是调度灵活，维护成本低。嗯，去劣势呢，其实就是嗯。大部分情况都是一样的，就是常驻节点，它的一个就绪速度较慢。

然后超级节点的话，也就是它不支持。超慢，以及就是说单位时间费用比较高，那如果我们要使用的话，那肯定就是把他们的优势进行一个相结合。相结合的话，其实就很容易去推导出这样一个使用模型。也就是高峰期的时候使用，或者是应急场景使用，但是大部分时间都使用长度节点加上care的一个操作。但是这样的话，虽然说是可以省，但是没办，就是说我底这个应该在占比多少，节点又应该占比多少，怎么样进行一个节点之间的一个配比，达成企业支出的一个最高。那我们就要继续研究一下这块的一个。成本的一个模型的一个对比。的话，其实它的有计费有两个原则，较大原则，也就是说它会呃你所有container之间的一个ma max的一个或和那个你所有container的request的呃，Sum进行一个比较，取最大的一个值。

那以这些例子来看，就是比如说你申请了一个C的一个，所有request加起来是3，但是它计费会变成4，因此推就是6的话，它计费就会变成8。那这个时候的话，其实我们就需要去进行一个注意，就是能把资源利用率，也就是比如说他是分配了那个，呃，我们我们升级的是三格，其实就可以去进行一个规格的一个升格，就是我们分配的时候就进行一个升格，以及呃达到就是说投入以及实际获得的一个最大的一个。

呃，优势，然后成都节点的话，计费规则，其实我们这边的话。是这样去进行一个计算的，也就是节点的数乘以配的放大系数，再去减去系统组件的一个合数，那这里的话为什么要去系统组的数呢？因为我们这边的它其实计费是包不包含这些的，或者是说它原来的模型就已经包含这些的。所以说我们需要进行一个条件的一个剔除。那把我们这边的一个的一个和一个常数节点的一个计费规则，嗯，都已经摸清楚之后，我们就可以根据实际的情况去研究我们这边so和长节点的一个配比的一个模型了。这边的话其实就是进行对应的一个统计，其中呢，这些计算一型或者是内存二型，这边就是我们内部的一些，嗯，规范化的request以及的一个配比，那相应的根据我们。

刚刚提到的一些规则来看，就可以得出它的一个超级节点，它的一个计费的实际的规格，以及就是说是这些对应的一个机型在节点上以及超级节点上需要，呃，就是每每小时运行花费的一个对应的一个成本。得到我们的一个成本模型，得到成本模型之后，我们自然而然可以很容易的算出，就是说是他用用多少之后它的一个。每天的一个时间用多少之后，它会超过对应的一个长出呃，超级的的的一个成本，然后进一步得出。我们这边的一个公式。也就是说我们会把每一个对应的一个机型的一个占比去作为一个，呃，可以可以理解为一个配比值吧，然后去进行。

呃，对，拿拿对应的一个条件进行一个。呃，聚合聚合之后呢，其实可以得到我们集群的一个常备资源的一个分位值，常备资源的分位值呢，其实是用来是用来干什么的，就是我们假如说是把嗯，把我们整天的一个集群的一个总和数进行一个，然后每分钟的一个对应的一个和数去取一个点的话，然后对应的分位值，其实就是说从大到小去。牌。排序，然后比如说它这个值的话，在我们这边算出大概是嗯，P66左右，那其实就可以算出，就是说你每天超级节点需要呃，运行大概8小时左右，我们这边的一个黄金配比。

然后可以得出对应的就是说我超级节点需要配多少盒，以及长度节点需要配多少。那我们拿到配比之后呢，其实要怎么进一步的去进行一个维护呢。其实维护的话，其实就比较比较进行，呃，比较简单了，那我们可以把我们的分位结合我们的在我们的大盘上进行一个配置，嗯，这边的话涉及的呃，涉涉涉及到一些数据脱敏就不太方便放，然后。可以看到我们这边的一个实际的一个效果。嗯。优化之后呢，其实之前大部分嗯，集群这边常驻节点还是有一些冗余空间的，那那我们在优化之后呢，其实可以看到发挥了它最大的一个潜力，然后对于成本来说呢，相同业务量，它的一个云资源的一个成本降低了12%。

然后下一部分呢，是我们这边的HPA+HPC，解决业务场景的需求以及成本痛点。场景一呢，就是直播带货，也就是比如说我们线下有很多的商家，然后他为了就是说，也就是疫情那段时间，为了数字化转型，以及开展他们的业务，会把他们的一个线下庞大的一个流量带到线上直播间，进行一些产品的讲解之后发出对应的一个商品链接进行抢购。瞬时的话，其实就有呃，几几十万人的一个用户去进行同时的一个抢购，对我们的系统造成压力。那其实的话，其实大部分用了容器集群都会配置H，但是H的话，其实。

在我们场景下，其实用的也比较多，因为比如说商家在嗯下午的两点进行一个开播，如果是我们到了对应的一个点去进行一个的一个自动扩容的话，它其实嗯对客户的体验来说并不是很好，因为什么？因为我们每次扩容的时候，至少就算优化之后也至少1~2分钟。但是发出链接之后，它的流量的一个时效性是时的。也就会造成对应的一个系统的一个不可用的一个状态，所以说扩完之后进行缓慢的进行一个回收，可以。嗯，很好的解决我们的业务的问题。那另外一个场景呢，因为我们这边主要是区B端的，那B端的话，它就会有一个对应的一个长尾效应，也就是说你一个商户它可以带来线网呃非常大占比的一个流量，比如说带来几十呃呃就就是带来呃网一半的一个流量，在某个场景下。

所以说呢，呃，如果说是开用户有对应的一个，呃在时开播的一个需求，那我们这边的保障其实就可以对对应的场景进行一键添加HC。然后帮助用户进行呃，帮助用户使呃体验顺畅。然后这里其实可以看到，它其实是脱离了，就是常见的晚高峰的一个时间段，在早高峰，但是作为重点的一个客户，我们还是。对资源进行了一个特殊的一个保障。嗯。好，现在接下来的话就是。我们做完这些保障之后，会发就是引发出一些问题。就是对应的服务大量的HP维护，人力成本较高，利用率下，为什么？因为我们之前其实在没有资源调控之前，都是凭之前的一些经验。

去进行一些配置或者是调整，但是配置完之后，它的HP以及HC的维护性，后续维护性工作，比如说这个场景没有了，或者说这个场景被嗯优化了，CPU占用较少了，但是就是由于人力成本较高的话，就是没有后续的一个维护的一个机制，导致集群利用率低下，云资源成本陡增，那我们怎么去解决这块的一个问题。嗯，解决问题之前呢，我们肯定是想要就是说对应的一个场景化，以及可自动性这样，然后可维护性，那在开发程序或者是说制定对应的规则之前呢，我们需要制定对应的一个标准。

然后标准的话，其实呃业界的话在就是说是计算资源这块的一个容容器，计算资源它的一个运行标准，其实呃资料目前的话还是比较少，所以说是我们结合了一些部分的一些业界经验，比如说德物的一个的经验，以及我们自身生产的一些经验。然后。进行一些呃，背景的一些调研，以及对应的一个试点，得出我们这边的一个计算资源的一个标准。然后可以看到标准的话，其实刚刚提到的集训常驻资源计算资源水位，其实就是我们呃，常驻节点以及就是超级节点的一个配比。服务基础资源呢，其实就是规定这个呃服务它的一些呃日日常的一些指标，比如说它的呃CPU内存或者是FPN的FPPN的那个继承利用率，它应该在什么样的一个范围值，然后得出我们这边的一个呃落地的一个背景参考。

那我们有了标准之后，其实呃，后续的工作其实就会比较简单。有了标准之后，就是通过程序化去把这些标准进行一个全自动化，进行一个落地，比如说我们之前调资源可能需要呃去看各种监控的一个面板，那我们其实对应的一个数据源，其实现在都已经呃很发达，那那我们直接拿对应的一个数据源进行一些之前的这些标准的一个计算，计算之后呢，会推出对应的一个变动的一个账单，比如说它，呃，它最大的一个7天最大的CPU利用率是多少，7天最大的进程利用率是多少，符不符合我们的标准，如果说不符合我们程序就进行呃一个预算的一个动作，预算之后会推出对应的一个调整的一个预期，也就是说本次变动服务多少个。

呃，成本变动多少个预期，能提升我们多少的一个，嗯，集群的一个利用率，进行一个数据的一个触达。然后这边的话，其实就是一第一个方面可以降低我们整个集群的资源冗余，以及对应的一个投入，呃，另外一个的话就是可以处理我们资源的风险，比如说他某某个嗯服务它CPU其实已经长期高位，但是由于没有触发告警，或者是说他的那个值还不够。会嗯，比如说的流进一的话，就会引发的一个不稳定，然后再就是一个会放我们的一个人力动作，因为之前的话，其实都是上千上百个我或者的一个规则去进行一些调整，其实都是呃，比较消耗人力的。然后最终我们落地这套计算资源调控服务的一个，呃，成果是什么样的呢？

第一个就是负合容器资源云成本降低20%，然后这个负合是怎么算出来的呢？就是由于在我们处理这些资源的同时，我们整个小通的D还继续上涨，那我们做到了，就是小通上的同时，我们成本还是下降的，然后综合起来就是说他原来。原来如果说是原来的一个计算资源按正常的Du增长的话，嗯，同比现在的就会嗯嗯多个多个20%左右，就是现在的一个资源的一个实际的一个落地的一个效果，然后集群整体的一个利用率较上限提升20%。然后日常容器资源维护，人力成本降低50%。就是一些。

扩容，扩容或者是一些应急的一个场景。另外一个就是冗于计算资源维护人力成本降低90%，也就是说之前扩多了，或者是呃，为了应急去加的那些HPC规则，现在都得到一个有效的一个。然后未来的话，其实这边主要是几个方面。我们虽然说是对了每个对每个HC的一个时间段的一个副本进行一个监控的一个比对，或者是副本的一个调整，但是它其实可以做精细一点，比如说我配的HC时间段真是需要配这么，那其实这实也可以控去解决问题，去把的一个大时段分为小时段，或者是分它的一个对应的一个时段，这样能达到更好的一个效果。另外一个就是精细化规格或者是配置的调控。

那其实我们分配了这么多资源，那它的一个配置是合理的吗？比如说我们的P的场景，P的场景。他有时候在资源部。不改动的情况下。单独去调对应的一个配置，其实就能得到很好的一个效果，那这里的话其实也可以做成对应的一个，呃，自动化能力。在不调资源的情况下，得到更好的一个效果，那其实变相的也是进行对应的一个本，另外一个就是引入我们事件驱动的一个扩。就比如说我们小鹅通有大量的一个卡夫卡的一个场景，卡夫卡消费的时候，它其实会有对应的一个阻塞，如果说是我们能把对应的阻塞的一个事件跟我们，呃，就是或者是。资源这块的一个扩容结合起来的话，那其实可以缓解很大的一些人力维护的工作，然后提升我们整个集群的一个稳定性。

好的，我的分享就到这里，谢谢各位主持人。主持人。好的好的，非常感谢我们张老师给我们带来的精精彩分享，那我们线上如果有疑问的同学呢，你也可以在本答区留言，我们讲师会在最后的问答环节为大家答疑解惑，那接下来就有请我们今天的第二位分享嘉宾，腾讯云中间件产品资深架构师侯世军。侯老师参与过多项国家信通院的云计算标准制定，拥有20余项云计算领域的技术发明专利，嗯，Cube waterter redis operator polarris等开源软件的贡献者，云原生社区优秀讲师，具备16年的研发、架构设计与运维实践经验，专注于云原生与分布式中间件等领域，目前在腾讯主要负责云原生pass产品的解决方案及企业数字化转型与落地工作。欢迎侯老师给我们带来服务，治理场景下建立云原生架构，支撑业务稳健增长。主题分享，有请。

OK.好，大家下午好，刚才张老师分享了如何通过容器化来帮助企业降本增效，按照CNCF对云原生的定义啊，除了容器化，那么还有微服务，服务网格等等一些方面，那么接下来的时间的话，我就和大家一起来探讨一下。服微服务服务治理的场景下，我们企业如何更好的建立云原生架构来支撑企业的业务发展？啊，这个是我的一个呃，个人简介啊，我目前的话在腾讯主要是负责呃，原生pass产品架构以及企业架构啊，转型落地等方面的工作，那同时也参与国家信通院啊等等一些呃云计算标准的一些制定工作。

那我今天分享的主要分为三个章节，呃，第一个是关于it系统架构的一个趋势啊，第二个是场景化的服务治理的实践啊，第三块的话是实际的一个落地案例和一些建议。那我们先来看一下呃，简单看一下这个业界的一些呃it系统架构的演化路径，早期的时候呢，一般的话，我们企业会采用单体式的架构啊，因为单体式架构简单方便，但是随着it系统的建设的话呢，越来越多的这个系统孤岛形成啊，许多的企业的话，通过引入啊ESB前端总线来去解决啊这种系统孤岛和服治理的一些问题。但是随着业务呃逻辑业务的规模的增长的话呢，啊ESD的一些瓶颈问题啊，它会凸显出来啊，在这样的一个背景下呢，啊人员生微服务架构应运而生。

云约社会服务架构的应用啊，它应该是更加的结构，更加的内聚啊，更关注业务逻辑本身啊，中间件的能力下沉到啊云基础设施，云是应用，从设计开始就要去考虑啊，将来是应该是运行在云上面，充分的去利用云的优势解决业务问题。那我们发现，随着资源技术。不停的这个匹配业务需求，那么不断的去促使it系统架构的啊，逐渐的转型与演进。那么企业的话呢。在随着业务的这个规模逐渐的增大，那么业务的随时发布，弹性伸缩啊，系统的一个平滑引进，以及能力的沉淀复用的需求也会逐步的凸显出来，那么这个对于企业来说的话呢，我记得我我觉得就是它既是一个需求。

啊是挑战，那我觉得更更是这个机遇啊，它更是提升企业核心竞争力的一个机遇。CNCF在2018年会生做了重新的定义，有几个关键点，容化服务、网格生可变。通过落地原生架构的，能够帮助组织提高研发协作效率，增强系统的可扩展性和可用性。提升运维、部署、交付效率，从而助力企业的技术创新，提高啊企业的核心竞争力。从IDC特等权威的调研机构的数据，我们可以看到，原生应用的趋势呢，也是在逐年的递增的，预测到2025年，全球将有2/3的企业将会成为软件生产商，超过90%的应用程序将会使原生的啊这样一个原生架构的应用。那么下面的这个图的话，是我前段时间从Google上面截的这个趋势图，我们从这个趋势图可以看出，以容器编排代表为代表的这个K8S和这个新型微服务代表的19。

它的曲线是逐年的这个上升的这样一个趋势，和这个一九，与传统的微服务代表spring cloud并驾齐驱。这也是当下企业中两种主流微服务架构的一种真实写照。那么微服务架构出的车轮之所以向前，很大程度上来说，它的确为我们企业解决了很多生产中的实际的一些问题。那么下面的话，我就分阶段的话，场景化来展开简单介绍一下，那首先的话呢，在这个企业的实际生产当中呢，我们会有许多的一些环境，比如说开发环境啊，测试环境，预发布环境，生产环境。

那么在代码的测试阶段呢，我们也会呃，有大量的业务，业务线要去做或产品线去做这个测试，比如说以腾讯我们内部的一些案例为例啊，就是比如说手机QQ，当然不光是手机QQ啊，还有其他的产品线也遇到了同样的问题，当时的话，手Q的话，研发全流程当中啊，有很多混用环境的问题，那么导致各个环境的啊，它的运行不稳定，链路长的服务经常会不可用走塞的软件测试的开展工作。由于这个手Q业务的调用链，它涉及到几十个上百个这样的一个服务啊，为每个分支的这个部署特定的环境呢，又比较浪费这个资源，又比较耗时，在这样一种情况下呢，我们通过啊，我们服务自己中心的标签路由进行流量染色。实现用户侧骨干将多环境组件复用，从而去节省了啊这个部署环境的一个资源，提高了部署效率，那么在发布阶段的话呢，为了更多的为了去考虑业务的啊版本上线它的一个灰度啊平滑及更好的用户体验，那么我们啊也建议就是说企业基于恢复这一中心啊，结合像CSCD的一些应用发布管理平台，能够去实现像金丝雀滚动发布力部署。

多种这样的灰度的啊，这个成灰灰度的功能，能够去满足多种业务的一个灰度场景和平滑过度。啊，在新上线和业务的功能和促销活动开关动态公告啊，技术组件配置发布变更等等一些，呃，场景的话呢，我们可以基于分布式配置中心，它的动态配置能力能够去啊灵活的去进行我们动态的开关控制。啊，在业务的运行阶段的话，那就更多需要去兼顾和考虑的一些问题了啊，比如说呃，多地域的，或者说咱们有一些跨境的业务的，呃，出海的业务的，往往就是说需要去兼顾新人的同时要去解决跨地域的容灾的一些问题啊，例如我们的游戏类业务啊，王者荣耀有荣耀啊啊游戏的业务啊，它需要进行这个全球开服，那么就可以通过这个啊原生网关恢复治理中心来提供接入层与应用层的多活容灾和就近访问，实现故障的快速恢复与容量的快速扩展。

那为了更多的去帮助啊业务获客，那么企业的话往往会举办一些啊元宵活动，像刚才小鹅通的张老师也说过啊，有一些这种优惠券啊，或者说营销活动啊，直播活动啊啊等等，这就会导致在这个活动期间的话，会有许多一些突发流量。一些突发流量的一些呃产生，那么这些突发流量产生之后呢，往往会对我们后端的业务呢，后端的一些核心服业务服务产生冲击，那为了防止后端的业务被发流量去冲，我们可以借助中心的啊，多种设置多种这种限流的一些规则，管控的规则，比如说通过接入层的这个服务限流，服务间的这个调用的限流。

呃，单机限流，分布式限流等等多种手段去保障我们活动的顺利进行，然后确保我们业务的一个稳定运转，所以针对突发理论上的时候的话呢，呃，限流，刚刚说限流是一个办法。但是呢，我们企业的业务呢，一般它会有核心业务啊，非核心业务。那如果说我流量特别大的时候，我一股脑的区域限流，那这样的话势必会影响用户的体验，所以有的时候呢，我们需要去优先保障我们核心业务的一个正常运作。啊，那我们可就可以借助微服务自己中心的，呃，熔断线理和熔断降级等等一些策略。

我们将一些非核心的业务降级掉啊，优先去确保我们的核心业务对外正常提供服务。那另外的话呢，我们当然也没法百分之百确保一个服务组件它是不会挂掉的。他肯定会有挂掉的时候。那么万一这个组件挂掉怎么办？所以我们要去确保，就是能够去保障，就是说它挂掉之后尽量的去减少，减少它的一个爆炸扳机，它减少它的一个波击范围啊，影响变。对，在服务自己的场景中呢。当这个服务的提供者，比如当服务提供者去调用某一个啊，这个提供方的一个实力的时候，当这个实力已经挂掉的时候，我们应该尽量的去避免我的啊这个调用方尽量的去不要去调用到这个有问题的实例，应该尽量的将它隔离开，同时的话呢，我们应该去保留这个，尽可能保留这个故障现场能够做到啊，方便后期的一个故障的诊断啊，故障的排查和规。

在有无服务，在服务这个啊，应用无服务法之后的话呢。呃，各种错综复杂的调用关系，各类的故障问题，也是这个后期的运维阶段比较头疼的事情。那么建议的话呢，啊，企业可以去做好事前的一个呃，可观测监控预警，以及这个事中的快速故障的定位啊，以及第一时间的一个业务的快速恢复。然后是事后的复盘总结。通过增强对微服务的，比如说全链路的调用分析啊，系统负载的评估啊，差异化的比对啊，以及系统分析调用啊等等一些这种运维可观测的能力，那这样的话就后的话，我们在啊实际生产当中的微服务的一个运维的更加得心应手。

刚才我分享的各种场景的一些，呃。服务的一些建议，那么接下来我们看一下。在企业的实际生产中呢，我们应该怎么去进行落地，或者说怎么样一个路径可能更加恰当？在企业的话，在前期的技术调研和测试的时候呢，我们往往会使用一些开源的软件，自己去搭建啊会议服务的中心。但是随着业务规模的增长的话，那么企业往往需要投入大量的一个研发啊，时间的损耗啊和资源成本，微服务领域的技术。它又比较复杂，设计的组件又非常的多，那么企业自建微服务中心的话，它就会面临着研发周期长，研发成本高，那么上线落地的风险也较大。

也会面临着后期的一些部署、运维、故障、定位、升级、维护等等一些问题，尤其是我们上到生产环境之后。开源软件呢，它会存在的一些bug，那么你可以去提交啊，提交你的一的PR，但是呢，往往开源社区去合，去合并你的PR，或者说去解决这些，修复这个bug的时间它是不确定的，有的有的你的bug甚至会会很长时间，可能好几年都有可能。那么还有一个就是说开源软件，它的一个可能避免的风险，受到一些国际因素的影响。所以呢，后期的话呢，啊，它的一个这个稳定运行啊，以及后期的一个升级啊支撑啊，都是一些问题。所以我们一般建议的话呢，那前期你可以采用开源软件呢，去自建呢，去调研，但到了一定的规模呢，我们建议还是基于商业化成熟的微服务产品。

来进行分阶段的项目建设，因为我们腾讯的话呢，呃，商业化的成是有具备商业化的成熟的这个各种微服的这个套件和产品，也是经过内外部的大规模的打磨沉淀，所以支撑了企业低成本的迁移，平滑的过度，每个分呃，每个阶段的这个分阶段的一个建设，然后呢，我们也提供了持续的专业的技术支持兜底服务。来支撑企业业务的一个稳健发展。那么另外一个除了使用商业化的啊这个产品之外，另外一个建议就是说啊，要进行这个。嗯。服务的原生微服务的架构的一个转型，或者说不光是说架构的转型，就是你进行任何一个可能说啊，底层的it系统的这个变更啊，啊或者说啊迁移啊，或者说变革啊。

或者转型这一块啊，都是一个，呃，比较好的一个建议就是说啊，建议循序渐进，平滑的迁移引进，一般的话呢，我们建议的话，先从这个增量的啊，新的业务入手。然后再是存量的业务，那么存量的业务也是先从边化的业务开始，边角的业务，然后逐步的往这个核心业务开始去进行演进啊，最后是全面的一个云化，对于这个存量的平化，存量业务的一个平化迁移这一块的我们也提供了像商务注册发现，然后网关的灰度迁移等多种的一些呃迁移的解决方案。我们腾讯商业化的，呃，华麦微服务中心呢，提供了面向多语言异构环境兼容一站式全链路的生态的这个配置与治理。

无论是这个JA还是购GS，还是PHP这种语言啊，无论是传统的这个还呃传统的虚拟机还是容器化啊，无论是supreme code的传统的微还是新的service的接入，那么SH都提供了统一的服务。治理管控、注册发现、动态配置以及全方位的运维观测能力，满足企业的啊微服务的开发、测试、运维等各个阶段的一个治理需求。那刚才我也提到了，我们提供多种的接入方式啊，这上面右侧我们可以看到啊，多种的语言的SDK，各种的框架，比如说像加PC组织的框架，以及提供呃，JA agent等侵入式的这种接入方式，呃兼容像主流的优瑞卡拉克斯等啊建的一些注册中心。

啊，这个是我们云的啊T界面，那么我们可以在这个界面上可视化的可以方便的去进行服务的治理的一些操作，那么我们也提供方案咨询，技术兜底，很方便的去投入使用。那除了这个工业云的呃PRO卖啊，维护自己中心之外，那我们也将工有云的全站能力下沉到私有云的tcs pass当中，那么私有云和公有云同源同构，基于tcs pass呢，我们就将2卖些。TSF框架网关消息中文件容器云整合成我们的企业资金工程的解决方案，向下兼容第三方的异构的二，然后对外提供恢复效益中件等各种各样的一些能力，那目前的话，我们也在像金融、政企、工业、互联网各个行业有落地案例，下面我们来简单看一下啊，我们的一些案例，那么前不久的话，刚刚做一下帷幕的巴黎奥运会，非常的精彩，那么我们腾讯呢？啊，腾讯视频啊，腾讯云也是央视频的重要合作伙伴，我们为央视频提供了覆盖客户端啊，前台中台和底座的数十个。

呃，应用系统通过PRO的帮助啊，央视频解决跨K8S集群的服务注册发现与治理的问题，为观众提供啊更流畅的视频，我们看到左上角这个图，我们央视频的话，它其实是在我们的腾讯的公有云以及我们的云上啊，都有这个节点，然后公云和专云通过这个专线去打通，然后通过方smartsh来提供这个。异构的、多环境的、混合云的，这种国际群的服务发现所致。

那么这个时我看一下这个是AI教育平台的一个，当时这个平台上呢，它有上万个服务节点，它原来是基于优瑞卡去实现这个服务的，出发现那的这个U瑞卡的一些问题啊，比如U惠卡新的版本，它已经不再开源，以及这个U瑞卡的这个它的一些架构局局它的扩展性啊。问题，所以的话，当节点非常多的时候，已经上万个节点，它的注册及上报心跳，那这些情况呢，会导致这个负载特别高，因为经常会出现这个节点状态异常的一些问题。和PRO的相对这个U拉S传等传统的一些注中心来说的话呢，我们采用了这个算分离的一个架构。我们可以做到这个呃控制面完全的一个状态，那么计算层就可以呃接入更多的一个节点，然后随着这个呃业务这个压力的增大，我们可以去做横向的扩展。

啊，这样的话可以轻松的去，呃支持百万机的一个快速扩展，那同时的话呢，我们也兼容了呃，UV卡的这个接口啊协议，那么搞AI教育平台这个客户的话，他就可以。把原来的优卡无缝的去迁移到我们的这个PRO系统。然后这样的话就可以实现一个呃，这个业务的一个扩展，扛住了它的一个压力啊，同时我们额外还提供了像可观测啊，跨中心的股灾啊，支撑了它的业务的一个发展。这个是一个游戏对战平台的案例啊，一个每一个游戏的间呢，它对战的时间不一样，它消耗的CP也不一样，负载不一样啊，通过每台游戏serve的话啊，把这个负载的信息上报了啊，根据规则啊，计算调度节点的一个负载权重。来去实现各个房间的一个均衡。啊，这个是我互联网业务的一个的类型，它的一个权杖辅助的一个能力，其中就包括了南北向的网关的一个服务治理，以及东西向的这个，呃，服务间的一个治理，我通过我们工业云的TS12式卖血，那实现的微服务组件的一个免运维，高可用。

一键升降配的能力，那么解决了用户原来需要他管理者原来管理为服务组件的一个复杂度。然后啊，运维成本高，可用性建设等等问题治理的，这个治理效率也是提升了60%以上。另外的话，我们通过PRO瑞斯贸企的话，帮助跨境国际物流平台的去解决了管理，管理恢复弹性流量控制，配置管理故障服务发现。等一系列的一个问题实现了啊，这个人原生架构的一个改造升级，帮助用户整体的微服务运维效率成本啊，运维成本降低80%以上。

OK, 我今天的分享就到这里啊，感谢大家的聆听，嗯，好，也感谢侯老师的精彩分享，那我们线上如果有疑问的同学也请您在问答区留言，我们讲师会在问答环节为大家答疑解惑，那接下来就有请我们今天的第三位分享嘉宾，腾讯云消息中间件技术专家李占辉李老师负责消息中间件luckyy MQ mqtt研发工作，Fy rocket m q, 嗯，Apay rocket MQ p MC有10年以上的云产品研发架构设计经利，曾主导rocket mq5DNX整体架构设计，分级存储多语言SDK研发及落地。欢迎李老师给我们带来基于全托管MQTT构建具有成本效益的企业LT业务平台主题分享，有请。哎，谢谢主持人的介绍，我今天给大家带来的是一款啊M支持MTTT协议的呃，消息主件产品。

首先呢，就是我的分享内容包含下这几个方面，大体上呢可以分为三部分，第一部分呢，就介绍一下什么是MTT的这些协议的演进，在哪些场景下有比较好的使用。的使用和集成研发的呃和集成的呃等研发成本，呃，我们这款云产品呢，可以。呃，极致的。通过机制的弹性，可以有效的降低用户的使用成，然后呃现有效的降增效。之后呢，就是介绍一下我们客户案例。首先是M，什么是MT，现在就是V最广泛的一个场，最广泛的一个协议，呃，几乎上是一个事实上的一个标准，嗯。

呃，他的这个协议呢，他呃在这个。呃，在市场上其实有很多很多的这个客户端，这些软件站，然后。呃。有也有非常好的这种硬件模组的支持，就是我从一些这种硬件的这种呃，网站上啊，可以去看到，包括像E32这样一个，呃，一个就是大概就是十块钱人，它里就有一个完整的M的的支持，然后因此呢，它也有就是从这个生态上来看，有着强大的生态。生态支持。呃，就是为什么要用M，除了刚才生态方量量高非小啊，很容易的实现，而且就是不容易出错，因为简单嘛，其次呢，这个协议呢，本身实现了方向的通信，从设备到云和从云到设备这个双向的，呃消息的推送啊，都是有呃前一级的支持。

呃，还有一个呢，就是这个。呃，这个协议呢，就是在，呃it这种呢，就是说最大的挑战就是的数量比较多，百万级或者千万级的这样一个设备。有可以有效的支持这样的使用场景，嗯，后边一个呢，就是消息的投递的可靠性，它完整定义的就是三个KS，就是服务的质量啊，就是相当于最少一次啊，然后最多一次完整一就是这样的三个使用场景。I经生的M。

然后对，比如他通过message，通过这种session的呃恢复，然后通过这种的方式，就是可以对呃企业的业务程序，就是业务的状态做一个很好的恢复和支持，最后一个呢，就是它的安全性M，就是尤其是在升级到这个协议版本以后，然后支持了就是方便用户实现SSL这样的一些安全的协议。然后MPC协议呢，就是它是一个标准的pop的一个协议，其实是这样一个消息的模式，就消息模式大家都知道，基本都是点对点和PU萨这两个协议形态，然后他这套这一份协议呢，呃不像其他协议，它就是在整个协议的规范上很完整的去定义了整个的业就是的这个框架，所有的层面的要求比较明确，这样的话，其实呃对于整个生态有非常大的优势，呃，它的比如说它的客户端，它在SDK可以在很多的这种标准的呃生就是的这些实现上可以跨，跨来跨去就是可以实现的呃去迁移。

然后我们看这个就是标准的，比如像像这个图上就是一个这个温度的温度的传感器，然后它采集到这样一个温度的信息，可以过M协议传到broke上，Broke呢，然后再把的协把这样一条消息，这个信息推送到对他有关注有的样一个客户端上。既然。然后M协议，然后我们看一下他的这个眼睛历程，1999年的时候呢，是IBM和S，呃，S link, 就是现在叫s s link.啊，这就这样一两个公司一起合作推出的啊，最早呢是用在啊这个石油管道的监控上，通过卫星连接啊，我们都知道这个是石油管道啊，像这些都都是，呃，非常长，就是这样的链，这些客户端数量也非常的多，而且这个网络卫星通信的延迟也很大，然后网络也很低，网络也不是很稳定，所以MP协议从第一天设计的时候呢，就。

对，这个整个的协议的就是非常的compac，非常的简洁，然后呃，内部的每一个字节的使用呢，就呃都是比较呃有考虑，比如像我们自己定义过协议的都知道，比如经常使用的这种less field的这样一套协议的定义方式啊，我们就会当前一如放一个或者表，我这个pack多长，像M里呢，就是一个表都会使用一个可变的这样一个字节的表示，就是尽可能的去节约，就是能用一个字节表示就用一个字节，然后能节约一个就是一个。

然后F协议呢，首先它也是一个，其实它也是一个比较开放的协议，在19年之后呢，然后到现在已经经历到了第5个版本，那在这个整个参与的过程中呢，也有越来越多的厂商去参与进来，去扩展一些特性，比如像最新的MPT5里就是实现了像共享订阅，然后消息的过期主体的别名。以及这种呃的这样一些特性。就是还有包括它的安全的特性，刚才讲到有也有，也有一些更多的插入式的支持。然后我们再看一下这个使用的场景，MC典型的使用场景，从它的最早的来源，比如像能源，像石油，石油管道这些运输物流，智能制造，智能家居，还有消费电子类交通啊，就是从我们自己感知的啊，比如像呃物那个典型的物业服务，或者是说车联网服务，这都是最广泛使用的一些场景。

呃，包括小程序这个也是越来越多的这种手持设备通过小程序，然后实现过小程序基M这样的推命令。呃管控，呃管控命令的息。然后我们再看一下这个使用MP协议里边典型的一个场景，比如说我们的这个这个产品呢，在。呃在客户端通过呃网络连接到，连接到负载均衡，这就连接到LB之后，然后是呃到了我们这样一个LT产品，也就是说我们这个产品其实是一个下理解成一个节点下边挂载了非常非常多的客户端。那我们这个节点里边呢，基本上是有这么几个组，有一个是就是我们的协议节点，就是broke节点，不是节点里边呢，呃1然后我们会嵌套了一些规则引擎，规则引擎就是方主核心的理域，就是做数据的呃转换，然后方便后边的数据集成，就是和其他云产品啊，和现有的业务系统啊，数据格式呃做转换啊，然后做对应的筛选，数据的筛选转换，做这样一个事情。

然后。然后在这个基础之上呢，然后我们实现了就是从提供了一些插入式的这样一些认证授权，然后P和CI的体系，以及这个测和报警，就是这个整，就是负载均衡，加上我们这样一些协议的节点，以及我们后边这些通用的这些能力，组成了我个M的实例，这个实例呢，就是这些节点是我们是做了一个自动扩容这样一个特性，就是可以按照我们的QS以及我们的的连接数，然后根据这个节点的负载做这的探索。

然后对使这个协议的使用者来讲，就是说我们的集成能力特别重要，就是说我们的负面集成能力，就是说我们提供了对于其他的中间件，别像卡夫卡呀，以及函数计算等方面这些云产品的这些集成，也就是说我们可以实现比如说业务，呃，但我们的SK或者的设发送一条消息，然后通过比如引数据变换，通过我们的数据的就是嗯，这样一个集成，一个连接，可以直接去触发我们这个，比如说一个函数计算，然后R计算里边呢，再进一步去。呃，集成到业务平台里边。也可以，比如像这些消息通过订阅，然后把这些数据转发到消息中间件，比如像卡夫卡这样，然后接入到用户的大数据业务平台里边去。这是我们这个典型的一个使用的场景，然后我们这款产品呢，呃就是呃实现了就是一键创建进去，然后开箱启用，呃其实这个东西呢，要我们一般叫它enterprise ready就是呃，企业化就是就是企业能力完全具备的一个状态，然后它有高可用啊，高可靠，然后高可靠这方面上呢，然后我们实现了多A的部署，然后当然我们是个region进化经营的，呃然后同region里头是多个，呃可以多个A去做部署，然高弹性，然后后边会比较详细的介绍，然后我们是可以通过快速的扩容，然后实现了几乎无限的连接的支持，到百万级或者千万级的这种在线设备就没有问题。

然后还有呢，我们实现一个比较。完整的可观测体系，比如包括matrix login, 然后ping这样这样的一些能力。呃，包括开源兼容，开源兼容就现在我们现在是云上的产品是完整的兼容的社区，3.1.1的协议，然后5的协议呢，然后我们也在做兼容，然后呃，预计4可以可以公测。

然后下面介绍一下，就是我们的这个，呃，产品的底层是怎么做到的，能够快速的去扩容，支持无线的链接，首先我们这个产品呢，是基于存储计算分离这样的一个理念做了一个设计。然后。计算的这些节点上，呃，这些节点啊里边，然后呃，通过就是把这些所有的这种状态的信息呢，就是做了一个卸载，卸载到专门的存储节点，然后计算节点呢，相当于又实现了每个项目的协议链接，保持认证授权，然后观测限流，那就是这些能力，把这些统一的能力，然后放到这些计算，这些计算的逻辑放在这些计算节点。这些节点当可以做到按秒级实现扩容，然后存储节点呢，然后主要是呃，它的压力来来自于这一个。

离线消息就相对于离线的这种消息叫重放回放，嗯，主要实现的这样的一个能力，这个这个能力里边的是我们。是通过就是把现有的一些可靠呃可靠的成熟的云存储产品做了一个定制化的开发，然后把整个的整个IO，然后实现了呃，把所有的IO尽量的把它去顺序化，达到最对IO的需求大幅的降低的这样一个能力，然后因为我们的呃是了解这种M的同学都知道，就这个M里有大量的这些量的，然后我们这个呢，在这。嗯，部分的存储节点里头的表示呢，是通过K的形式，通过L这样一个形态去做一个表示，这样的话把就是这样一个节点的一种处理结构之下呢，然后我们的。IO呢，也是从可以从原来的随机IO转换成顺序的IO。

然后存储节点呢，然后我们实现的化的部署，然后计算节点整体呢，然后我们是按租户，然后隔离的部署的。这样你就可以做到最好的扩容性，然后以及整个成本的降低。然后下面介绍一下我们这款产品的这个呃，安全的方面的建设以及能力，就是我们这个产品呢，是在呃网络的传输层啊，然后实现了就提供端加密能力，但是这个很多，比如说内网VC打还是可以用户选择走这种不加密的路线，因为这个传输层本身就提供了加密的，呃这这个功能。呃，默认的，相当于每一个实例都会配置了默认的一个C证书，然后也支持用户自定义的双向的S认证，然后在认证方面的，我们提供了像用基于用户名密码，然后内置数据库这样一个方式的，呃基的basic这种authentic。

其次呢，我们也实现了呃提供了完整的GW的认证啊，包括呃，就是基于密钥形式的，基于证书形态，以及WPS这样支持证书轮转的一个GWT认证。呃，其现在还我们还支持了，比如对于这种像ILV这样的，就是网这样一个业务场景的，就它的每一个设备呢，都是高价的，有高价值的设备，就是一个呃，车这样一个场景，我们也支持了，完整的支持了P就是叉50这样的一个。一一证的一个形态，也就是说每一个客户端都有一份自己独立的证书，然后所有的认证过程完全基于这些P去做认证，那除了这个现成的这个支持，然后我们也支持用户可以呃把自己现有的一些认证体直接来类似通过HT的形态，就是相当于每一个请求。

然后，然后关联。关联企业自己现有的HTP服务，然后把他们把这个现有的证过程起来也可以支持的，以及比如像或者LP，然后发现了把你的用户的账户信息，认证信息存储到这现有的这些体系里头。授权方面的，然后我们支持了呃，比较灵活的，类似于看好这样的一个数据链路的授权策略，呃，相对基于资源条件，然后以及影响这样一个模型，相当于这个3呃3块，然后提供了这样一个标准的，也很灵活的，或者也也是比较通用的这样一个授权策略，在这个授权策略下，用户其实可以自己定义出RC啊，就是这些常用的，嗯，就是用户权限分离的这样一个策略。啊，我们的这个，呃，支持的一些条件里头，像资源化这个基本上都因为是个消息类的产品，中间件啊，基本都是像topic或者用户，然后里头的条件呢，我们可以现在支持的action action, 包括比如说像connect啊，Pub sub1这样的一个动作，然后对client ID啊，用户名，然后用户客户端的IP，包括消息的是否，然后以及po OS就是服务等级，就可以做非常精细的控制，这样可以控制比如哪一类或者哪一个用户或者用户名或者ID拥有什么，对哪些topic有着怎么样的一个操作权限。

嗯，除了这个，就是除了这个维度比较细之外呢，然后我们是在一个维度的支持上也提供的灵魂的，比如说我们可以支持啊，这个world card的这样的一润，就是我们就类似于正则式这样的一个表达式，这种方式，我也支持一些这种变量的，比如说我们可以把用户名啊，然后我们的证书里边的像common name, 然后直接可以提供这样的变量，可以用在用来定义我们的策略。

其次呢，我们也支持了这种JWT的ACL，就相当于说我们JWT就是这样的话，就是如果用户现有的一套完整的，呃，这个其实这个其中场景还是蛮多的，呃。就相当于说他的GT里头可以直接包含进去这个用户，就是有拥有这个token的用户，有哪些权限也可以完整的支持。然后还有呢，就是就是跟这个认证一样，我们的授权服务。授权服务也是可以直接继承现有的啊，这个服务能力就是相当于说可以通过TTP service这样的一个把你的授权的策略，然后直接有到现有的里面去。就是下边呢，我们介绍一下我们这个产品啊，提供的数据集成能力，也就数据集成能力基本上就决定了我们这个产品，比如说集成到现的业务系统也是的成本的高低。

那我们这个能源，相比于说我们定义了数据源，然后定义了一个。会在引擎或者数据的一个操作，然后之后呢，定义一些，或者叫我们叫action或者叫think都可以，相当于就是说我们提供了一个类似于ETL变换一样，就等于说我们定义源数据的原来是什么，然后进到这个MPT里边，然后做哪些通过会对引擎啊，通过这个数据集成的。呃，模块，然后可以。可以把这些数据做对应的变换，然后或者说增补，嗯，变之后呢，然后可以把这个变化后的数据，然后关联或者调用到第三方，当然也可以调到最前，相当于比如说publish，我可以把一个topic，就举一个例子，就是我们把一个topic的消息，然后做一个变换，变换完以后我放到就是转到另一个topic里头，当然我也可以把它变成一个函数的对个SC的调用。

这个东呃，就是这个能力呢，就是可以大大的降低用户使用起来，或者集成现有系统做增量开发的时候啊，这样一个场景的开，主要是研发成本。我们看一看一个就是呃，用户的案例吧，就是之前的时候，比如一个用户在AWS上去做了一个架构，就是这个，这个使用场景呢，主要是它是IV的一个场景，就是网的一个场景，嗯，就我们都知道呢，这个。AWS上边的这个溢价还是比较还是有相当的比例的啊，然后为了降低成本的，然后他们。呃，就是迁到迁到了我们这边上去，那就是。在整个整个迁移的过程中呢，然后我们的现有的一级证的能力啊，以及PK及就是P这一套体系可以完整的去兼容啊I的这个这些策，这些能力的使用策略。

相当于说如果从消息的呃角度来看，相对于TCU会控和题策略和呃以以及他的，比如像他的监控信息啊，就是呃，比如像对车机发一些指令之类之类的，把这一些消息，然后从他转到MKT的这样一个服务器上，这个服务器呢，他通过数据集成，刚才讲的数据集成能力，然后把数据可以接到C卡普卡里面，呃C再从C卡夫卡，它相当于关联了大数据的处理，以及比如我们函数啊，它是从这边去关联的一个函数。到这样一个能力里头去。嗯。是另一个事情呢，就是除了我们支持了标准的P，呃，标准的协议之外，我们还支持了啊，然后P协议这个这个呢就可以大于，因为我们的考虑到一个场景就是我们的客户端会非常多，当很有时候一些客户端。

就是就他支持他要需要订阅很多很多订阅关系，就是这个每一个订阅呢，其实都是一个成本。然后我如果降一个点对点对点对点这样一个场景呢，我们会发现也是一个比较通用的需求，呃，要支持这样一个能力之后呢，可以有效的降低用户定位关系的数量，还有一个一个动机呢，就是我们提供这样一个能力，就是因为点对点相对于之前的pop，它的这个链路还是，呃要简化一些，这样的话，如果使我们有机会去提供更优质的服务，比如说把延迟能做到有效的降低，那我们现在来测试呢，大概能降低百分之五六十这样的样子。嗯。然后下边也就提供一个长，呃，一个用户的案例啊，这个用户的案例呢，然后就是。使用了我们的，比如说除了刚才介绍的那些能力之外，就是呃，这是一个换电的一个风，就是就相当于说这个，呃有有时候呢，就是它需要对，比如像充电桩啊，然后换电站呀，然后去实现这个。

管控，直接管控这样一个具体设备，这样一这样一个需求，就使用了我们刚才说的这个点对点PP的一个协议的能力。就是我们这个扩充能力。啊，这个除此之外呢，就实我们其实还有一些正在呃研发的这一些能力，就是就是这个呃，这些能力也包括比如像m c quick, 尤其对LV这种快速移动的设备比较有价值，就是可以减少这种便捷同连的时候的成本以及需要的时间。呃，这个用户呢，最标准的就是说实现了就是我们MKT主要是我们数据集成到C卡数据集，以及和然后消息的完全的互通，嗯。

在这个场景下。就呃相比如说数据可以呃，非常低的成本，只需要在我们的这个管控上，就是配置一下这个数据互通的规则，那就可以完全把这些数据两方向做了一个打通。好，我就这些。嗯，谢谢大家观看。感谢，感谢我们李老师给我们带来的精彩分享，那也再一次感谢我们今天三位老师的精彩分享，那下面呢，就进入今天的KA环节啊，有请我们的石军和占辉两位老师来为我们解答问题，那我们看一下观众的问题啊，问到以前呢，是比较老的传统价格架构，那想要做平滑迁移如何去做呢？哎，诗欣老师，嗯，其实这个跟第一个问题有点相似，都属于这一个，呃以前的架构呢，往新的这个架构去迁移的这样一个例子啊，只不过说以呃第一个问题的话，它是呃，他可能是已经做了一些微服的改造，我前在呃拉克斯方面，那第二个问题呢，可能说呃，我理解这个，呃观众的意思就是说他可能是比较传统的，比如说他可能甚至于有可能连服务化改造都还没做，或者说。

啊，有可能是单体式的，或者说已经做了一些拆分啊，可能是啊，或者说ESB的那种那种结构啊，这些比较传统的，或者是一些老的方向，那么这种情况下，他要往一个新的这个价格去移，或者往北极星移，或者说往新的这个，比如说呃，Service也好，还是说首先靠的这种这种去迁移的话。那你要是完全去直接在框架层面，在这这个这个啊，应用层面，你说完全去平滑这个是啊，直接去怼是很困难的，但我们有一种方式啊，就是说在前面加一个网关，原始网关或者API啊网关，然后呢会有网关层去做封装啊，网关层的话呢，将这个啊。

比如说你原来是一个单体式的，里面有三个模块啊，我在前面加一层网关之后，我先把这个啊接口就之前你该怎么调用的封装，我直接通过网关层包装的，呃，走向你的后端的，呃，单体式的各个模块，然后你比如说你三个模块你拆了一个出来了，拆到这个，呃，新的。这个架构里面，比如说拆到这个149里面，或拆到设备什么写里面，拆到我们北极星里面。那我网关上面我去做一些调配，我让我往这个原来的这个啊接口的指向啊，那个模块我改为可能指向新的这个，新的这个拆出这个服务。那在这个过程中呢，我们也可以去灰度，比如说我先90%的或者95的流量都还是指向原来的单体式的那个，呃，那个程序，然后5%的流量我放到这个新拆出来的这个，呃，这个服务上面，或者是这个微服务上面。

我去观察做灰度，如果没有问题的话，我再去逐渐的放量，比如说我50%的两边去分，那那再观察没有问题，我我可能啊，90%的都放到拆下的那个服务上，那10%的还在原来的单体的那个模块上啊，采用类似于这种方式，我们可以逐渐的把剩下的这些，呃，这个单体中剩下的模块也逐步的去做做拆分，那还有一种它不一定是单体式，它可能就是一个比较老的架构，它也不一定是单体式，它就是。你也很难去改，你也改不动了，就是有历史包袱，那它他可能就你就把它放在那里，你也不要动它，然后呢，我在旁边去搭建一个新的，以新的架构，我去我去这样去弄一套，比如说我以新的服务网格也好，还识别套，我去我去搭建一套起来，然后我去开发一套新的，那这就存在新老并存的问题。

那前面我可以通过这个呃，API网关，或者说我们通过一些像呃这种负债均衡，或者n in increase, 或者说比较比较常用的就是网关了，我们可以去做灰度，那这个是可以就是说你原来是改不动的情况下，我就先搭建一套新脑如何去做平滑灰度的一个方法。哦，这个是第二个问题，我就先这个就先回到这里，这个也是呃，比较常规的一些平滑的方法。好的，谢谢，嗯，我们看一下下一个关注的问题，问到北极星是如何实现那管servicesh网络应用的，还是世军老师，嗯。OK啊，刚才我在分享北极星的这个接入的时候啊，北极星呢，它是支持很多种接入方式啊，比如说多语言的SDK，就是不管是Java还是Python，还是啊还是啊，然后以及这个呃。

各种框架，各种注册中心，那么还有加微镜头，还有set com, 那这种呢，这个呃这个问题的话，就是其实跟刚才我说到的塞卡的接方式这个是有关的，就是说呃，它这样是符网格的，那那么它的底层的话，就是它的运行的环境，它可能是呃，K8S或者是容器化的这样一个一个环境。那跟传统的放在这个物理机上面，部署在物理机和虚拟机上是有差异的，我们新的这种北极星的话，它是去，呃第一个它是区兼容的这个，呃，这个。一四条的这个叉DS的协议啊，就完全做了完全的一个兼容，那么你这个把业务放在比如说放在这个K8S的pod。那么这个控制链它是因为完全兼容DS协议。它可以。

去去息发这个配置啊，控制指令到这个proxy，那同时也可以啊，去接收这个这台的上报，就是这一块是完全没有问题，我们做了兼容啊，另外一块我们是跟K8S的API去做了打通啊，里面的一些呃呃，消费者的信息的获取啊，啊这一块的一些呃信信息的收集管理啊，这块我们都是去做了接口的兼容和打通。所以的话啊，这样那这样经过这样一些这种兼容之后的话呢，你可以理解北极星的话呢，它的这个控制链的话，你可以理解它，你可以想象成它是一视图的那个控制面，可以想象成这样一个这样一个一个位置，就是说呃，他已经完全去做了兼容。所以这种情况就可去管这个。

类型的应用，那同时呢，它也可以去蜡管视频靠的啊啊的其他的类型的这一种应用，因为我们也是去完全兼容的，像视频靠的。这些组织的一些像八宝这些组织的框架。哦，那那我我这个问题就我先回到这里啊的，谢谢谢谢老师，嗯，感谢感谢陈军老师，那呃看我们看下一个观众的问题啊，呃问到MMQTT具体是怎样帮助公司降本的啊，这个问题请占辉老师来帮我们回答。那我觉得应该从这以下三个方面去理解吧，就是首先第一个呢，就是我们提供了比较灵活的数据集成呀，然后这些安全呀，这些的能力，就这些能力呢，一方面呢，就是可以有的是代码，甚至说就是通过写几条C库的语句的方式就可以完成很多业务的这种诉求，就是能够帮助企业，就是现在降低开发的成本吧，因为这这方面开发成本就是很明显的一块儿的这个支出。

还有一个呢，就是说我们这一些产品，就是对现有的这些产品能力，现有的比如包括云产品啊，包括现有的产品都是一个就是可集成的一个状态，有要么集成或者被集成的一个状态，就是这样，这样就可以大最大化的用现有的企业的已经支出的这种it成本。这样也可以就是节约的对节约或者复用成本，还有一个呢，就是说我们刚才重点强调了，就是说我们就是通过一些技术的手段，然后把比如我们的这些broke块，这些状态做到做说就是内存，就只有内存，它就是没有持久态，做到无状态，可以实现快速的扩容和缩容，这里就给我们呃提供了，就是相当于说我们的这个实力的规格可以快速的调大或者调小，就是skill in out.呃，后续就是现在我们还是基于呃实力的规格在售卖，然后不过呢，我们的规格可以定的非常的细致，也就是基金基本上匹了变成一个形态的售卖的的形式，后续呢，也会提出我提供完整的这种呃完全形态的产品售卖。

还有一个呢，就是说我们呃，可以对比一下开源的这些产品能力，我们通过技术创新呢，就是就是把这些我们的I，包括储啊，IO啊，然后这些呃，资源的使用上就更有使用更有效率一些，这样的，然后我们可以持续的更有竞争力的产品。好，就就是这些。好嘞，感谢那各位观众朋友们，我们本次的问答环节到这儿就结束了，也感谢两位老师再来的精彩回答和分享，时间过得很快啊，我们今天的课程进入到了尾声，再一次感谢大家对我们的参与和关注，我们下一次课程再见。