关键字: [ 亚马逊云科技中国峰会2024, Istio, 服务网格发展趋势, 无代理模式, 无边车模式, 中心化代理模式, 网关Api 集成]
本文字数: 3600, 阅读完需: 18 分钟
导读
在亚马逊云科技中国峰会2024 上, 马若飞分享了” 云原生服务网格漫谈’ 落地与未来’“ 。他介绍了服务网格技术的发展趋势, 包括无代理(proxyless) 模式、无边车(sidecarless) 模式、Istio 的Ambient Mesh 模式以及Kubernetes 的Gateway API 等新形态。这些新形态旨在通过服务代理能力的转移和分层, 简化和消除传统sidecar 模式的缺点, 如侵入性、资源占用、生命周期绑定和请求中断等。马若飞还对比了Amazon App Mesh 和开源Istio 等主流服务网格产品, 并分享了公司的混合云服务网格架构实践。
演讲精华
以下是小编为您整理的本次演讲的精华，共3300 字，阅读时间大约是16 分钟。
在2024 年亚马逊云科技中国峰会上, 马若飞先生作为一位技术分享者和亚马逊云科技的Content Hero, 就云原生服务网格的发展趋势和落地实践进行了精彩分享。
服务网格发展趋势
1. 服务网格成熟度
根据CNCF 的年度报告, 马若飞先生引用了一句话:“ 随着Kubernetes 成熟, 许多组织已经转向了服务网格技术。” 这明确地代表了当前我们使用服务网格的方式, 已经不再是像2018 年、2020 年那个时候去尝试去探索, 而是服务网格技术已经成熟, 我们现在就是去落地、去使用它, 去利用它的服务治理能力来优化微服务应用。
2. 服务网格发展曲线
马若飞先生表示, 服务网格起源于2016 年底至2017 年, 到2018 年左右获得大量追捧, 之后由于落地实践发现不成熟之处而进入低谷期, 直到近两年才开始逐渐成熟。他补充说:“ 同时我们来我加了几个时间点, 大家可以看一下, 这个其实就是我们这个Service Mesh 这个技术, 它的一个发展趋势基本上是类似的。Service Mesh 其实是从16 年底到17 年, 我们认为它是一个初创的原点, 然后逐渐到了18 年左右得到了大家的大量的追捧, 然后结果通过一些落地实践发现并不是那么回事, 还是有很多不成熟的地方, 所以逐渐进入低谷, 直到这两年才开始逐渐的成熟。”
马若飞先生解释了达克效应曲线, 指出人类认知和技术发展方向基本相似, 都经历了从一无所知到自负, 再到自知无知, 最终达到真正知识积累的过程。他说:“ 达克效应曲线其实跟这个图的趋势几乎一模一样, 它是指的是我们的人的认知, 它的发展的方式也是这样一个趋势。一开始什么都不知道, 对吧? 你是一个婴儿, 什么都不知道,No Nothing 。然后我就拿技术人来举例, 到了一定阶段之后, 我们学了一些技术, 学会了一些编程语言, 我们觉得我们什么都知道了, 对吧? 就达到了顶峰, 一副这个无所不知的状态, 其实这个顶峰叫不知道自己不知道, 实际上是这个阶段, 然后当你发现周围有更多的大牛, 然后并且随着自己的技术的深入的探索, 发现自己其实一无是处, 对吧? 就到了一个所谓的悲伤谷底, 这个时候叫知道自己不知道, 然后再逐渐地不断地去学习, 不断地去提升自己, 逐渐进入了这个阶段, 就是知道自己知道了, 这就是达克效应曲线, 其实跟技术, 所以我们人的认知跟技术发展没有什么太大区别, 对吧?”
3. 服务网格新趋势
马若飞先生总结了服务网格新趋势的方向:“ 通过对服务代理能力的转移和分层, 从而简化和消除主流方案带来的缺点。”
(1) Proxyless( 无代理模式) 马若飞先生解释说:“ 这个原因也很简单的, 你可以把这个模式认为是一种, 就是我简单的一句话就是把它认为是一种基于SDK 层面实现一个服务治理的能力。为什么这么说? 我们来看看gRPC 本身就是一个网络通讯的一个类库对吧? 那既然我已经我的client 所有端在交互的过程中就需要通过gRPC 这个SDK 去进行编解码, 去进行网络数据传输, 那我干嘛不把路由这些流控能力也做到这个SDK 里对吧? 所以那么这个所谓的无代理模式就是向左边这个图转换到右边这样方式。从一开始它需要通过sidecar 方式去进行流控, 但现在我只要是你使用我gRPC 这个SDK, 它就直接可以进行一些简单的流量控制, 这就是proxyless 无代理模式。”
(2) Sidecarless( 无边车模式) 马若飞先生说明道:“Cilium 是这个原生领域一个网络相关的一个框架, 那么他呢在去年提出了他们自己的一个Cilium 的mesh 一个形态, 主要依赖的就是eBPF, 这个我就不细讲, 你可以把eBPF 技术理解为就是在内核态给你开了一个口子, 开了一个可扩展的一个hook 的一个能力, 使得我们在网络通讯的这个过程中, 这些事件通讯事件发生的过程中, 我们就可以通过我们实现的这个hook, 从而将原有的sidecar 里边的这些流量控制的这些能力, 这些路由的能力, 这些指标收集能力全都转移到内核层面去, 这就eBPF 技术。因此它通过eBPF 就可以消除我们原来的sidecar, 所以叫sidecarless, 也可以叫sidecar free 。也就说当我们想使用的时候, 那我们就可以再加一个sidecar, 用来去实现7 层相关的一些 的能力。不想使用的话, 那我们就直接基于4 层的eBPF 去实现流控就可以了, 这叫sidecarless 。”
(3) Istio Ambient Mesh 马若飞先生解释了Istio 的Ambient Mesh 部署模型:“ 这个形态其实跟其实本质上也是一个sidecarless, 也是消除sidecar 一个方式。但是我个人更倾向于把它是称作是中心化代理模式, 或者叫共享代理模式。他的思路主要是将我们的这个流控的能力, 流量控制能力分成两层。 如果你只是想实现四层的流控能力或者是安全相关的能力, 那你只需要在你的集群中去部署这个它所谓的安全覆盖层就行了。如果你需要使用这个gRPC HTTP 这样的基层能力, 那你再去部署一个共享型的一个代理, 也就是这张图上的中间这个ingress proxy 。”
他进一步说明了部署结构:“ 我们可以从这个它这个部署结构可以看到, 它通过两个分层把原来的sidecar 这个能力下沉到一个叫Istio-agent, 由他去负责四层的这个流控, 然后再通过一个中心化的一个代理来实现七层流控, 这就是他提出的所谓的ambient mesh, 就ambient mesh 叫周围网格这样的形态。这是Istio 的一个形态, 最近两年的Istio 一直在持续的对这个形态进行一个持续的完善和开发, 我相信未来Istio 也是主推的一个部署形态, 也是这个ambient mesh 。”
(4) Gateway API 马若飞先生谈到,Kubernetes 1.18 引入的Gateway API, 虽然本意是代替Ingress 管理南北向流量, 但实际上也能管理东西向流量。他解释道:“ 他号称是面向角色的设计, 这个其实如果你熟悉Kubernetes 的这个存储, 它的存储, 你就会发现它跟存储的设计一模一样, 也有一个StorageClass, 也有个PV PVC 这样东西, 它也是指的是不同的这个运营人员, 开发人员, 他去进行不同的配置。现在Istio 还有一些主流的一些产品都已经支持了GatewayAPI, 也就是说你部署完Istio, 然后你的版本又已经在1.18 以上, 你直接可以使用它的这个API 这些CRD 去配置Istio 的流控能力, 不用再去写Istio 的那些CRD 。”
4. 新形态对比
马若飞先生对比了这些新形态在代理位置、分层等方面的异同。他总结道:“ 首先他们的代理的位置: 传统方案就是在container, 就是在我服务旁边;Proxyless 就是我把这个能力下沉到了SDK 里边了;Sidecarless 就是我把这个能力更下沉放到内核层面了;Ambient mesh 它是用一个共享型的中心化的代理去实现的, 所以本质上来说它的能力都在那, 只不过它的位置不同了。然后他基本上这两个基本上没分层, 基本上他都会基于你的需求做一个分层, 以便你能够部署的时候更加的灵活。”
服务网格技术选型
1. CNCF 技术蓝图
马若飞先生展示了CNCF 的技术蓝图Landscape, 并对其进行了解释:“ 这个图我不知道大家会不会识别, 花花绿绿的, 其实很好认, 它分三大部分: 所有框的蓝色框的是CNCF 基金会自己运营的, 自己孵化的产品; 深蓝的就是毕业的; 浅蓝的就是孵化中; 所有的白色的是开源产品; 所有的灰色这边不太明显, 灰色就是闭源或者托管产品, 比如说Amazon App Mesh 。”
他指出, 这张图中包含了许多中国产品, 说明中国的基础设施对服务网格有着浓厚的兴趣。马若飞先生补充道:“ 这里边我们可以发现有很多的中国的一些产品, 我们中国的基础设施对Service Mesh 还是非常的热情的, 比如说Mosn 来自于蚂蚁金服的, 比如说这个EES Mesh, 比如说这个Slim 来自网易的等等。 那么列出这个就是让大家在如果你想落地Service Mesh, 可以基于它做一个技术选型。”
2. Istio vs Amazon App Mesh
马若飞先生对比了开源Istio 和亚马逊云科技的托管服务App Mesh, 为服务网格技术选型提供了参考。
两者均基于Envoy 代理, 能提供类似的服务治理能力。马若飞先生解释道:“ 其实这两个都一样, 都是使用的这个Envoy, 也就是说本质上他们能够提供相同的服务的, 服务治理的能力取, 至于这个能力的多少取决于我们分装的, 或者说把这个能力暴露了多少, 那目前来看,Istio 他暴露的更多。”
Istio 通过CRD 等方式暴露了更多配置能力。马若飞先生说:“ 他后面他一开始做了一些CRD, 做一些把这些接口都封装给他暴露出来, 后来他用了一个比较偷懒的办法, 他直接暴露了一个CRD, 叫EnvoyFilter, 也就说你直接把Envoy 原来的这些能力把这个配置直接配到里边就行了, 这样他就一劳永逸了。”
App Mesh 支持更多工作负载, 但近年来更新较少。马若飞先生指出:“App Mesh 其实相对来说能暴露的能力稍微少一些, 而且近几年App Mesh 好像没有太多的更新了, 因为我去看了他们的Roadmap, 更新不多了, 不知道是不是因为哎卖是免费的原因, 因为免费他不赚钱对吧, 所以更新的动力也不大。”
在入口网关方面,Istio 使用Envoy, 而App Mesh 使用亚马逊自有的负载均衡产品。马若飞先生说:“Ingress 就入口网关这边,Istio 是用的Envoy, 这边是用的亚马逊自己的这个非常丰富的LB 的一系列产品。”
工作负载支持方面,Istio 最初专注于Kubernetes 环境, 后来扩展到支持虚拟机等混合工作负载。马若飞先生解释道:“ 工作负载这边,Istio 最早的时候一搜, 最早的时候他其实是他想的是比较远的, 他其实就是想覆盖在Kubernetes 这个生态下面, 但后来他发现其实在那个阶段, 在18 年19 年那个阶段, 绝大部分的应用厂商, 它实际上是一个混合的, 混合架构的一个形态。混合云的形态就有一个部分我已经上云了, 有一部分其实我还是宿主机, 还是这个虚拟机, 所以后来在1.4 1.6 版本开始提供了VM 的这样的方式。” 而亚马逊App Mesh 一开始就支持几乎所有工作负载, 马若飞先生认为这是一个非常好的设计:“ 亚马逊这边其实一开始就支持几乎所有的工作负载, 这跟他们的产品策略有关, 因为它毕竟是基于自己的这个闭环的生态的, 我觉得这个是非常好的, 他一开始他就知道, 或者说他这个设计者他一开始就知道, 所谓的这个Mesh 这个范畴一定不仅仅局限于Kubernetes 集群内部, 一定是一个非常大的一个包括EC2 等的这样范畴, 所以这个设计也是非常好的一个设计。”
马若飞先生总结了两者的优缺点:
Istio 的优点是功能丰富、可跨平台部署, 缺点是学习成本高。他解释说:“ 优点依次的, 目前就主要是功能比较大, 然后你可以因为毕竟开源产品可以自己去部署到各个平台上去, 然后缺点的意思, 我现在其实即便他做了几轮的简化, 但是他的学习成本还是很高, 或者我们这样说, 就你把它装起来容易, 你想把它用好不太容易。”
App Mesh 的优点是在亚马逊云科技生态内使用便捷, 缺点是平台绑定。马若飞先生说:“Amazon App Mesh 就是一个闭环产品, 你只能在亚马逊云科技自己的这个生态中去使用。缺点, 主要就是平台绑定好。”
公司服务网格架构实践
最后, 马若飞先生简要介绍了其公司的混合云服务网格架构实践案例。他说:“ 最后简单给大家看一个我们公司的目前的一个服务网格的架构, 我们主要是我们是一个混合的, 就是我们是所有的产品基本上都是在ECS 上的, 然后我们的微服务架构, 我们微服应用是基于这个EKS 去部署的, 都在集群内部, 同时我们但是我们使用的是开源的Istio 产品。”
马若飞先生进一步解释了他们的入口网关架构:“ 然后入口网关是这个都是自动的, 就是上面最上面外层不是有两层网关的, 最最上面外层是亚马逊云科技的API Gateway, 然后鉴权之后往下走, 走到应用内部的时候, 到了集群边界的时候就应用了Istio, 都是Ingress 进来的, 大概就是这样。”
他还补充说, 由于现在落地的形态都差不多, 就不再详细说明了:“ 这个因为现在落地的形态都差不多, 我就不细说了。”
马若飞先生没有在视频字幕中提及任何具体的客户案例或亚马逊云科技产品、服务的使用案例, 因此我无法根据视频字幕对此进行补充和丰富。但他分享了公司自身的服务网格架构实践, 包括使用ECS 、EKS 、开源Istio 以及Amazon API Gateway 等亚马逊云科技服务, 为混合云环境构建了完整的解决方案。
总结
马若飞先生的分享全面介绍了服务网格技术的发展历程、新趋势、技术选型要点, 并分享了公司的实践案例, 为服务网格的落地和未来指明了方向。他在最后总结说:“ 好, 那么我今天的分享就到这里, 谢谢大家。”
马若飞先生的分享内容非常丰富, 涵盖了服务网格领域的方方面面。他从服务网格的成熟度、发展曲线出发, 解释了这一技术的演进过程。接着重点介绍了服务网格的新趋势, 包括无代理(Proxyless) 、无边车(Sidecarless) 、Istio Ambient Mesh 、Kubernetes Gateway API 等新兴部署模式, 并对它们在代理位置、分层等方面进行了对比分析。
为了帮助技术选型, 马若飞先生展示了CNCF 技术蓝图Landscape, 指出了其中包含的主流开源和商业产品, 特别是来自中国厂商的产品。他还对开源Istio 和Amazon App Mesh 这两种主流方案进行了全面对比, 从服务治理能力、配置暴露、工作负载支持、优缺点等多个维度进行了解析。
最后, 马若飞先生分享了其公司的混合云服务网格架构实践, 介绍了他们如何结合ECS 、EKS 、开源Istio 以及Amazon API Gateway 等服务构建整体解决方案, 但未提及任何具体的客户案例。
总的来说, 马若飞先生的分享内容非常丰富详实, 将服务网格的发展历程、新趋势、技术选型、实践案例等多个维度娓娓道来, 为在场听众提供了一次系统的服务网格技术盛宴。无论是对于了解服务网格现状, 还是寻求落地实践的指引, 这次分享都具有很高的参考价值。
下面是一些演讲现场的精彩瞬间：
亚马逊云科技中国峰会2024 的主讲人感谢与会者的热情参与, 称赞他们对技术的真挚热爱。
达克效应曲线揭示了人类认知和技术发展的相似趋势, 从无知到自负, 再到谦逊和不断学习提升。
亚马逊云科技中国峰会2024 上, 演讲者列举了服务网格技术的四大缺点: 侵入性、资源占用、生命周期绑定以及请求中断。
亚马逊云科技中国峰会2024 上, 演讲者介绍了无边车(sidecarless) 模式, 利用eBPF 技术在内核层面实现流量控制和路由能力, 消除了传统sidecar 的需求。
在Kubernetes 1.18 中引入的Gateway API 不仅能够管理南北向流量, 还能实现服务网格的东西向流量管理能力。
亚马逊云科技在设计 Mesh 时就考虑到了不仅仅局限于 Kubernetes 集群内部, 而是包括 EC2 等更广泛的范畴, 这是一个非常好的设计理念。
亚马逊云科技中国峰会2024 上, 演讲者展示了公司的服务网格架构, 包括混合部署在ECS 和EKS 上的微服务, 以及使用开源Istio 和Amazon API Gateway 作为网关的设计。
总结
云原生服务网格技术已经走过了从探索到成熟落地的发展历程。服务网格的新趋势是通过代理能力的转移和分层, 简化并消除主流方案的缺点。新形态包括无代理(Proxyless) 模式、无边车(Sidecarless) 模式、Istio Ambient Mesh 中心化代理模式, 以及Kubernetes Gateway API 等。这些新形态通过将代理能力下沉到SDK 、内核或中心化代理, 实现了去中心化、资源节省、生命周期解耦和减少请求中断等优势。
主流开源方案如Istio 和Amazon App Mesh 虽有异同, 但均基于Envoy 代理, 提供了丰富的服务治理能力。未来, 服务网格将继续在云原生领域扮演重要角色, 为微服务应用提供流量控制、安全性和可观测性等关键能力。选择合适的服务网格产品并正确落地, 将有助于优化应用架构和提高运维效率。
服务网格技术的发展需要与人的认知相辅相成。我们应当保持开放包容的心态, 持续学习创新, 方能跟上技术发展的步伐, 在云原生的浪潮中稳操胜券。
2024 年 5 月 29 日，亚马逊云科技中国峰会在上海召开。峰会期间，亚马逊全球副总裁、亚马逊云科技大中华区总裁储瑞松全面阐述了亚马逊云科技如何利用在算力、模型、以及应用层面丰富的产品和服务，成为企业构建和应用生成式 AI 的首选。此外，活动还详细介绍了亚马逊云科技秉承客户至尚的原则，通过与本地合作伙伴一起支持行业客户数字化转型和创新，提供安全、稳定、可信赖的服务，以及持续深耕本地、链接全球，助力客户在中国和全球化发展的道路上取得成功。