微軟開源的 ServiceFabric：SF在多個集群中運行，機器總數超過160000台，核心數量超過250萬個

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）可以考慮到故障域和負載均衡。

一致性成員和故障檢測

成員和故障檢測在鄰居節點集裡面進行。有兩個關鍵的設計原則：

強一致性成員：負責監視節點X的所有節點必須就該節點是正常還是宕機達成一致。在SF環中，這意味著X的鄰居節點集內的所有節點必須就其狀態達成一致。

故障檢測與故障決策分開：故障檢測協議（心跳）檢測可能的故障，而獨立的仲裁節點組（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的可靠集合的存儲區。這需要處理許多值得關注的問題，從記錄位元組與面向塊的存儲、高效加密到感知事務的內存分配，不一而足。

論文：

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！