经验总结

  1. 首页 > 生活 > >

Istio Ambient Mesh七层服务治理图文详解( 三 )

生活百科


文章插图
七层服务访问数据流
sleep访问productpage的实例中，我们为productpage创建了Gateway，因此Ambient mesh将启动waypoint，代理所有访问productpage的七层流量流量 。前面我们深入分析了ztunnel和waypoint中每一个监听器、每一个Cluster的工作原理，看起来可能会很复杂 。故在此通过上图进行一个结构性的总结，我们发现在通信的过程中，七层的治理流程明显比四层复杂：
1. 发送侧的路由、iptables：将流量拦截到ztunnel的15001端口
2. 发送侧ztunnel：将productpage请求转发到waypoint
3. Waypoint七层处理：将请求通过四个监听器依次处理，最后发送到接收端
4. 接收侧的路由、iptables：将流量拦截到ztunnel的15008端口
5. 接收ztunnel：virtual_inbound监听器及关联的cluster
Ambient Mesh七层流量治理总结和展望Istio Sidecar模式下，七层HTTP处理分别在客户端的Sidecar和服务端的Sidecar中进行 。而Ambient mesh中，七层HTTP处理仅在waypoint中进行 。理论上，七层流量的处理比较复杂，同时比较耗时，所以ambient mesh在这一层面具有一定的优势 。但是实际场景中，waypoint的部署位置是不确定的，它可能与客户端、服务端在同一节点上，也有可能与他们任何一方分布在不同的节点，甚至在不同的可用区 。所以单纯从时延的角度，很难判断Istio 经典Sidecar模式和Ambient mesh孰优孰劣 。
当前Ambient mesh负责waypoint的生命周期，但是只支持了单实例部署，并且没有提供动态扩缩容能力，而实际生产中服务请求往往有明显的峰谷特征，所以Ambient mesh没有应对突发大流量的能力 。
Ambient mesh中，每一个服务身份使用独立的waypoint代理自身的访问，这一点在安全性上与Sidecar模式类似，不用担心共享带来的安全性降低 。
整体来看，Ambient mesh七层治理架构并没有太大的优势，主要是补充Ambient mesh四层共享代理ztunnel 。未来首要解决的就是waypoint本身自动化的问题，必须能够根据服务当前的负载动态扩缩容 。
从实现角度来看，waypoint的监听器处理链过长，容易产生重复的计算和处理，并且在开发者角度，过多的xds配置不易维护 。因此简化waypoint处理也是长期性能优化的一个主要方向 。
Istio Sidecar模式基于Revision的优雅升级目前已经GA，但是Ambient mesh本身由于共享代理的原因，优雅升级功能基本被破坏殆尽 。作为微服务的基础设施，Ambient mesh如何支持Revision的优雅升级也将是未来社区关注的头等大事 。
点击关注，第一时间了解华为云新鲜技术~

经验总结扩展阅读


上一篇：2023年1月27日修建仓库黄道吉日 2023年1月27日修建仓库行吗

下一篇：2023年农历八月初一宜祭祖吗 2023年9月15日祭祖黄道吉日