ServiceFabric：用于云端构建微服务的分布式渠道。

　　微软的 Service Fabric 为 Azure 的许多要害服务供给支撑。它已开发了大约 15 年，安置于出产环境已有 10 年，2015 年供外界运用。

　　ServiceFabric（SF）让用户可以关于由微服务组成的可扩展、牢靠的应用程序进行应用程序生命周期办理――这些微服务在同享的机器集群上高密度运转，从开发到安置到办理，供给一站式功用。

　　在 SF 上运转的几个值得重视的体系包括：

• 　　Azure SQL DB（100000 台机器，含有 3.48PB 数据的 182 万个数据库）

• 　　Azure Cosmos DB（200 万个中心和 100000 台机器）

• 　　Skype

• 　　Azure 作业中心

• 　　Intune

• 　　Azure IoT 套件

• 　　Cortana

　　SF 在多个集群中运转，每个集群有成百上千台机器，机器总数超越 160000 台，中心数量超越 250 万个。

　　定位和方针

　　Service Fabric 不太好分类，但论文作者将其描绘为“微软在云环境下支撑微服务应用程序的渠道”。特别异乎寻常的当地是，Service Fabric 立足于强共同性（strong consistency）的根底，包括经过牢靠调集（reliable collections）支撑有状况服务（stateful service）：牢靠、耐久、高效、业务性的高档数据结构。

　　现有体系为微服务供给不同等级的支撑，市面上最首要的体系有 Nirmata、Akka、Bluemix、Kubernetes、Mesos 和 AWS Lambda[良莠不齐]。SF 功用比较强壮：它是现在仅有面向有状况微服务、可辨认数据的编列体系。特别是，咱们需求支撑初级架构组件中的状况和共同性，这促进咱们处理与毛病检测、毛病切换、leader 推举、共同性、可扩展性和可办理性有关的分布式核算难题。与上面这些体系不同，SF 没有外部依靠项，它是一种独立的结构。

　　SF 中的每一层都支撑强共同性。这不是说你无法在上面构建弱共同性的服务（假如你想这么做的话），但这个难题比在不共同的组件上构建强共同性的服务来得简略处理。“根据咱们的运用场景研讨，咱们发现需求 SF 的团队大大都都要求强共同性，比方微软 Azure DB、微软商业剖析东西等，它们在履行业务时都依靠 SF。”

　　总体规划　　

　　SF 应用程序是独立版别操控、可晋级的微服务的调集，每个微服务都履行一项独立功用，由代码、装备和数据组成。

　　SF 自身包括多个子体系，首要的子体系如下图所示。

　　SF 的中心是联合子体系（Federation Subsystem），它处理毛病检测、路由和 leader 推举。建立在联合子体系上的是供给仿制和高可用性的牢靠性子体系（reliability subsystem）。论文更具体地描绘了这两个子体系。

　　联合子体系

　　环

　　在联合子体系的中心，你会发现一个有2^m点的虚拟环，名为 SF 环（SF-Ring）。2000 年头它是在微软内部开发的，与 Chord 和 Kademlia 较为类似。节点和密钥映射到环中的一个点，密钥由最接近它的那个节点具有，由前一个节点取得联络。每个节点盯梢环中紧跟它的后一个节点和前一个节点，这些节点构成了街坊节点集（neighborhood set）。

　　路由表条目是双向、对称的。路由同伴在环中以急剧添加的间隔来加以坚持，按顺时针方向和逆时针方向。因为双向性，大大都路由同伴终究都是对称的。这加快了路由、毛病信息的传达以及节点丢失后的路由表更新。

　　转发密钥音讯时，节点以顺时针方向或逆时针方向查找路由表中最接近密钥的那个节点。比较只按顺时针方向的路由，咱们取得了速度更快的路由，面临过期表或空白表有更多的路由挑选，可以更有效地跨节点分配负载，以及防止路由环路。

　　路由表终究收敛。谈天协议在路由同伴之间交流路由表信息，保证远间隔街坊节点具有终究共同性。

　　SF 方面的一个要害结果是，假如将强共同性成员与环上的弱共同性成员结合起来，可以大规模支撑强共同性应用程序。文献常常将强共同性成员等同于虚拟同步，但这种办法在可扩展性方面存在约束。

　　环中的节点具有路由令牌（routing token），路由令牌表明环中哪部分的密钥由它们担任。SF 环协议保证令牌之间永久不会有任何堆叠（一直安全），每个令牌规模终究都由至少一个节点具有（终究存活）。有节点参加时，前后两个相邻的节点各自与新节点共享其在环上的一段。有节点脱离时，前后两个相邻的节点在当中将令牌规模分隔来。

　　假如咱们看一下牢靠性子体系，会发现节点和目标（服务）被安置到环中，而不是简略地依靠哈希。这样一来，优先安置（preferential placement）可以考虑到毛病域和负载均衡。

　　共同性成员和毛病检测

　　成员和毛病检测在街坊节点集里边进行。有两个要害的规划准则：

1. 强共同性成员：担任监督节点X的一切节点有必要就该节点是正常仍是宕机达到共同。在 SF 环中，这意味着X的街坊节点集内的一切节点有必要就其状况达到共同。

