本文要点

Azure Service Fabric Mesh（目前处于预览阶段）是一个完全托管的服务，它使你可以使用“无服务器”方法构建、部署和管理由运行在容器中的多语言服务组成的应用程序。
Azure Service Fabric Mesh通过使用Envoy Proxy构建的软件定义网络（SDN）功能提供了智能消息路由，使得服务发现和微服务之间的路由成为可能。
Azure Service Fabric有三项公共服务：Service Fabric Azure集群服务、Service Fabric独立服务和Azure Service Fabric Mesh服务。
Service Fabric Mesh主要是一个应用程序平台，它首先从终端工程师那里抽象出了业务流程，然后添加了可以供你在应用程序中使用的智能消息传递路由和存储。
Service Fabric 平台有一个内置的、高可用的、低延迟的内存内持久化状态存储。你可以通过编程式数据结构（Dictionary和Queues）使用这个存储，或作为附加的卷磁盘使用。

今年早些时候，Azure发布了Service Fabric Mesh的预览版，这个平台面向的是那些不希望承担运行底层编排平台操作责任的微服务开发人员。Chacko Daniel是微软的首席技术经理，同时也是Service Fabric Azure集群服务和Azure Service Fabric Mesh服务的所有者。最近，InfoQ对他进行了采访，探讨了这项服务与现有的平台即服务（PaaS）和容器基础设施即服务（CIaaS）解决方案（如Cloud Foundry何Kubernetes）的关系。

InfoQ：欢迎来到InfoQ！您能向我们的读者简单地介绍下自己吗？

Chacko：我叫Chacko Daniel，是微软Azure超大规模计算团队的首席项目经理。我已在Azure Service Fabric团队工作了10年。我是平台运行时和Service Fabric Clusters与Service Fabric Mesh两项Azure服务的服务所有者。

InfoQ：您能否为不太熟悉云技术的读者解释一下Azure Service Fabric是什么？

Chacko：AzureAzure Service Fabric是一个分布式计算平台，它使构建、部署和操作始终处于开启状态的任务关键型微服务应用程序（容器化和非容器化）变得更容易。开发人员可以专注于构建微服务，而Service Fabric平台解决了诸如应用程序的生命周期管理、编排、可用性和可伸缩性等难题。
该平台还具有内置的、高可用的、低延迟的持久化内存内状态存储。开发人员可以通过编程式数据结构（Dictionary和Queues）使用这个存储，或作为附加的卷磁盘使用。
Azure Service Fabric是开源的，可以在Windows和Linux上运行，你既可以在本地使用它，也可以在云中使用它——这是一个很棒的混合解决方案，可以支持要求很高的“原生云”应用程序。
Azure Service Fabric有三项公共服务：Service Fabric Azure集群服务、Service Fabric独立服务和Azure Service Fabric Mesh服务。

Service Fabric不仅可以供大规模的微软服务使用，如Azure SQL DB、Intune、Azure Cosmos DB、Azure Event Hubs和Bing，也可以供成千上万的企业客户使用，如Citrix Systems、Alaska Airlines、Honeywell、BMW和Societe Generale以及SI（系统集成商）&ISV（独立软件供应商，如Accenture和OSISoft）。

InfoQ：新的Azure Service Fabric Mesh与Azure Service Fabric Clusters有何不同？

Chacko：我们在Azure中提供了两种Service Fabric服务——Service Fabric Clusters和Service Fabric Mesh（预览版），用于在Azure中部署和管理应用程序。
Service Fabric Cluster为你提供了一个可靠的、可伸缩的VM集群，这些VM运行着Service Fabric运行时，你可以通过一个高可用的集群端点向其中部署和管理应用程序/服务（容器化或非容器化）。Service Fabric运行时基于它与底层Azure基础设施的集成来做出服务配置决策，保证它们的可靠性。
在使用Azure Service Fabric Clusters时，你不仅需要以管理员身份访问集群，还需要访问组成集群的VM。你可以选择使用VM SKU来满足你的要求，你可以决定要根据哪些网络安全规则和自动伸缩规则来伸缩集群。你可以设置Service Fabric运行时和VM操作系统自动升级。借助这个服务，你只需为使用的VM、存储和网络资源付费，Service Fabric运行时实际上是免费的。它非常适合需要完全控制基础设施的客户/ISV。
Azure Service Fabric Mesh目前处于预览阶段，它是一个完全托管的服务，它使你可以使用“无服务器”方法构建、部署和管理由运行在容器中的多语言服务（例如任何语言、任何操作系统）组成的应用程序。开发人员只需要指定他/她的应用程序/服务所需的资源，如容器的数量、容器的大小、网络属性、自动伸缩规则等，系统负责提供和管理所需的基础设施。这种方法使得开发人员可以只关注应用程序/服务，而不是基础设施。
Service Fabric Mesh还通过软件定义网络（SDN）功能（基于Envoy Proxy构建）提供智能消息路由，简化了服务发现和微服务之间的路由。在即将到来的预览更新中，我们计划启用其他SDN功能，如断路器、重试、SSL终止、蓝/绿部署以及使用托管服务标识简化安全。这里，你可以使用我前面提到的由Service Fabric提供的有状态功能。这里有一个关于Service Fabric Mesh的2分钟的视频，它汇总介绍了这里的部分信息。

InfoQ：Azure Service Fabric Mesh与一些读者可能熟悉的技术，例如Cloud Foundry、Kubernetes或Docker（通过Docker Compose配置），是什么关系？

