Service Fabric是什么？

题记：鉴于社区对Service Fabric有诸多误解，但愿借本文能让你们正确了解Service Fabric是一个什么东西，算是给其正名。

术语与分类

Service Fabric不只仅是容器编排器

Service Fabric 是一种开源的跨平台的分布式应用平台，经过它可轻松开发、打包、部署和管理可缩放且可靠的微服务（或者非微服务）。因此Service Fabric不只仅是一个容器编排器或者微服务平台，而是一个分布式平台，也意味着你要开发一个分布式应用，那么藉由SF，能够更容易的解决所遇到的一些问题：服务发现、高可用下的分布式状态一致性、服务生命周期管理、健康和资源监控、服务移动、按需缩放、故障恢复、滚动升级、良好的DevOps支持等等。

Service Fabric家族

为何说家族呢？由于根据不一样的形态或者平台，SF分为以下几种：

• 按操做系统平台：
• Service Fabric for Windows
• Service Fabric for Linux
• 按编程模型：
• Service Fabric Native：提供了特定的SDK，可让你在入侵代码（便可靠服务，支持.NET、.NET Core和Java）或者无入侵代码（即来宾可执行程序和容器应用，支持任意技术平台）的状况下，运行分布式应用。这种模式下，若是把SF看成一个容器编排器的话，SF=K8S。
• Service Fabric Mesh：提供了特定的SDK，让你无入侵代码（仅容器应用）的状况下，运行分布式应用。这种模式相似于Istio。应用能够是Linux的也能够是Windows的（好比旧的ASP.NET应用，固然须要容器化后）。
• 按托管环境：
• Azure Service Fabric：在Azure上开箱即用的Native集群，能够选择Windows集群仍是Linux集群，在国际和国内的Azure都支持。
• Service Fabric Standalone：在本地数据中心或者第三方云平台IaaS上，建立的Native集群。官方文档专门有一节讲如何在AWS中安装Standalone集群。固然因为官方只提供了Windows的安装包，因此若是你须要建立Linux的Standalone集群的话，要不经过源代码编译安装，要不联系微软帮你安装。
• Service Fabric Mesh：目前Service Fabric Mesh是一个纯托管的Azure PaaS，在国际和国内的Azure上处于预览状态。所谓PaaS就是你无需关心底层的基础设施，只须要部署Mesh应用就行，相似于Serverless。这点Service Fabric Mesh很是超前。
• Service Fabric开发集群：在本机安装一个用于开发目的的集群。这里安装的不是一个模拟器，而是和生产集群一样的运行时，这样的好处是应用在本地开发和生产运行的行为是一致的。Service Fabric Native的开发集群能够在Windows上安装，在Linux上安装（微软虽然没有提供生产集群的Linux安装包，可是提供了开发集群的安装包哦），在MacOS上经过Docker的方式来安装（Image：microsoft/service-fabric-onebox）。Service Fabric Mesh的开发集群只能在Windows上安装，可是你能够把Docker的模式改成Linux（或者利用LCOW模式，Linux Container On Windows），就能够在Windows上开发Linux的Mesh应用。
• 按容器编排模式：
• 资源模式：这是Service Fabric Mesh特用的编排模式，经过一系列yaml文件来描述你的Mesh应用的结构和依赖，这点相似于Helm Charts。
• 原生模式：这是Service Fabric Native支持的，经过xml清单文件来描述容器应用的结构和依赖，能够达到Helm Charts的效果。甚至于，这种模式支持在容器中运行可靠服务。
• Docker Compose模式：这也是在Service Fabric Native支持的一种变通模式，方便你把原有的Docker Compose应用迁移到SF中。

容器编排

在容器编排大战中，以Kubernetes胜出了结。尤为在最近的v1.14版本发布后，Kubernetes在生产级别支持Windows集群，感受Service Fabric做为容器编排器更是一无可取了。

可是Kubernetes有几个缺点仍是值得咱们注意（固然随着时间推移，可能也不成问题）：

1. 对Windows的生产级支持刚刚提供，估计尚未什么实际案例，尝试过程也会有不少坑。遇到坑，除非你有能力给Kubernetes提PR，否则只有干瞪眼。
2. 仅支持Windows Server 2019，这就须要对现有基础设施进行升级。
3. Kubernetes是中心化的架构设计，SF是非中心化架构设计。理论上说，非中心化能够管理更多的节点。详细比较能够见：http://cncc.bingj.com/cache.aspx?q=service+fabric+vs+kubernetes&d=4956308203112741&mkt=en-US&setlang=en-US&w=yS0m4YqKykfN3kzC17BYsOdrCrlumxkV （这篇文章也分析了Service Fabric的底层机制和应用场景）

可是，实际上Service Fabric Native对容器的编排能力是很是强的，只是弱在了相关生态建设和推广上。

同时，不要忘了Service Fabric Native除了能够编排容器之外，还能够编排在进程中跑的服务。由于并非全部应用都能顺利容器化（技术限制和法律限制（我就遇到过）），在这种状况下，若是你不想入侵代码就用来宾可执行程序，或者稍做改动使用可靠服务。

