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有几个缺点还是值得我们注意（当然随着时间推移，可能也不成问题）：
对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
分享到： 更多