Chacko：所有这些技术都非常类似，它们都编排或部署容器。Azure支持你提到的所有平台，所以你可以使用自己喜欢的技术栈。
至于其他Service Fabric服务，借助于Service Fabric Mesh，我们将继续致力于成为一个应用程序平台，首先抽象出所需的容器编排，并添加可以在应用程序中使用的智能消息传递路由和存储。你可以使用一组声明性策略部署和管理自己的应用程序，这些策略包括你需要的容量和网络、你希望如何伸缩、路由消息、管理证书，平台不仅将编排容器，还将负责管理基础设施并运行它。
在使用Service Fabric Mesh时，除非你查看平台日志，否则你甚至不知道Service Fabric是为服务提供支撑的底层平台，就像你不知道Service Fabric在Azure数据库和其他服务中使用一样。它使开发人员不必考虑编排器和其他低层管理服务。

InfoQ：您能介绍下Service Fabric平台的可伸缩性吗？

Chacko：尽管我们在内部运行了大量的测试，使用人工工作负载在内部对服务施加压力，但是，我将从实证方面来回答这个问题。大多数流行的Azure服务都使用了Service Fabric平台，比如Cosmos DB、IOT Hub、Event Hub、Azure SQL DB、Intune、Event Grid。每个Azure SQLDB事务在Service Fabric中都是一个复制操作，Azure中有数百万个SQL DB。每个CosmosDB写也是一个类似的复制操作，EventHub使用Service Fabric每天处理2万亿条消息，诸如此类。大多数人/公司都太可能需要超过Azure中这些使用数百万核的大型服务的规模。
该平台不仅具有高度可伸缩性，而且还提供零停机应用程序滚动升级、安全性、内置的健康监控、跨地域集群的能力等等。*这里*有一段Mark Russinovich的演讲视频，他是Azure的CTO，他展示了Service Fabric的伸缩和部署速度。在不到两分钟的时间里，他在3500个节点的Linux集群上部署和运行了100万个容器。
Service Fabric是一项每天都要经过实战测试的技术。

InfoQ：服务网格是当前一个热门的新兴话题吗？名称有点类似，那么Azure Service Fabric Mesh与Linkerd、Istio和Cilium等服务网格技术是什么关系呢？

Chacko：服务网格是关于连接服务和实现网络原语的，包括服务发现和快速、安全、可靠的服务到服务通信。Linkerd、Envoy和Cilium是网络代理，它们可以作为服务网格部署在Kubernetes或Service Fabric之类的编排器上。Istio等项目则允许你连接、保护、控制和观察服务，并使用Envoy提供了第7层（L7）网络功能。
Azure Service Fabric Mesh还允许你连接、部署、保护和管理服务，并在底层使用Envoy为Windows和Linux容器提供L7功能。然而，它不仅仅是一个服务网格——它是一个构建、部署、扩展和操作基于微服务的应用程序的应用程序平台。

InfoQ：Azure平台提供了一系列部署选项——Azure Service Fabric Mesh的主要用例是什么？我为什么要选择在这里构建和部署，而不是另一个Azure产品上，比如AKS或Azure Functions？

Chacko：Azure提供了多种计算选项来满足不同的客户用例。最终，我们希望客户能够成功地使用他们的首选技术栈、体系结构和/或已有的投资。
如果你正在为事件驱动的场景寻找一种无服务器的计算体验，那么鉴于其编程模型（基于触发器来响应发生在其他服务中的活动，基于绑定来方便地连接到不同的服务），我会推荐Azure Functions。
同样，如果你来自Linux生态系统，并且正在构建容器化的应用程序，那么你将使用Azure Kubernetes Service（AKS）。另外，我们还发现使用Red Hat Linux的客户正在迁移到Azure上的OpenShift。
如果你想要Windows/.Net或微服务, Service Fabric是一个很好的选择，Service Fabric Mesh提供了无服务器的全托管风格，让你可以将任何容器化的工作负载、Linux或Windows部署到Azure上。虽然Service Fabric可以用作容器编排器，但是它的优点在于它的编程模型，而且它是专门为在Azure中大规模构建、部署和操作微服务应用程序而设计的。
我们从2018年7月起就开始预览Azure Service Fabric Mesh，我们看到客户正在利用这种“无服务器”服务，现代化/升级他们当前的应用程序（Windows或Linux），并把它们迁移到Azure上，或者将新的多语言应用程序部署到Azure。

InfoQ：非常感谢您今天抽时间和我们交流。您还有什么想和InfoQ的读者分享的吗？

Chacko：感谢你们提供机会让我们分享我们团队的工作细节。Service Fabric Mesh的旅程刚刚开始，我们需要你们的帮助。请在这里试用Service Fabric Mesh预览版，并提供反馈。
可以在这里与我们分享你的想法、问题和反馈。还有，如果你有问题想问我的话，请给我发推特@chackod。

关于作者

Chacko Daniel是一名产品负责人，在构建企业级分布式计算平台和服务的产品/服务开发方面有着丰富的经验。他目前在微软担任首席技术PM，是平台运行时和两项Azure服务的所有者——Service Fabric Azure Cluster服务和Azure Service Fabric Mesh服务。

查看英文原文：Exploring Azure Service Fabric Mesh: A Platform for Building Mission Critical Microservices

创作场景

Azure Service Fabric Mesh：一个构建任务关键型微服务的平台