技术选型

就我的观点而言，建议的技术选型以下：

• 纯.NET Core的容器应用：使用Kubernetes或者Service Fabric Native或者Service Fabric Mesh均可以。若是你的组织已经在使用Kubernetes管理Linux集群来支持其余技术平台，那么就继续使用K8S来管理.NET Core容器应用（跑在Linux下）吧。
• 有遗留的ASP.NET 应用：
• 能够容器化：这个时候只能使用Windows容器集群，Kubernetes或者Service Fabric Native或者Service Fabric Mesh均可以，只是Service Fabric Native在编排Windows容器方面产品自己已经很成熟，已经有不少案例。
• 不能容器化但能够自托管：所谓自托管就是不须要依赖IIS就能跑起来，那么在旧的ASP.NET技术当中，只有ASP.NET WebAPI等支持原生OWIN的才能自托管。这个时候能够代价很是小（仅启动代码改动）就能够转变为可靠服务。这种状况下采用Service Fabric Native是惟一选择。
• 不能容器化也不能自托管：这个时候只能对应用进行迁移到ASP.NET Core。
• 有遗留的.NET开发的Windows Service应用：
• 能够容器化：在代码（较多）改造后，使用Kubernetes或者Service Fabric Native或者Service Fabric Mesh均可以。
• 不能容器化：在代码（较少）改造后，变为Service Fabric Native的可靠服务。
• 须要开发中间件产品：Service Fabric Native的可靠服务
• 须要开发大规模并发应用：好比IoT的Event接收、游戏后端等，Service Fabric Native的可靠Actor服务

若是你只是想在容器中跑下应用，那么看到这里应该已经足够了。可是，我再次强调，Service Fabric Native不只仅是一个编排器，它真正强大的地方是其可靠服务（尤为有状态服务）。

Service Fabric Native的可靠服务

Service Fabric Native体系结构

上图说明了，Service Fabric Native是跨平台且不绑定任何公有云平台的。并说明了一些内置的强大能力。

上图说明了，支持的多种运行形态，同时特有的SDK是支持.NET/.NET Core和Java的。

上图是Service Fabric Native的体系结构图，其余的不累述，我强调两个部分：

1. 集群管理子系统：它背后的核心原理来自于专门研究拜占庭将军问题的图灵奖得主Leslie Lamport的研究成果，他在微软是杰出科学家，解决了大规模集群中节点状态一致性问题。
2. 可测试性子系统：它让你能够轻松实现混乱测试，这个东西在互联网公司但是很是NB的存在哦。

编程模型

Service Fabric Native提供了灵活的编程模型：

• 来宾可执行程序：老是无状态的
• 容器：本质是一种特殊的来宾。因此一切以容器为基础的平台，状态都只能在集群外部维护。
• 可靠服务
• 无状态服务
• 有状态服务：集群能够帮助你维护状态
• Actor服务（一种特殊的有状态服务）
• 容器中的可靠服务：即在容器中运行利用SDK编写的服务，这样虽然有点多此一举，不过让你的运维环境统一为容器。

被严重低估和忽略的有状态服务

我一直说Service Fabric Native强大之处是可靠服务中的有状态服务，它经过提供一个强大的可靠集合（相似于NoSQL，可是是高可用、状态一致、可伸缩的）让你整个微服务的开发乃至中间件的开发变得垂手可得。

咱们先来看两张示意图：

也就是，不须要依赖外部存储，直接把数据的保存和处理数据的逻辑放到一块儿，得到不同的架构。这里尚未展开可靠Actor服务的强大呢。

有状态服务的强大不是口说无凭的，咱们知道（估计仍是不少人其实不知道），Azure上的不少PaaS的底层机制都是Service Fabric Native，以下图所示：

上图中，最为引人注目的就是Cosmos DB了，下面摘抄一份官方说明：

Azure Cosmos DB 从一开始就将分布和横向缩放做为其核心。经过透明地缩放和复制数据（不管用户位于何处），在任意数量的 Azure 区域提供统包分布。灵活缩放多个数据中心范围内的吞吐量和存储，只为须要的吞吐量和存储付费。Azure Cosmos DB 提供对 NoSQL 和 OSS API（包括 MongoDB、Cassandra、Gremlin 和 SQL）的本机支持，还提供多种明肯定义的一致性模型，Azure Cosmos DB 保证各区域任意位置在第 99 个百分位为个位数毫秒的延迟，提供多种定义明确的一致性模型以微调性能，并保证多宿主功能的高可用性

为何Cosmos DB能实现上述这种NB的特性，诀窍就是有状态服务！

最后，但愿对可靠服务尤为有状态服务深刻了解的朋友，能够仔细阅读官方文档，并深刻理解这个示例：https://github.com/Azure-Samples/service-fabric-dotnet-web-reference-app

另外，若是你喜欢看纸质书，那么我参与撰写的《架构宝典》也对Service Fabric Native有所简单介绍：https://item.jd.com/12561926.html