共计 4442 个字符，预计需要花费 12 分钟才能阅读完成。
只管微服务环境提供可移植性，容许更快更频繁的部署周期，甚至还能让组织创立关注于特定畛域的团队，但这也随同着对于流量治理、平安以及可观测性等需要的增长。在整个生态系统中，针对这些需要的服务网格模式的实现办法成千上万。微软始终沉闷在 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 进行原型设计，为适宜生产的机会做好筹备。这不会须要期待很久。
