题记：鉴于社区对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有几个缺点还是值得我们注意（当然随着时间推移，可能也不成问题）：
- 对Windows的生产级支持刚刚提供，估计还没有什么实际案例，尝试过程也会有很多坑。遇到坑，除非你有能力给Kubernetes提PR，不然只有干瞪眼。
- 仅支持Windows Server 2019，这就需要对现有基础设施进行升级。
- 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的体系结构图，其他的不累述，我强调两个部分：
- 集群管理子系统：它背后的核心原理来自于专门研究拜占庭将军问题的图灵奖得主Leslie Lamport的研究成果，他在微软是杰出科学家，解决了大规模集群中节点状态一致性问题。
- 可测试性子系统：它让你可以轻松实现混乱测试，这个东西在互联网公司可是非常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