Microsoft Azure Service Fabric

Microsoft Azure Service Fabric 是微软 Azure 平台上的平台服务之一，它也是基于微软资源管理架构与基础建设发展出的新型服务，可用来建置以微服务为主的云端分散式应用程式，而它也将会是 Microsoft Azure 云端服务 的后继者。Azure 平台上的数个重要服务如 Azure SQL Database、Azure IoT 服务、Azure DocumentDB、Azure Event Hub 等服务都是使用 Service Fabric 作为基础所开发。

Service Fabric 自 2015 年于 Build 2015 研讨会中揭示，并于 2016/3/30 Build 2016 研讨会上由 Scott Guthrie 宣布正式进入 General Availability 阶段。

架构

Service Fabric 是一个基于 Azure 基础建设上的平台服务，但它和 Azure 云端服务最大的差异是，Service Fabric 一开始就有丛集 (Cluster) 的概念，Azure 云端服务是以虚拟机器为单位，Service Fabric 则是以丛集为单位，每一个丛集依照服务等级会有不同的虚拟机器数量，大小则是看建立丛集时的选择。

运算能量

丛集所使用的虚拟机器的大小与Microsoft Azure 虚拟机器服务相同，依照地区与开放的程度可选择 A、D、DS 或是 G 等级的虚拟机器。

Service Fabric 规定每个丛集最低的虚拟机器数为 3 台 (且会标示成测试用服务)，正式的服务必须要有 5 台^[1]，丛集的持久性 (Durability) 被划分成金级 (固定使用 G 级虚拟机器) 与铜级 (可选择 A、D、DS 等虚拟机器)，可靠性 (Reliability) 则决定了最少的虚拟机器数量。

• 白金级 (Platinum) 9 台
• 金级 (Golden) 7 台
• 银级 (Silver) 5 台
• 铜级 (Bronze) 3 台

当持久性选定后，就只能针对数量来修改，虽然可靠性订定了下限，但上限则没有限制，视订用帐户的上限来决定 (也就是若想用到 10000 台的话只要联络微软技术支援开放上限就可以)。

Service Fabric 目前使用 Windows Server 作为基础作业系统，未来可能也会导入 Linux 版本的 Service Fabric 虚拟机器。

节点

一个 Service Fabric 丛集可以包含最多三个节点 (Node)，节点的概念和云端服务的角色类似，它可以个别定义虚拟机器的等级、类型与数量，配置方式也可以自订。当丛集部署到 Azure 后，每一个节点都会生成指定数量的虚拟机器，并且依照错误域 (Fault Domain) 与更新域 (Upgrade Domain) 做隔离配置，而每一个节点会拥有自己的负载平衡器，所有与该节点有关系的虚拟机器网路设定都要由该负载平衡器处理，包含对外的 IP 与可用的 Port 等。

节点的部署是采用虚拟机器扩展集 (VM Scale Set) 的规则进行，每一次的 VM 横向扩展都会赋与有规则性增长的连接埠，因此若要连到个别的虚拟机器，除了可用 Service Fabric 的 API 外，也可以由 Portal 取得该机器的 Port，再使用远端桌面连入即可。

开发模型

Service Fabric 在概念上有分为有状态 (Stateful) 以及无状态 (Stateless) 两种，而在 API 类型上则分为客座可执行档 (Guest Executable)、可靠动作者 (Reliable Actor) 以及可靠服务 (Reliable Service) 三种。

客座可执行档系指 Service Fabric 在启动服务时启动的是一个可执行档，而不是由 Service Fabric API 所开发的应用程式，因此它虽然是放在 Service Fabric 内，但本身并不参与 Service Fabric 里面的互动，通常也不会使用 Service Fabric 的 API 取得资讯 (例如服务的 Proxy 或是网路位址等)，它就只是单纯的可执行档，通常会作为前端介面，例如 node.js 网站。客座可执行档在 Service Fabric 中是以无状态的概念管理。

可靠动作者是以 Actor Model 的概念开发的，每个应用程式都是一个动作者 (Actor)，每个动作者是一个独立的单执行绪执行空间，但一个 Service Fabric 内可以有很多个动作者，而且每个动作者之间是隔离的空间，而每个动作者可以被建立出多个执行个体，简单的说，一个游戏者 (Gamer) 可以建立出多个动作者，例如与别的游戏者交谈的 Session Actor、游戏进行的主线 Main Actor、交换讯息的 Messaging Actor 等，而这些动作者可以被多个用户端所建立，因此等于每个动作者的拥有者都会不同，Service Fabric 丛集内会不断的生出许多的动作者，而每一个动作者都运行著它自己要做的工作，或是和别的 Actor 交谈。

可靠服务则是提供功能的服务，视应用程式需要可划分成有状态 (Stateful Service) 与无状态 (Stateless Service)，这两者的差异是有状态的服务可以使用可靠字典 (Reliable Dictionary) 与可靠伫列 (Reliable Queue) 来保存状态，可靠字典与可靠伫列的可用性与可存取性是由 Service Fabric 进行管理，服务不需要介入，只要使用 Service Fabric API 就能获取；无状态的服务则是一般的服务，若它要保存状态，就要依赖外部的状态保存机制，例如 Azure Redis Cache。

参考

1. Service Fabric 叢集容量規劃考量. [2016-05-12]. （原始内容存档于2016-06-11）.