Open Service Mesh(OSM)
是一个轻量级的、可扩展的、云原生的服务网格,它允许用户对高度动态的微服务环境进行统一管理、安全保护,并获得开箱即用的可观察性功能。
微软今天宣布推出一个新的基于 Envoy
代理的 Open Service Mesh
。Open Service Mesh
意在成为 Service Mesh Interface(SMI)
规范的参考实现,这是 Kubernetes
上 Service Mesh
的标准接口,得到了这个生态系统中大多数玩家的支持。
微软公司计划将 Open Service Mesh
捐赠给云原生计算基金会(CNCF
),以确保它由社区主导,并具有开放的治理。
微软 Azure Compute 合作伙伴管理总监(同时也是 CNCF 董事会成员)Gabe Monroy 说:
“SMI 真的引起了人们的共鸣,因此我们真的认为在生态系统中存在着 SMI 的参考实现空间,其中 Mesh 技术首先是实现 SMI API,并为客户提供最佳的 SMI 体验,”
他还补充说,因为 SMI
提供了最低共同点的 API
设计,所以 Open Service Mesh
让用户在需要一些更高级的功能时,可以 “保送” 到原始的 Envoy
。Monroy 指出,这种 “没有断层” 的设计,是 Open Service Mesh
背后的核心理念。
至于它的功能集,SMI
处理了所有你期望的标准服务 Mesh
功能,包括使用 mTLS
确保服务之间的通信安全,管理访问控制策略,服务监控等。
不过目前市场上还有很多其他的服务网格技术。那么微软为什么要推出这个呢?
“我们的客户一直告诉我们的是,今天的解决方案,Istio
就是一个很好的例子,非常复杂。” 他说。“这不仅仅是我说的。我们在 AKS
支持队列中看到了客户的数据,他们正在尝试使用这些东西 —— 他们就在这里挣扎。这就是难以使用的技术,难以大规模构建的技术。所以外面的解决方案都有一些不尽如人意的地方,我们真的觉得一些重量较轻、更注重 SMI
的东西,才是当前涉足这项技术的客户的最佳选择。”
Monroy 还指出,Open Service Mesh
可以与 Linkerd
等其他解决方案并驾齐驱。
很多专家预计谷歌也会将其 Istio
服务网格捐赠给 CNCF
。但是这并没有实现。“这很有趣。很多人都非常关注治理方面的问题。” 他说。“我认为,当人们过度关注这一点时,你就会忽视客户是如何使用这项技术的。而事实是,客户今天使用 Istio
的日子并不好过。我想即使是那些深陷该社区的人也会承认这一点,这也是我们目前没有兴趣为该生态系统做出贡献的真正原因。”
英文原文地址:https://techcrunch.com/2020/08/05/microsoft-launches-open-service-mesh/
本文转载自:「ServiceMesher」,原文:https://mp.weixin.qq.com/s/-v-wo3Wl_qfnw3KfpdAzKA,版权归原作者所有。欢迎投稿,投稿邮箱: editor@hi-linux.com。