2. 毛病检测与毛病决议计划分隔：毛病检测协议（心跳）检测或许的毛病，而独立的裁定节点组（arbitrator group）决议怎么处理此状况。这有助于发现并阻挠起连锁反应的毛病检测。

　　节点X定时向其每个街坊节点（监督节点）发送续租恳求。租借期动态调整，但通常是 30 秒左右。X有必要从它的一切监督节点取得承认（租约）。这个特点界说了强共同性。假如X未能取得悉数租约，它考虑将自己从组中移除。假如监督节点错失X的续租心跳，它考虑将X标记为有毛病。在这两种状况下，依据都提交给裁定节点组。

　　裁定节点充任毛病检测和检测抵触的裁判。出于速度和容错方面的考虑，裁定节点被施行成一个涣散的节点组（每个节点独立运转）。一旦体系中的任何节点检测到毛病，在采纳与该毛病相关的操作之前，它需求取得裁定节点组中大大都（法定数额）节点的承认。

　　裁定节点协议的细节可在论文第 4.2.2 节找到。运用轻量级裁定节点组让成员、因而让环可以扩展到整个数据中心。

　　leader 推举

　　鉴于咱们有一个精心保护的环，SF 为 leader 推举供给了一种奇妙而有用的处理方案：

　　关于 SF 环中的任何密钥k，都有一个共同的 leader：这是令牌规模包括k的节点（因为路由令牌的安全性和活泼性，这个节点具有仅有性）。任何节点都可以经过路由到密钥k来联络 leader。因而 leader 推举是隐式的，不需求额定音讯。在整个环需求 leader 的状况下，咱们运用 k = 0。

　　牢靠性子体系

　　为了简练起见，我将专心于牢靠性子体系的安置和负载均衡器（PLB）组件。它的使命便是将微服务实例安置到节点，一起保证负载均衡。

　　不像传统的分布式哈希表（DHT），目标 ID 被哈希到一个环，PLB 为 SF 环中的节点分配每个服务的副本（主副本和次副本）。

　　安置组件会考虑节点处的可用资源、未完结的恳求以及典型恳求的参数。它还不断将服务从过度耗尽的节点转移到未充分使用的节点。 PLB 还将服务从行将晋级的节点搬迁出去。

　　PLB 或许会处理不断改变的环境中不计其数个目标，因而某一时间作出的决议鄙人一时间或许不是***的。因而，PLB 倾向做出快速灵敏的决议计划，不断进行小幅改善。为此运用了模拟退火（Simulated annealing）。模拟退火算法设置一个计时器（快速形式下是 10s，　慢速形式下是 120s），并探求状况空间，直到收敛或直到计时器到期。每个状况都有能量。能量函数是用户可界说的，但一种常见的状况是集群中一切衡量的均匀标准偏差（越低越好）。

　　每一步生成随机移动，考虑因这个移动而导致的新预期状况的能量，并决议要不要跳动。假如新状况的能量较低，退火进程跳动的概率为1；不然，假如新状况的能量比当时状况高出d，当时温度是T，跳动产生的概率是e-d/T。这个温度T在初始步中很高（答应从部分最小值跳动），但跨迭代线性下降，以便之后收敛。

　　所考虑的移动是细粒度的。比方说，将次副本交流到另一个节点，或许交流主副本和次副本。

　　牢靠调集

　　SF 的牢靠调集供给字典和行列之类的数据结构，它们具有耐久性、可用性、容错性，高效性和业务性。状况本地保存在服务实例中，一起又具有高可用性，所以读取是本地的。写入经过被迫仿制从主副本转发到次副本，一旦法定数额得到承认，就被以为完结。

　　牢靠调集立足于联合子体系和牢靠性子体系的服务：副本在 SF 环中加以安排，检测到毛病后，推举一个主节点。PLB（与毛病切换办理器合作运用）坚持副本容错和负载均衡。

　　SF 是仅有自给自足的微服务体系，可以用来构建牢靠的、自我*和可晋级的业务共同性数据库。

　　罗致的经验教训

　　论文第 7 节深化议论了开发 SF 进程中罗致的经验教训。因为篇幅所限，我在这里只给出标题，建议您参看论文以了解具体信息：

• 　　分布式体系不仅仅是节点和网络。灰色毛病很常见。

• 　　应用程序/渠道的职责需求清晰别离（你不能信任开发人员总是做对作业）。

• 　　容量规划是应用程序的职责（但开发人员需求协助）。

• 　　不同的子体系需求不同等级的投入。

　　下一步是什么？

　　咱们的日常作业首要处理这个问题：下降办理集群的复杂性。为此，一项作业便是改用这种服务：客户永久看不到一台台服务器......其他值得重视、长时间的形式围绕着让客户具有服务器，还要可以在那些服务器参加进来后将微服务办理作为一项服务来运转。此外从短期来看，咱们考虑在牢靠调集中完成不同的共同性等级，主动向内扩展和向外扩展牢靠调集分区，并供给地理分布副本集的功用。从稍久远来看，咱们在考虑最有效地使用非易失性内存，作为 ServiceFabric 的牢靠调集的存储区。这需求处理许多值得重视的问题，从记载字节与面向块的存储、高效加密到感知业务的内存分配，不胜枚举。

　　论文：