江苏龙网

  1. 首页 > 资讯 > 科技 > >

Array,Array|谷歌与微软，勇士与恶龙的身份互换？

Array,Array|谷歌与微软，勇士与恶龙的身份互换？
文章图片

文章图片

近日 ， 微软宣布开源轻量级服务网格（Service Mesh）项目 Open Service Mesh （OSM） ， 并强调将在第一时间把该项目捐赠给云原生计算基金会（CNCF） 。
而就在上个月 ， 谷歌违反与 IBM 之间的协议 ， 拒绝将旗下著名的开源服务网格项目 Istio 捐给 CNCF ， 并自建新组织转移了 Istio 等项目的商标所有权 ， 遭到开源界的一致抗议 。
相较之下 ， 微软强调要捐赠 OSM 的举动确实耐人寻味 。
OSM 与 Istio 的区别
8 月 6 日 ， 微软宣布开源一个基于 Envoy 代理的轻量级服务网格项目 OSM 。据微软云服务平台 Azure 产品总监 Gabe Monroy 介绍 ， OSM 被设计为服务网格统一接口标准 SMI 的实现 ， 同时采用 Envoy 作为代理和总线 。
被问到 OSM 与 Istio 有何区别时 ， Gabe 表示 ， 最主要的区别在于 OSM 更加轻量 。“ 我们的许多客户都在尝试使用 Istio ， 但从 AKS （Azure K8s 服务）的支持队列中我们看到 ， 很多用户都在使用 Istio 的过程中遇到了困难 。”
Gabe 认为 ， Istio 本身的复杂度已经成为很多企业用户开发人员学习的负担 。“ Istio 的设计理念是试图整合整个 Envoy 生态系统 ， 这就产生了大量复杂的 API。
但大多数使用 Service Mesh 的用户其实只关注三件事：服务之间的安全通信、智能路由以及服务之间的自动监控 。Istio 的一些复杂功能在很多时候都用不上 。事实上 ， 这些不必要的复杂性还提高了容器集群出故障的概率 。”
而 OSM 虽然被称为轻量级 ， 但并不意味着它缺乏能力 。Gebe 表示 ， OSM 是经过精心设计的 ， 只保留了用户最需要的部分 API。“ 我们希望 OSM 简单易懂（相比 Istio） ， 这是有代价的 ， 这个代价就是一些高级功能的可访问性 。
我们通过为原生 Envoy API 创建一个 bail-out 机制来启用这些高级功能 ， 而不是在 API 层面做更多文章 。
服务网格统一接口标准 SMI
Gebe 提到的 SMI 是微软在去年提出的 Service Mesh Interface 的简称 。
2019 年 5 月 ， 在由 CNCF 主办的 KubeCon 2019 峰会上 ， 微软联合 CNCF 推出运行于 K8s 之上的服务网格规范 Service Mesh Interface （简称 SMI） ， 定义了一组描述能力很有限的对象 ， 用于进行服务网格的控制 ， 旨在为现有和未来不同厂商的服务网格产品提供统一的接口标准 。
SMI 的出现让轻量级的服务网格产品成为主流趋势 ， CNCF 官方项目 Linkerd 就是一款基于 SMI 实现的轻量级服务网格产品 。
SMI 对服务网格中的流量规范、访问控制、流量拆分、流量监控四大模块定义了 API 标准 ， 避免了市场碎片化 ， 也让新晋厂商拥有加入 Service Mesh 生态建设的兼容能力 。
Array,Array|谷歌与微软，勇士与恶龙的身份互换？
文章图片

文章图片

当时 ， 加入该标准的厂商包含了很多知名开源公司和 CNCF 基金会成员 ， 包括 Red Hat、VMware、微软、Canonical、Docker 等 ， 但作为 CNCF 创始成员的谷歌却并不在列 ， 令人感到惊讶 。要知道 ， 谷歌维护着当时市场份额占比最大的 Service Mesh 产品 Istio 。
似乎从这时候起 ， 谷歌就打算不和大家一起玩了 。
屠龙勇士终成恶龙？
从云计算技术基础“三大论文”、浏览器内核 Chromium 、Andorid 系统 ， 再到如今一统云原生基础设施建设的 Kubernetes， 一直以来 ， 谷歌都是开源领域的佼佼者 ， 推出了一个又一个足以改变世界的重量级开源项目 。
但近年来 ， 谷歌面对开源社区的态度似乎正在产生微妙的变化 。


推荐阅读


上一篇：|iPhone 12 有哪些值得期待的地方？

下一篇：Array|这一行动实施，苹果将会受重创，库克直接损失60亿！