微软通过SMI与OSM定义新标准
时间：2022-04-19 10:09:01 | 来源：行业动态
时间：2022-04-19 10:09:01 来源：行业动态
为了正面对抗AWS App Mesh与Anthos Service Mesh，微软照理说肯定要在自家云平台Azure上公布相应的Service Mesh实现方案。但有趣的是，微软决定另辟蹊径，着力在不同Service Mesh之间建立起互操作标准。
面对谷歌对Istio的倾力投入，以及AWS以专有托管服务的形式发布App Mesh，微软看到了为Service Mesh技术制定行业标准的重大机遇。与其建立与Azure计算服务相集成的自有技术，微软决定与行业合作伙伴共同发布名为Service Mesh Interface的开放规范。
Service Mesh Interface (SMI)负责定义面向各类供应商的通用标准。SMI通过一组经过明确定义的标准化API，将Service Mesh实现与应用程序区分开来。任何Service Mesh实现都可以遵循SMI标准，确保开发人员能够在不涉及实现细节的前提下使用SMI API。
大体来讲，SMI带来了与其他云原生标准包括容器运行时接口（CRI）、容器存储接口（CSI）、容器网络接口（CNI）等相同的抽象层级。这些接口负责提供广泛接受且拥有明确标定的API，允许用户在不更改代码的情况下切入/切出各类实现方法。使用SMI，开发人员不再需要直面Istio或者Linkerd API，而可以通过标准API将自己的操作转换为相应的底层Service Mesh实现。
云原生生态系统对SMI表达出了应有的热情。包括HashiCorp、Buoyant、Solo.io以及Aspen Mesh在内的一系列着名供应商要么推出了SMI兼容功能，要么构建了相应的适配器。目前，SMI已经以沙箱孵化项目的形式加入CNCF。
就在谷歌宣布将Istio商标转让给OUC的几天之后，微软就发布了SMI的开源实现，名为Open Service Mesh (OSM)。OSM属于SMI的参考实现方案，属于一套基于Envoy代理的成熟Service Mesh。本就拥挤的Service Mesh生态系统如今又挤进一位基于Envoy的新成员。
在发布一个月后，LSM被提交给CNCF成为沙箱孵化项目。我们期待微软后续会如何规划OSM的发展、又会怎样将其与Azure云体系集成起来。
在线咨询
