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体系结构

image

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

image

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

image

上图是Service Fabric Native的体系结构图,其他的不累述,我强调两个部分:

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

编程模型

image

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

  • 来宾可执行程序:总是无状态的
    • 容器:本质是一种特殊的来宾。所以一切以容器为基础的平台,状态都只能在集群外部维护。
  • 可靠服务
    • 无状态服务
    • 有状态服务:集群可以帮助你维护状态
      • Actor服务(一种特殊的有状态服务)
    • 容器中的可靠服务:即在容器中运行利用SDK编写的服务,这样虽然有点画蛇添足,不过让你的运维环境统一为容器。

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

我一直说Service Fabric Native强大之处是可靠服务中的有状态服务,它通过提供一个强大的可靠集合(类似于NoSQL,但是是高可用、状态一致、可伸缩的)让你整个微服务的开发乃至中间件的开发变得轻而易举。

image

我们先来看两张示意图:

image

image

也就是,不需要依赖外部存储,直接把数据的保存和处理数据的逻辑放到一起,获得不一样的架构。这里还没有展开可靠Actor服务的强大呢。

有状态服务的强大不是口说无凭的,我们知道(估计还是很多人其实不知道),Azure上的很多PaaS的底层机制都是Service Fabric Native,如下图所示:

image

上图中,最为引人注目的就是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

posted @ 2019-04-06 22:08  朱永光  阅读(...)  评论(... 编辑 收藏