OK 我们就先开始吧我是来自英飞网络的张淼以前我是几个月前还在百度今天我分享的题目是如何建立一个面向云旋生的流量管理平台首先做个自我介绍我之前在清华首先待过12年最早是做底层的网络的最早是从97年开始做路由器然后之后在多家公司做互联网的应用然后12年到百度然后做了10年多主要集中在应用层的附载均衡然后包括在百度做了代码委员会的主席做了出版了代码艺术这本书可能很多做开发的同学会有兴趣那么今年4月份我们这个团队是独立出来专注地做我们的附载均衡的技术那么首先讲一下就是附载均衡刚才其实下午两场前面也讲了不少那么应该讲附载均衡这个技术其实已经有很多年的历史但是应该讲这个技术目前传统的技术其实是出现了一些问题那么右侧是一个非常典型的部署的架构那么前面是SL卸载然后下面是防火墙然后在之后是按照业务纵向的会建立它的四层及七层的转发机群那么这个四层的设备传统设备它还是非常复杂的功能也非常多但是应该讲它在七层处理能力上会有很多的问题所以我们在现实中会发现很多的客户它会使用NGX来作为它七层的扩展的能力那么这个硬件本身它其实不符合我们云原生的这种要求就是无法动态扩缩容而且升级起来比较困难那么更为重要现在来说很多的云索要的能力那么传统的无论是传统的一些网络设备以及像NGX这些老一代的七层它其实不支持比如说多速户的能力其实像设备和NG这样的开源其实它支持的都不很好另外就是配置的变更其实在我们云的场景是非常频繁的但是配置变更其实做得不太好当然刚才讲的那个NGX其实华冰讲到一个很重要的NGX就是它都可以动态非常好的进行动态的加载那么包括还有统计的能力这其实是可观测的要求那么我们也会发现传统的这些无论是硬件还是它的软件这方面其实都不太好还有就是因为安全能力的缺乏所以造成这里面需要把安全相关能力放在外部而且是一种串联的架构那么这里面很多的使用场景是基于硬件也是没有困难能力另外防火墙这里面是一个串形的是可能出现故障的点可能出现由于你的配置的升级导致性能下降甚至说整个系统的崩溃另外就是还有现在一个新的场景叫做多处理中心的调度这里面有些金融场景叫同生双火那么这里面的方案其实来讲原来主要基于DNS那么DNS这方面存在的问题就是调度能力很弱生效速度比较慢因为它基于缓存机制还有就是整个精度是比较低的如果你想精确地在多个数以中心或是多个集群间进行精确的流量调度这是非常困难的另外对于设备来说还是沿用很早之前的管理方案就是SNP 命令行等等机制这些也不符合我们现在讲的软件定义网络这样一种趋势那么我们看一下现在这个对于整个流量转发的一些需求首先基本的讲负载均衡最基本的需求是要稳定就稳定是负载均衡的第一需求这其实被很多的同学忽略认为说性能或者功能但其实是稳定性是第一需求然后是性能然后是相关的一些熔断保护安全等等那么从现在应用角度我们可以看到四个需求比如说可扩展支持多云和混合云的部署它可以随便的迁移以及说高可运我们可以快速恢复还有就是要支持密基带这是从现在应用提求的要求而从云原生和微服务角度我们发现动态扩缩容大规模的应用路由现在微服务做了拆分那么服种类是爆大式增长所以它的整个应用路由表的膨胀是非常厉害的包括在很多的一些大型客户出现到几万是超过10万条的路由表还有就是多K8S集群那么如果大家去看CN4F的每年的调研报告会发现很多的应用的企业它的K8S集群是超过10个的在生产环境所以多K8S集群的切换快速或精准的切换成为一个钢区还有以及服务间的安全防控制这是安全的需求那么我们这里面提出的一个思路是什么就是我们要从一个简单的负载均红系统进化到什么的一个流量管理的平台这个平台那么可以看到它看到一个独立的平台那么这个平台其实它是可以把流量向我们计算的平台去转发那么这个计算咱们现在谈K8S是一个容器的但是很多的企业里它还有它的遗产对吧它有无理机的有基于虚机的那我们其实把整个流量转发平台独立出来之后其实我们不用在乎说它到底是不是K8S而这并不重要对于流量转发平台它看到的就是一个服务的实力就是IP加端口它可以把流量转发过去那么对其他的也是可以接种那么在这个整个流量转发平台之上我们是支援的功能包括转发包括调度还有可观测还有安全这个平台整个这些功能都可以提供那么在这些平台内部我们也是一个面向远远性的架构包括四层七层是各自独立的也就是我们现在常说的四级层要分离那么为什么要分离因为四级层的属性很不一样需求很不一样四层是要求性能比较强大它要能尤其对于南北向我们要接受外网的巨大的攻击的挑战而七层要求它的能力它的能力功能比较强要能支持快速叠弹所以我们这里面会可以选择不同的技术战而且可以各自进行扩容这其实也是一种微幅的思想实际我们把原来整个的一个放在硬件里的实现变成了两个独立的服务那么它可以各自根据自己的需求进行一种扩展所以这种架构其实是比原有的这种基于硬件的架构要更加先进那么在这个新一代的平台我们会发现它有几个特征那么这总结了十个特征第一个 首先它要软件化它需要进行快速的扩容那么后面几点四一层的分离以及多组刚才讲到这个硬件它是主备的那么包括数管评的分离这几点都是为了它可以快速过的扩展另外刚才也提到我们多云或者多极群的调度能力这现在也成为一种必须还有刚才提到了对于微服务场景下这么多的服务的类型我们需要具有比较强大的路由管理能力那么我们有一些伙伴反馈就是传统的比如像NG这样的实现它可能比如支持几千条路由表就已经遇到一些性能平静而我们现在实际的场景可能要支持几万条路由表还有就是可观测就是你的流量要变得可见以及它自己要包含安全能力以及包括多组户多组户其实刚才前一个报告有同学问到这个问题其实多组户是一个在敏捷发布是一个非常强的或者是一个非常强的需求在传统的很多场景是上线是由一个韵围团队统一来做的那么这个效率非常低基本一天最多两个窗口但是在多户场景下全线进行隔离那么各个业务它是可以独立进行上线可以它不受到时间窗口的限制可以其他人随时上线所以这里面多组户其实对于整个敏捷发布是有很大的帮助的另外评论一下一片接口这个其实在这个时代是变得非常关键的就是软件定义网络那么这些都是很多配置的变工是由我们的程序来启动并不是人来启动所以这边接口的完备性接口的性能就变得非常关键所以我们这里面这个管理评验这里面数据面和管理评验进行分割然后管理评验主要是四个功能第一个配置的管理然后第二个对整个平台转发的状态进行监控管理然后第三多组户的支持然后第四个就是要对向提供比较强大的API的能力那么现在很多开源其实它并没有提供很强的API的接口然后下一个就是我们对于整个底层引擎的生态的一个对比那么这个领域确实这几年产生了很多的新的项目所以很多同学也非常困惑到底选择什么样的技术那么我们也是大概在一两年前做了一个整个生态的一个疏离我们这里面是按照语言来去疏离的就是发现有四大生态第一个生态是NGX其实它是C加Roy那么这是一种技术然后这个应该讲历史的存量非常大然后第二个是Avoy前一个演讲就是关键Avoy它是快速崛起对这个在也是CNCF的毕业项目它是基于C加加的然后第三个有构源我所从事的这个BFE这个项目其实是属于构源生态然后第四个是Ross源Ross源是为了解决C源的内存的安全性问题所诞生的增益源那么我们看一下刚才讲到就是从稳定性的角度出发我个人看法构和Ross才是未来那么可以看到这一连就是C和C加加它在内存的安全性上有非常固有的问题大家可以发现就是像比如说像这个Avoy大家可以看到CVE现在爆出来非常多的漏洞这个问题是根本没法根治的包括C语言包括还有Ross这里面其实Ross在一些项目里广泛地使用但是真正有经验的系统程序会说把桥本语言用到一个系统机转发是非常不合适的所以在前年也在上海避战当时出了一个非常严重的故障7月份出了一个5小时停机的故障当时是因为Lua的GIT当时触发了一个bug然后导致整个配置推上线之后整个出现死循环CPU全部打满但是处理了5个小时所以这里面就是我刚才也反复讲到稳定性对于我们的整个选情非常重要那么如果我们从稳定性选择刚才说到就是构语言和Ross语言是我们最终的选择那么这里面两个生态道有我们选择哪个我们要对比一下就是那么为什么我们这里面会选择构语言呢就是在开发效率和开源生态上面我们发现Ross这方面劣势非常明显的基本研发的成本来说Ross语言的投入基本是构语言的5倍比如说你做一个feature你如果说用构语言一礼拜做完但是你用Ross可能要4到5周这个成本是相当高的当然这里面也不是说构语言就什么都好对吧我们看到两个稍微的劣势一个是它的性能这里面是稍微差一些对 相比C语言和Ross语言另外就是在高的CPU压力之下GC的长语延迟还是能观察到但是我们会发现什么大部分的公司的场景流量是非常小的应该可以看到对大部分的公司如果它的最高的峰值QPS能达到10万量级已经是非常少了能达到100万更少大家可以看一下自己的企业到底多少那么对于这样的压力其实依靠简单的增加CPU就可以把这问题解决而现在大家知道就CPU已经变得非常便宜相比我们的时间成本相比我们的人力成本已经变得非常便宜所以我的一个看法是什么在99%的场景对99%的企业基于购源的实现的这样一种机制就足够了只有1%大家知道ClubFile美国第二大的CDN厂商在基于Ross的开发它的网关来替代Angus那是因为它是CDN场景它规模过大当然CDN的整个的功能的需求相比我们在IDC里面做API的管理还是要简单很多所以这是我们整个生态的一个对比另外我也简单介绍一下BFV的项目因为BFV项目其实已经开源19年开始今年已经差不多4年时间那么我们也是2020年进入到SenseF的杀项项目那么这个平台本身是百度最早去建立了一个七层的转发的平台是从12年开始建设的那么我们是基于购源的项目是14年去把它重构然后15年年初完成权量的上限那么我们也是在19年完成了对整个百度春晚红包项目的支持大家知道大流量非常巨大所以在这当时也是承受了非常大的一个挑战然后之后也是被两个一个是央视网另外一个是开源被360协使用那么我们同时也是在照常银行使用今天上午Case的报告里就提到这个就是我们这里面也在金融的场景能得到使用对 另外我们在这里面也是在前年出版的这本书如果大家有兴趣可以看一下这个也有线上的版本就是可以去看一下这本书这本书是我们对整个附载均衡技术进行了一个比较深入的一个研究然后下面介绍一下就我们的细节到底我们怎么支持这个运源生的这个附载均衡那么首先对于一个附载均衡来说最重要的其实是它的路由那么我们会发现在传统的这个方案里的问题就是首先不区分租户把这些配置都混在一起另外就是优先级的管理尤其像NG字里面非常复杂就是你优先级如果理解得不太好你很容易配置出现问题如果大家用过会知道然后第三个 政则表达式这里面其实是一个巨大的一个坑政则表达式如果你想做一些稍微复杂的匹配你会用到政则表达式而这里面在可维护性就可读性以及说它的性能方面是有巨大隐患就是如果你写得不好一条表达式可以把性能直接掉几十倍所以对于很多的公司来说你如果用在一个多足户场景如果你不控制政则的提交可能一个足户提交的政则可以把整个平台全部搞挂所以这里面是一个很大的问题另外就是传统方案刚才前面讲到它的一些模型其实支持的字段很少比如说只支持House和Path其他的一些你说我要对Cookie我要对Header进行匹配其实你配台非常困难我们这里来说就是我们的方案是什么其考虑了性能也考虑了描述能力大家可以看右侧这是一个我们租户的一个转发表那么这个转发表是不要换两部分一部分是基础的表这个表是只支持House和Path它的性能非常高那么如果说你的不够用那么你可以在下面这个高级表去描述那么这里面我们使用了自己所发明的条件言语这样用机制比如说这是请求的House是在Cadercom或者请求的Cookie是拳队这个类似这样的言语我们有40多种而且很容易扩展所以它这里面还可以与过Path进行组合这样一种强大的描述能力是可以支持我们很多的路由的一个表达而且我们在整个这个系统它可以支持非常庞大的路由表象我们目前在生产环境已经支持超过5万条的表象这个其实在很多其他的对应的项目里它是很难支持这么大的数量的路由的然后另外一点就让我提到多机群的转发的问题那么这里面就会发现我们现在刚才讲的同城双活现在成为普遍需求一个城市内建两个数理中心我希望快速切换还有就是多K8机群刚才我提到SenseF的调码报告那么在多机群场景下为了保证你服务的可靠性我们需要把同一个服务部署在两个甚至三个或更多的K8S机群里来保证它得有足够的龙缩能力那么传统的机制刚才提到了就是GDSDS在发案那么整个生效速度如果你走外网去调度那么整个生效速度要8到10分钟才能完成90分位点流量的切换当然在内网里面有些我听到的解放是直接把超时设成0这是用非常极端的方式但是它仍然无法做到精确地在多个机群间去分配流量你可以把生效速度加快但是你不能解决你要想精确调度流量的问题所以我们的发案是什么呢我们用BFE来做多机群的分流我们在多实力转发之外我们还以一层是多机群的调度那么从原理上来说我们的配置只要下发到这里立刻可以生效不用等待时间那么长时间而且我们可以非常精确地控制就是你是按照请求力度来控制所以这里面是有很大的优势然后另外一点就是多速户刚才其实前一个报告有个同学提到了多速户的问题那么我们这里面对比就NGIS没有提供这方面的支持另外就是配置压载长期中断这是一个如果使用完这次的同学都非常普遍知道的问题还有就是其他的一些项目那么配置压载会加载所有的文件NGIS的典型一加载要加载所有的文件当你配置文件很大之后那么这个加载成本非常高然后还有刚才我提到政策的这个问题那么我们这个机制首先内置多速户模型大家看到我们是整个模型上是有多速户这一层的就是你的配置文件首先是做了切割然后第二个配置压载不会影响长连接就是因为它里面我们使用的是一个多线程的类似多线程机制在构里面是协程然后第三是我们对各个模块是使用独立配置文件的确实有很多开发者第一次见到BFG的时候说为什么这么多独立配置文件因为我要满足大规模场景我要尽量减少压加载的成本所以这里面每个配置文件每个模块的配置文件是可以独立加载的然后另外刚才提到的这个调节表是它是可以避免政则的这种问题当然我要强调我们的机制是什么就是我们是做配置隔离但是不做资源隔离也就是说对于同一个BFG实力多速户的流量是在同一个实力上进行转发的那么这里面来自的是我之前做研究的经验就是你做服务质量Quality of Service就是你对机制限制越复杂最后性能是越差的那么所以我们是通过什么呢通过多速户共享一个大的转发资源池来实现你有更强的抵离能力同时我们还有一个脱底的机制就是我们可以在四层附带均衡就是在BFG的上游我们是要放置四层附带均衡可以在这里对单个VS进行一个限速来对整个BFG的七层转发机讯进行一个保护所以是这么一个综合的机制然后另外一点就是可观测那么这个可观测现在也是非常被强调的一个能力对于我们的运营非常关键那么我们这里面其实有两个机制第一个就是我们的BFG的实力本身是向外暴露大量的状态信息我们是使用了一个独立的HDP的一个server它对外有一个端用的端口这个端口你是可以用一些监控系统Zabikus Promise有四项系统去采集那么一个实力我们暴露多少状态呢上千个这个其实跟其他同类的开项项目相比是差距很多的那么这里面会形成什么呢你通过集群的采集最后汇总可以形成一个系统运萎的一表盘对里面各种实力内部的状态进行一个监控那么第二个是对业务流量的展示那么这里面是我们是可以通过这里是可以对七层的访问认识进行一个采集 一个收集然后最后汇总计算打入到这个TSCB里面去进行一个显示所以是这两种机制然后另外一个就是我们对安全架构的一些思考那么这里面来讲刚才讲到这个SISO卸载 防火墙等等是放在外部串形的它会成为性能的瓶颈也可能成为我们问题的引换点那么这里面还有一个就是开源的方案是使用了NGIS里面内嵌Mouse Security模块那么这个问题是什么如果Mouse Security上了一个新的规则如果它出现问题那么整个转发也会中断所以我们提出的方案是将它外置 变成一个远程调用方式那么这个远程调用是带有超时的也就是如果你的WaF服务如果出现崩溃没有关系 我直接超时返回整个转发是不会中断的然后下面是两个页比较可能跟大家想法不太一样的第一个观点我想说的就是叫做Ingress是不必要的大家知道Ingress是整个KBS里没一个重要的解决方案就是如果你是在KBS内来泡的对外不能不可见的话那么是需要通过Ingress来转发的那么我们会发现Ingress原本的模型是过于简单所以它就会依赖annotation做扩展这我们拿的是一个NGIS的例子所以有大量的annotation的描述那么由于这样的描述其实很难维护所以后来社区又提出了一个新的规范叫Gatev API前面一个演讲也做了一些分享讲到Gatev API那么这个模型确实有所增强而且是要求支持CRD然后不同的实现可以写自己的一个描述那么对各个七层网关来说就需要独立实现这么一个控制器那我的思考是什么呢几点第一个就是七层的网关模型不可能统一有时候我们做Ingress控制器做Gatev API它的基本假设是什么是认为底下有不同的实现但是对上层是可以透明有时候底下换你到底是NGIS还是Envoy还是BFE无所谓对吧上面都可以无感这个假设不成立因为怎么呢大家如果去深入的研究一下就是至少这三个实现这三个方案它的转发模型差异很大差异非常大它们是不可能统一的就不可能对用户是无感的如果我们写出了Annotation就它Ingress的模型举例写出Annotation其实那个Annotation长得都不一样所以这个第一个是假设不成立然后第二个关系是什么实现Ingress控制器对业务是没有新增价值的就是我写了半天不过是另外一种新的API对于使用方没有任何新的价值对而且更为恶劣的是什么相比原生的API功能反而打折为什么会打折呢因为我们的模型没法塞进去我是把我的模型做了一些减化做了一些消减才能塞到它原的Ingress模型或者GPIPI模型里所以其实用户使用这样的方案其实对它反而是功能是有损失的所以我们现在提出的方案是什么两种方案一种方案是它像这里就是我们把原生的API完整地部署到整个KBS里面去这种是针对于你的炮的对外是不能访问的这里面我们需要打通的是使用一个控制器一个Ctrl去跟KBS的API Server去打通去做服务发现进行相应的实力变化同步这是这种方案然后第二种方案是在KBS之外独立部署这也是一种方案就是我们现在比如说像Kalico这样方案它的炮的在外部是可以访问的它直接有独立的炮的IP可以访问那么我们的七层网关集群可以部署在外部那么这个方式好处是什么就是它可以支持多集群的调度刚才我提到了多个KBS集群怎么调那么我们这个事可以提供这样的能力那么这一面好处是什么我整个这个方案好处第一不需要额外实现Ingride控制器就是说你对用前一个方案当你实现完一个网关实现的非水你要写两遍API对吧你要实现一遍原生的API你再实现一遍Ingride控制器的API实现两遍而第二个是没有性价值甚至是有阉割的然后另外一个就是整个的这个controller就这个位置非常简单因为它只是一个吃力发现所以它不需要修改不需要持续的变更而且你可以拿到我们原生的附带均衡的所有100%的能力另外一点就是整个网络和计算是完全截我掉了截我掉了对然后第二个就是今天的观点叫sidecar不是唯一的方案因为这个大家昨天我上午也参加那个ease count听了一上午对包括我对这个sidecar也是也是保持在跟进那么这一面我的直观感觉是sidecar的整个方案过于复杂那么就是说这几前的基本的一个思路假设集中是网关走到分布室那么这个分布室走得非常彻底啊这一步就是每个node甚至每个pull的上面去放一个sidecar但这一来说这个太复杂太复杂那么集中式的网关并不是一个单个网关它也是一个集群它也是一个集群它也可以横向和扣展也可以实现我们说的安全转发可观测这些能力全部都可以实现所以我现在的这个这个看法是什么的我们可以形成一种组合我们把这些大部分的能力比如说路由调度安全可以放到集中式的网关来可以保留少部分能力放到sidecar那sidecar可以比如说支持一些原来RPCS SDK的能力就是使它不要使它的升级变得更容易其实这种方案来说其实我们其实在生产中已经在使用而且非常简单并不会出现像Isio现在出现的各种复杂问题而大家会发现这个新的安病的其实它已经在走向类似的思维它会把它的这个七层的功能也开始从它的node从它的pod抽离出来放到外头但它现在做的还不够彻底它还不是一个多组互的它还是要跟对单个service去单独建立的所以我们这里面这个网关积蓄就是我刚才前面讲的那个平台流量转发平台我们可以把所有的这个复杂功能都可以放过去OK下面是这个总结就是原有的技术包括原有的基于硬件的技术以及像NG这样老一代的附载军工技术已经没法满足我们现在应用的要求了我们需要针对于袁松去建立一套新的标准或者方案就是我提到叫做面向袁松的流量管理平台它是一个整体它不是一个单个的系统不是单个技术是整个一个平台那么刚才我也抛了一个比较重的观点就是这个够弃于够和RUS的新的复杂军可能才是为了方向虽然现在应该讲从整个的使用分割来讲NGs and Wallet其实它的整个分割我估应该80%至90%但是我从语言的这个属性以及从我们对稳定性要求来说我认为这一面够和RUS有更好的一个前景另外来讲就是整个的网络方案我认为未来还是有很多可以值得研究的地方包括NGs这个方案到底未来能不能持续还是说会换成我说的那样子把我们原生的API直接去使用也就是Sidecar未来这样的方案能不能走下去所以这是今天我想抛给大家一些问题对所以今天的内容就是这么多谢谢大家非常感谢张博士的分享其实我觉得张博士提出的一些观点可以集合我们的思考虽然说跟我们的其他演讲可能有点不一样了吧可能主流观点也不一样你肯定听到我们的思考但是我想提出的一个问题就是说从刚才你那个观点就说NGs API或者Gateway API它是不必要的我觉得这个要看从我们的角度因为本身大战的角度不一样比如说你从一个一个vendor的角度我是提供这个这个数据面的这个厂商的角度我觉得这个的确是是一个负担去做这个事情但是从一个生态的角度比如说我从一个用户从个生态的角度的话我觉得这个东西还是有它的价值在的但是我们会讨论价值到底有多大我举个例子比如说我现在有一个发布的系统比如说ARGOARGO是开源的一个项目那么我要去对接一个流行管理平台我要去做回头发布或者做一些别的一些能力那么我肯定是希望我有一个标准的一个一个API去对接比如说我对接10个100个一个实现是吧这就稍微价值我觉得它的价值可能并不在于说它能够提升你的效率让你的vendor的开发更高效它的价值在于生态方面可能是我觉得这方面可能我有点不同下台的不同开发谢谢啊那个我刚才其实跟画兵在底下讨论过就是我们到底怎么理解音乐生的生态到底是完全的所有东西都集成进KBIS还是我们是认为一个广义的生态就说计算是KBIS然后我们一些网络可以在稍微稍微偶和低一点的跟它进行配合我觉得这一面是可以讨论的OK 谢谢大家还有什么问题吗那个张老师您好那个我上午也跟你简单讨论过就咱们这边就是说作为setcard还是说使用一个通用的网络管理方案这次我听完以后我个人的感觉好像是说如果是把其实我觉得有一个比较大的一个区分就是如果是用BFE的一个方案的话我个人理解可能它的一个复杂性其实相对来说更高一些可能会更需要一些专业的人去做阅美因为他把它集中起来嘛所以它的一个量会更大的时候它可能需要专业的一些额外的开发在里面然后如果是setcard的话我个人想到它可能在某种意义上呃就是说一些比较没有太多网络知识的人可以去参与一些改动我觉得在这方面就是我是简单这么想啊就是您可能对我这种想法有什么看法没有呃应该讲就是以无论是集中式的网关集群还是你是setcard的这种所谓的网格集群其实理想的方式都是由一个统一的阅美团队来管理这样它才可以独立的去跟应用脱离呃让应用感觉是透明的甚至它可以独立升级是吧嗯对但是这里面涉及到一些比如说每个团队可能对一些网网络的要求可能不太一样我的意思是如果你要实现类似的功能你到底是把它放成一个集中式的集群还是你分布的放在各个的机器或者要note上本质上没有差别就是从这件事的属性来说呃对对只是它的location就是它的位置部署位置发生改变对吧一个是我独立的可能部署在一些啊独立的虚极或者是独立的这个容器之上还是说你放到每个note或者甚至每个泡的里其实这件事本质不会有差异因为你要实现那些功能是类似的对我理解对这这块我理解的一个感觉就是说如果要一个韵围团队去管这样所有塞德卡尔的话它的难度是会非常高的但是就是说如果要是使用塞德卡尔这种场景的话我理解他就不应该有一个大团队来统一管理他如果他不统一管理塞德卡尔又是又没有了就说你你就跟应用开始绑定对但是对一而二塞德卡尔本来是设计的思想就是要跟应用进行独立结合所以确实确实在塞德卡尔如何使用上我为现在业界都有争论对吧比如说你跟应用的炮子放在一起这件事其实你自己的塞德卡尔升级变得非常困难你必须跟让应用去升级对吧对对对对对对而你当你用塞德卡尔之后你的数量它会比你集中式的集群的数量可能要提升至少一个数量级甚至两个数量级的时候你的整个运维的复杂性会变得更高是吧所以就是得分开嘛对所以我觉得因为塞德卡尔这块有值对所以因为塞德卡尔这条路其实在整个管理复杂度上是有很大的问题对这是我的观点谢谢谢谢你好我这儿有主要是想问一下BFE现在支持协议转换吗因为我们可能北向流量可能是有一些通用的但是南向流量可能会比较多不仅仅是ATTP你指的协议有哪些协议你指的有ATTP double还有一些私有协议OK这个确实现在我们是比较薄弱的就看扩展性上有没有比如说我可以有一些你可以加协议我觉得是比较容易因为购的整个实现是比较容易的那其实就是站在通用的比如说通用的一个拼胖协议的基础上的话我其实有没有一些可扩展点比如说我只是实现得扣得可引扣的相关的然后其他的包括可观测一些流日处理就基本上用框架上的东西或者说有一些pdkdk的形式包含了一个开发者我们是有一个框架的就是怎么去加一些插件但是在协议方面可能确实是实现上可能是不是像插件那么容易对 这个可以底下咱们交流一下OK还有一个就是刚才您讲到的就是把BFE步道集群外就是kbar的场景下步道集群外然后用开类口把网络打通用集群外可以访问但这个形式的话你怎么去解决自动发现的问题我们是有一个agent可以部署到集群内部然后把整个kbs实力的变化同步到我们的API对 其实这样就可以解决了了解而这个agent其实不需要怎么修改那这个agent其实是要跟API Server打交道了他要去获取集群里的对对对 去跟kbs的API Server去打通对OK OK以及跟服务治理的打通有让类似F5的MSDA或MSRA那我不知道我们的这个组件跟F5我们是有一些比如说我们的定位有一些参照或者说我们有一些场景上不同场景的推荐或者说我们跟它的一些区分有没有能不能F5 CS主要还是四层的一个转发就是七层共同相对少然后第二CS它的节点应该说是一个准备的发是吧据我了解是不能合相扩展也可以也可以做cluster也可以做clusterOK那这点是有一些类似对我们其实支持叫多机群的调度我觉得这点上可能据我了解F5 CS是不支持多机群调度就是在多个kbs进行进行进行了一个按集群力度全中的调度这这个功能我记得很因为对F5来说它一句像刚才那个您说的其实它只是有一个泡的那么从API Server去读取信息然后反推到BIP的API里面对对对这点是类似的对对对那至于它从哪个cluster里去读信息其实并没有限制因为对于整个F5的cluster来说都是它的mamba对吧对但是F5里面它的转发模型里没有说多机群的这么一种模型多机群调度的模型那我大概理解好谢谢您好谢谢张老师我咨询一个问题就是说咱们这个BFE有没有在Cell化的这个过程当中有没有一些事件就是Cell化就比方说我举一个例子比方说像我们现在就遇到一个场景就是我们可能觉得一个中心化的一个一个一个一个一个流量的一个网关觉得它可能风险比较高那现在呢我们希望又做一些Cell化的比方这个Cell然后有对专门有一个这个BFE或者我们内部有其他的一些气层网关来负责然后另外一个Cell有另外一个负责然后现在的一个问题就是什么呢就是说我们会发现可能我们还需要在这两就是就是我的流量要转到不同的Cell的时候还需要一个气层网关就这个点我们现在也是有一个有个担心点就担心这个这个又变成一个中心化的东西可能又会觉得这个点会不会又是存在一个单点的瓶颈好好谢谢啊这是关于稳定性的一个讨论就是确实我跟很多的人去聊他们会认为说像塞达克尔这样彻底的分布式才更加可靠认为我们这样这个所谓集中式的集群不可靠那我认为这个观点有点过于的极端了因为本身的这个BFE它也是一个集群它也是分布式甚至你在这个选择部署的时候你也可以选择它在不同的TOR之下是不同的机柜这也是可以去选的所以并不能证明说我们这样的分布式就一定比那种极端的分布式这个可靠性要低是吧而且我们实际在多年的这个实验中其实也不会出现这样的问题也不会出现这样的问题所以就说如果你在想得更极端一点我其实在类比下比如说你在一些数据中心里面你的服务器确实是分布式但你的网络其实是汇聚的大家知道吧就计从交换机TOR到一层汇移到二层汇那里面的交换机的中心化比我们中心化是更为严重的为什么大家没有担心那件事它崩溃掉对吧所以从整个系统来看我们绝对不是最可靠性最低的点如果要担心可能是我们网络的汇聚的点可能是更加可怕它的数量并不多所以我是从这个角度然后另外部署角度确实我们是在一些特殊的行业比如金融它确实有分区的概念它可以根据它的应用的重要度分在不同的区对然后另外一点就可靠性保证是什么呢是我们的底层实验机制我刚才反复还强调我们是使用构源的那么从我们的差不多89年的实验机来看确实我们在几千个实力运行然后跑几年情况下在线上确实没有出现过单实力崩溃的情况而之前我们确实使用过CGC源的实验机制那么确实是出现过可能小辽量在场底下出现崩溃所以这点上我们在使用构源之后我们可以做到两周的一个迭代的上线权量上线这点其实是在其他用C或CR源是很难做到的所以这里面是有一个从语言方面稳定性的理论的保证的因为它并构源的内存也就是它异常的管理它是比C或CR要强大很多的所以这里面其实我讲你的本身转发的程序就非常高可靠然后你的机器本身又是分布齿的所以这些都可以保证你的可靠性那还有问题吗