尽管微服务环境提供可移植性，允许更快更频繁的部署周期，甚至还能让组织创建关注于特定领域的团队，但这也伴随着对于流量管理、安全以及可观测性等需求的增长。在整个生态系统中，针对这些需求的服务网格模式的实现方法不计其数。微软一直活跃在 Service Mesh Interface (https://smi-spec.io/) (SMI) 社区中，协助定义一组标准可移植的 API 规范，能够实现横跨在不同服务网格之上的通用服务网格功能。供应商可以应用 SMI 来确保生态系统工具能够在不同的网格上工作，同时也允许客户选择网格提供方。
今天我们很高兴推出一个新的开源项目--Open Service Mesh (https://openservicemesh.io/) (OSM) ,一个运行于 Kubernetes 上的轻量的、可扩展的服务网格。OSM 能够让使用者在高度动态化的微服务环境中对服务到服务间的通信做到一致地管理、保护和观测。我们希望 OSM 能成为一个社区主导的项目，这将促进 SMI 在新的和现有的 API 上的协作。我们打算让 OSM 成为开放治理，这样能够轻松的与社区进行协作。因此我们已经提交了一份提议，来启动将 OSM 捐赠给云原生计算基金会(https://cncf.io/) (CNCF) 的进程。
我们要让 Kubernetes运维人员们能够毫不费力的安装、维护和运行 OSM；与此同时，也要让 OSM 足够简单，让整个社区都能够理解并做出贡献。
这些目标根植于客户需求之中，也将我们引向三个基本的设计准则。首先，OSM 提供一个与SMI规范兼容的控制平面，以此来保留用户的选择。其次，我们使用 Envoy 作为数据平面，因为 Envoy 具有很强的社区动力。最后，OSM 背后最重要的理念是“非陡峭（no cliffs）”设计，能够让 OSM 足够灵活，在简单或复杂的场景下都可以直接使用 SMI 和编写 Envoy xDS API 来处理。
“很高兴 OSM 能够加入 Envoy 家族，为 Kubernetes 构建一个供应商中立的服务网格方案，并强调简便性”。--Envoy创始人Matt Klein
OSM 简化了许多任务，诸如为通用部署方案的配置流量转移，使用 mLTS 来保护服务到服务间通信的安全，为服务实施细粒度的访问控制策略，观察用于调试和监视服务的指标，集成本地或外部证书管理解决方案，以及使用自动的 sidecar 注入将应用载入到网格中。
很高兴能与社区一起改进、开发 、学习 OSM，并与广大 SMI 社区一同发布 SMI 规范的进展。我们将在 KubeCon EU Virtual 2020 ( https://events.linuxfoundation ... urope/) ，以及8月14日举办的 CNCF Webinar(https://www.cncf.io/webinars/c ... ystem/) 上展示 OSM。
1 了解微软 Open Service Mesh
微软已经发布了它的开源服务网格实现。这对 Azure 上的 Kubernetes 来说意味着什么？
仅仅在几年前，当我们提到基础架构时，我们指的是物理上的基础设施：服务器、内存、磁盘、网络交换机以及所有连接它们所必须的线缆。我曾经有一些电子表格，当我构建一个可以支持成千上万用户的 Web 应用时，我需要向表格中键入某个数字，先得到我所需要的硬件规范，然后才去实施。
现在一切都改变了。首先到来的是虚拟基础设施，它们位于那些物理机架的服务器上。通过一组虚拟机管理程序和软件定义的网络与存储，可以指定应用程序的计算要求，并在别人为我管理的物理硬件上配置应用程序及其虚拟网络。今天，在超大规模的公有云上，我们将在自动管理扩展(包括纵向和横向)的编排框架上构建分布式应用。
2使用分布式网格来管理分布式应用架构
新的应用基础设施需要属于它们自己的基础设施层，它必须足够智能，能够响应自动扩展、处理负载均衡和服务发现，并仍能支持策略驱动的安全性。在微服务容器之外，你的应用基础设施被实现为一个服务网格，每一个容器都被链接到作为 sidecar 运行的代理上。这些代理管理容器之间的通信，允许开发团队专注于他们的服务和托管的 API，而所有连接这些服务的服务网格由应用操作团队管理。
一个人在应用服务网格时，或许面临的最大问题是选择困难症：谷歌的出名的 Istio、开源的 Linkerd、HashiCorp 的 Consul，抑或是更多的实验性工具如 F5 的 Aspen Mesh。选择一个已经很难，而更难的是在整个组织中标准化一个实现。
当下，如果你想通过 Azure Kubernetes Service 来使用服务网格(https://docs.microsoft.com/en- ... -about)，你得到的建议是使用 Istio、Linkerd 或是 Consul，在 AKS 文档中都有它们的相关说明。这并不是最简单的方法，因为你需要一个独立的虚拟机来管理服务网格，同时还需要一个运行在 AKS 上的 Kubernetes 集群。然而，另一个还在开发中的方法是 Service Mesh Interface (https://smi-spec.io/) (SMI), 它提供一组连接 Kubernetes 到服务网格的标准接口。Azure 已经支持 SMI 有一段时间了，因为其 Kubernetes 团队一直领导着 SMI 的开发。
3 SMI: 一组通用服务网格 API
和 Kuebernetes 一样, SMI 也是一个 CNCF 项目，尽管当前只是一个sandbox项目。处于沙箱意味着它尚未被视为稳定，随着 CNCF 开发计划的各个阶段，它的前景将发生重大变化。当然，云厂商和 Kubernetes 供应商以及赞助其开发的其他服务网格项目也提供了大量支持。SMI 旨在为 Kubernetes 提供一组基本 API，以便连接到符合 SMI 的服务网格。因此你的脚本和运维人员可以使用任何的服务网格；没有必要被锁定在单个提供方。
作为一组自定义的资源定义和扩展 API 服务器，SMI 可安装在任何经过认证的 Kubernetes 发行版上，如 AKS。一旦应用到位，你可以使用熟悉的工具和技术来定义应用程序和服务网格之间的连接。SMI 会使应用程序具有可移植性；你可以使用 SMI 在本地的 Kubernetes 实例上开发，并可以将任何应用程序转移到一个托管有符合 SMI 规范的服务网格的 Kubernetes 上，且无需担心兼容性。
有一点很重要，SMI 本身并不是一个服务网格；它是一个规范，服务网格需要实现它来获得一组通用的功能特性。没有什么能阻止服务网格添加属于自己的扩展和接口，但是它们需要足够引人注目才会被应用程序和应用运维团队使用。SMI 背后的开发者们也声称他们并不反感将新的功能迁移到 SMI 规范中，因为服务网格的定义在不断发展，那些预期功能也在不断改变。
4 Open Service Mesh：微软开发的 SMI 实现
微软最近发布了它的第一个 Kubernetes 服务网格 (https://openservicemesh.io/)，它基于微软在 SMI 社区的成果之上。Open Service Mesh 是一个符合 SMI 规范的、轻量的服务网格，它是一个托管于 Github (https://github.com/openservicemesh/osm) 的开源项目。微软希望 OSM 成为一个社区主导的项目，并打算尽早将其捐赠给 CNCF。你可以视 OSM 为一个基于现有服务网格组件和概念的 SMI 参考实现。
尽管微软并没有明确表态，但在 OSM 的声明和文档中，有一条它在Azure上使用服务网格的经验，它们重点关注的是与运维相关的东西 (https://github.com/openservice ... IGN.md)。在最初的博客 (https://openservicemesh.io/blo ... -mesh/)中， Michelle Noorali 描述 OSM 为 “让Kubernetes 运营人员毫不费力的安装、维护和运行”。那是一个明智的决定。OSM 是供应商中立的，但是它很有可能成为 AKS 的众多服务网格选项之一，因此易于安装和管理将是推动人们接受它的一个重要因素。
OSM 基于其他服务网格项目的成果之上。尽管它拥有自己的控制平面，但是它的数据平面基于 Envoy。同样，这是一个务实且明智的办法。SMI 是关于如何控制和管理服务网格实例的，因此使用大家熟悉的 Envoy 来处理策略将允许 OSM 在现有的功能上构建，这减少了学习曲线，同时也让应用程序运营人员能跨过有限的 SMI 功能集，在必要的情况下使用更复杂的 Envoy 的特性。
目前 OSM 实现了一组通用服务网格特性。这些包括支持流量转移、保护服务到服务的连接、应用访问控制策略和处理服务的可观测性。通过自动部署 Envoy sidecar 代理，OSM 会自动添加新的应用和服务到网格中。
5 部署和使用 OSM
想要开始尝试 OSM alpha 版本 (https://github.com/openservice ... ide.md)，可以在项目的 Github Release (https://github.com/openservicemesh/osm/releases) 页面上下载它的命令行工具 osm。当运行osm install时，它会以默认的命名空间和网格名称把 OSM 控制平面添加到 Kubernetes 集群中。你可以在安装过程中进行修改。安装并运行 OSM 后，可以向网格中添加服务 (https://github.com/openservice ... ces.md)，使用策略定义来添加 Kubernetes 命名空间，以及自动将 sidecar 代理添加到托管的命名空间下的所有pod中。
这些步骤将实现你选择的策略，因此在开始部署前就设计好一组 SMI 策略将会是一个不错的主意。OSM Github repo 上的策略样例将会给你帮助。OSM 中包含了 Prometheus 监控工具包和 Grafana 可视化工具 (https://github.com/openservice ... ity.md)，因此你可以快速查看服务网格和 Kubernetes 应用的运行情况。
Kubernetes 在现代云原生应用中是一个重要的基础设施元素，因此我们要开始重视它。这要求你将它同运行在它之上的应用独立开来进行管理。AKS、OSM、Git 和 Azure Arc 的组合成为管理 Kubernetes 应用环境的基础配置。应用基础架构团队管理 AKS 和 OSM，为应用和服务设置策略，与此同时， Git 和 Arc 将通过 OSM 的可视化工具传递的实时应用指标来控制应用的开发和部署。
这些元素完全融合还需要一段时间，但很明确微软正在为分布式应用管理及其必要的工具做出重要的承诺。现在就动手吧，使用这个套件的基础元素 AKS，并添加上 OSM 和 Arc。你现在就可以在 Azure 上构建和部署 Kubernetes，使用 Envoy 作为服务网格，同时在实验室中使用 OSM 和 Arc 进行原型设计，为适合生产的时机做好准备。这不会需要等待很久。