ServiceFabric：用于云端構(gòu)建微服務(wù)的分布式平臺(tái)。

　　微軟的 Service Fabric 為 Azure 的許多關(guān)鍵服務(wù)提供支持。它已開發(fā)了大約 15 年，部署于生產(chǎn)環(huán)境已有 10 年，2015 年供外界使用。

　　ServiceFabric（SF）讓用戶能夠?qū)τ谟晌⒎?wù)組成的可擴(kuò)展、可靠的應(yīng)用程序進(jìn)行應(yīng)用程序生命周期管理――這些微服務(wù)在共享的機(jī)器集群上高密度運(yùn)行，從開發(fā)到部署到管理，提供一站式功能。

　　在 SF 上運(yùn)行的幾個(gè)值得關(guān)注的系統(tǒng)包括：

• 　　Azure SQL DB（100000 臺(tái)機(jī)器，含有 3.48PB 數(shù)據(jù)的 182 萬個(gè)數(shù)據(jù)庫）

• 　　Azure Cosmos DB（200 萬個(gè)核心和 100000 臺(tái)機(jī)器）

• 　　Skype

• 　　Azure 事件中心

• 　　Intune

• 　　Azure IoT 套件

• 　　Cortana

　　SF 在多個(gè)集群中運(yùn)行，每個(gè)集群有成百上千臺(tái)機(jī)器，機(jī)器總數(shù)超過 160000 臺(tái)，核心數(shù)量超過 250 萬個(gè)。

　　定位和目標(biāo)

　　Service Fabric 不太好分類，但論文作者將其描述為“微軟在云環(huán)境下支持微服務(wù)應(yīng)用程序的平臺(tái)”。尤其與眾不同的地方是，Service Fabric 立足于強(qiáng)一致性（strong consistency）的基礎(chǔ)，包括通過可靠集合（reliable collections）支持有狀態(tài)服務(wù)（stateful service）：可靠、持久、高效、事務(wù)性的高級(jí)數(shù)據(jù)結(jié)構(gòu)。

　　現(xiàn)有系統(tǒng)為微服務(wù)提供不同級(jí)別的支持，市面上最主要的系統(tǒng)有 Nirmata、Akka、Bluemix、Kubernetes、Mesos 和 AWS Lambda[良莠不齊]。SF 功能比較強(qiáng)大：它是如今唯一面向有狀態(tài)微服務(wù)、可識(shí)別數(shù)據(jù)的編排系統(tǒng)。尤其是，我們需要支持低級(jí)架構(gòu)組件中的狀態(tài)和一致性，這促使我們解決與故障檢測、故障切換、leader 選舉、一致性、可擴(kuò)展性和可管理性有關(guān)的分布式計(jì)算難題。與上面這些系統(tǒng)不同，SF 沒有外部依賴項(xiàng)，它是一種獨(dú)立的框架。

　　SF 中的每一層都支持強(qiáng)一致性。這不是說你無法在上面構(gòu)建弱一致性的服務(wù)（如果你想這么做的話），但這個(gè)難題比在不一致的組件上構(gòu)建強(qiáng)一致性的服務(wù)來得容易解決。“基于我們的使用場景研究，我們發(fā)現(xiàn)需要 SF 的團(tuán)隊(duì)大多數(shù)都要求強(qiáng)一致性，比如微軟 Azure DB、微軟商業(yè)分析工具等，它們在執(zhí)行事務(wù)時(shí)都依賴 SF。”

　　總體設(shè)計(jì)　　

　　SF 應(yīng)用程序是獨(dú)立版本控制、可升級(jí)的微服務(wù)的集合，每個(gè)微服務(wù)都執(zhí)行一項(xiàng)獨(dú)立功能，由代碼、配置和數(shù)據(jù)組成。

　　SF 本身包括多個(gè)子系統(tǒng)，主要的子系統(tǒng)如下圖所示。

　　SF 的核心是聯(lián)合子系統(tǒng)（Federation Subsystem），它處理故障檢測、路由和 leader 選舉。建立在聯(lián)合子系統(tǒng)上的是提供復(fù)制和高可用性的可靠性子系統(tǒng)（reliability subsystem）。論文更詳細(xì)地描述了這兩個(gè)子系統(tǒng)。

　　聯(lián)合子系統(tǒng)

　　環(huán)

　　在聯(lián)合子系統(tǒng)的核心，你會(huì)發(fā)現(xiàn)一個(gè)有2^m點(diǎn)的虛擬環(huán)，名為 SF 環(huán)（SF-Ring）。2000 年初它是在微軟內(nèi)部開發(fā)的，與 Chord 和 Kademlia 頗為相似。節(jié)點(diǎn)和密鑰映射到環(huán)中的一個(gè)點(diǎn)，密鑰由最靠近它的那個(gè)節(jié)點(diǎn)擁有，由前一個(gè)節(jié)點(diǎn)獲得聯(lián)系。每個(gè)節(jié)點(diǎn)跟蹤環(huán)中緊跟它的后一個(gè)節(jié)點(diǎn)和前一個(gè)節(jié)點(diǎn)，這些節(jié)點(diǎn)構(gòu)成了鄰居節(jié)點(diǎn)集（neighborhood set）。

　　路由表?xiàng)l目是雙向、對(duì)稱的。路由伙伴在環(huán)中以急劇增加的距離來加以維持，按順時(shí)針方向和逆時(shí)針方向。由于雙向性，大多數(shù)路由伙伴最終都是對(duì)稱的。這加快了路由、故障信息的傳播以及節(jié)點(diǎn)流失后的路由表更新。

　　轉(zhuǎn)發(fā)密鑰消息時(shí)，節(jié)點(diǎn)以順時(shí)針方向或逆時(shí)針方向搜索路由表中最靠近密鑰的那個(gè)節(jié)點(diǎn)。相比只按順時(shí)針方向的路由，我們獲得了速度更快的路由，面對(duì)過期表或空白表有更多的路由選擇，可以更有效地跨節(jié)點(diǎn)分配負(fù)載，以及避免路由環(huán)路。

　　路由表最終收斂。聊天協(xié)議在路由伙伴之間交換路由表信息，確保遠(yuǎn)距離鄰居節(jié)點(diǎn)擁有最終一致性。

　　SF 方面的一個(gè)關(guān)鍵結(jié)果是，如果將強(qiáng)一致性成員與環(huán)上的弱一致性成員結(jié)合起來，可以大規(guī)模支持強(qiáng)一致性應(yīng)用程序。文獻(xiàn)常常將強(qiáng)一致性成員等同于虛擬同步，但這種方法在可擴(kuò)展性方面存在限制。

　　環(huán)中的節(jié)點(diǎn)擁有路由令牌（routing token），路由令牌表示環(huán)中哪部分的密鑰由它們負(fù)責(zé)。SF 環(huán)協(xié)議確保令牌之間永遠(yuǎn)不會(huì)有任何重疊（始終安全），每個(gè)令牌范圍最終都由至少一個(gè)節(jié)點(diǎn)擁有（最終存活）。有節(jié)點(diǎn)加入時(shí)，前后兩個(gè)相鄰的節(jié)點(diǎn)各自與新節(jié)點(diǎn)分享其在環(huán)上的一段。有節(jié)點(diǎn)離開時(shí)，前后兩個(gè)相鄰的節(jié)點(diǎn)在當(dāng)中將令牌范圍分開來。

　　如果我們看一下可靠性子系統(tǒng)，會(huì)發(fā)現(xiàn)節(jié)點(diǎn)和對(duì)象（服務(wù)）被布置到環(huán)中，而不是簡單地依賴哈希。這樣一來，優(yōu)先布置（preferential placement）可以考慮到故障域和負(fù)載均衡。

　　一致性成員和故障檢測

　　成員和故障檢測在鄰居節(jié)點(diǎn)集里面進(jìn)行。有兩個(gè)關(guān)鍵的設(shè)計(jì)原則：

1. 強(qiáng)一致性成員：負(fù)責(zé)監(jiān)視節(jié)點(diǎn)X的所有節(jié)點(diǎn)必須就該節(jié)點(diǎn)是正常還是宕機(jī)達(dá)成一致。在 SF 環(huán)中，這意味著X的鄰居節(jié)點(diǎn)集內(nèi)的所有節(jié)點(diǎn)必須就其狀態(tài)達(dá)成一致。

2. 故障檢測與故障決策分開：故障檢測協(xié)議（心跳）檢測可能的故障，而獨(dú)立的仲裁節(jié)點(diǎn)組（arbitrator group）決定如何處理此情況。這有助于發(fā)現(xiàn)并阻止起連鎖反應(yīng)的故障檢測。

　　節(jié)點(diǎn)X定期向其每個(gè)鄰居節(jié)點(diǎn)（監(jiān)視節(jié)點(diǎn)）發(fā)送續(xù)租請求。租賃期動(dòng)態(tài)調(diào)整，但通常是 30 秒左右。X必須從它的所有監(jiān)視節(jié)點(diǎn)獲得確認(rèn)（租約）。這個(gè)屬性定義了強(qiáng)一致性。如果X未能獲得全部租約，它考慮將自己從組中移除。如果監(jiān)視節(jié)點(diǎn)錯(cuò)過X的續(xù)租心跳，它考慮將X標(biāo)記為有故障。在這兩種情況下，證據(jù)都提交給仲裁節(jié)點(diǎn)組。

　　仲裁節(jié)點(diǎn)充當(dāng)故障檢測和檢測沖突的裁判。出于速度和容錯(cuò)方面的考慮，仲裁節(jié)點(diǎn)被實(shí)施成一個(gè)分散的節(jié)點(diǎn)組（每個(gè)節(jié)點(diǎn)獨(dú)立運(yùn)行）。一旦系統(tǒng)中的任何節(jié)點(diǎn)檢測到故障，在采取與該故障相關(guān)的操作之前，它需要獲得仲裁節(jié)點(diǎn)組中大多數(shù)（法定數(shù)額）節(jié)點(diǎn)的確認(rèn)。

　　仲裁節(jié)點(diǎn)協(xié)議的細(xì)節(jié)可在論文第 4.2.2 節(jié)找到。使用輕量級(jí)仲裁節(jié)點(diǎn)組讓成員、因而讓環(huán)可以擴(kuò)展到整個(gè)數(shù)據(jù)中心。

　　leader 選舉

　　鑒于我們有一個(gè)精心維護(hù)的環(huán)，SF 為 leader 選舉提供了一種巧妙而實(shí)用的解決方案：

　　對(duì)于 SF 環(huán)中的任何密鑰k，都有一個(gè)獨(dú)特的 leader：這是令牌范圍包含k的節(jié)點(diǎn)（由于路由令牌的安全性和活躍性，這個(gè)節(jié)點(diǎn)具有唯一性）。任何節(jié)點(diǎn)都可以通過路由到密鑰k來聯(lián)系 leader。因此 leader 選舉是隱式的，不需要額外消息。在整個(gè)環(huán)需要 leader 的情況下，我們使用 k = 0。

　　可靠性子系統(tǒng)

　　為了簡潔起見，我將專注于可靠性子系統(tǒng)的布置和負(fù)載均衡器（PLB）組件。它的任務(wù)就是將微服務(wù)實(shí)例布置到節(jié)點(diǎn)，同時(shí)確保負(fù)載均衡。

　　不像傳統(tǒng)的分布式哈希表（DHT），對(duì)象 ID 被哈希到一個(gè)環(huán)，PLB 為 SF 環(huán)中的節(jié)點(diǎn)分配每個(gè)服務(wù)的副本（主副本和次副本）。

　　布置組件會(huì)考慮節(jié)點(diǎn)處的可用資源、未完成的請求以及典型請求的參數(shù)。它還不斷將服務(wù)從過度耗盡的節(jié)點(diǎn)轉(zhuǎn)移到未充分利用的節(jié)點(diǎn)。 PLB 還將服務(wù)從即將升級(jí)的節(jié)點(diǎn)遷移出去。

　　PLB 可能會(huì)處理不斷變化的環(huán)境中成千上萬個(gè)對(duì)象，因此某一時(shí)刻作出的決定在下一時(shí)刻可能不是***的。因此，PLB 偏向做出快速敏捷的決策，不斷進(jìn)行小幅改進(jìn)。為此使用了模擬退火（Simulated annealing）。模擬退火算法設(shè)置一個(gè)計(jì)時(shí)器（快速模式下是 10s，　慢速模式下是 120s），并探究狀態(tài)空間，直到收斂或直到計(jì)時(shí)器到期。每個(gè)狀態(tài)都有能量。能量函數(shù)是用戶可定義的，但一種常見的情況是集群中所有度量的平均標(biāo)準(zhǔn)偏差（越低越好）。

　　每一步生成隨機(jī)移動(dòng)，考慮因這個(gè)移動(dòng)而導(dǎo)致的新預(yù)期狀態(tài)的能量，并決定要不要跳躍。如果新狀態(tài)的能量較低，退火過程跳躍的概率為1；否則，如果新狀態(tài)的能量比當(dāng)前狀態(tài)高出d，當(dāng)前溫度是T，跳躍發(fā)生的概率是e-d/T。這個(gè)溫度T在初始步中很高（允許從局部最小值跳躍），但跨迭代線性下降，以便之后收斂。

　　所考慮的移動(dòng)是細(xì)粒度的。比如說，將次副本交換到另一個(gè)節(jié)點(diǎn)，或者交換主副本和次副本。

　　可靠集合

　　SF 的可靠集合提供字典和隊(duì)列之類的數(shù)據(jù)結(jié)構(gòu)，它們具有持久性、可用性、容錯(cuò)性，高效性和事務(wù)性。狀態(tài)本地保存在服務(wù)實(shí)例中，同時(shí)又具有高可用性，所以讀取是本地的。寫入通過被動(dòng)復(fù)制從主副本轉(zhuǎn)發(fā)到次副本，一旦法定數(shù)額得到確認(rèn)，就被認(rèn)為完成。

　　可靠集合立足于聯(lián)合子系統(tǒng)和可靠性子系統(tǒng)的服務(wù)：副本在 SF 環(huán)中加以組織，檢測到故障后，選舉一個(gè)主節(jié)點(diǎn)。PLB（與故障切換管理器配合使用）保持副本容錯(cuò)和負(fù)載均衡。

　　SF 是唯一自給自足的微服務(wù)系統(tǒng)，可以用來構(gòu)建可靠的、自我*和可升級(jí)的事務(wù)一致性數(shù)據(jù)庫。

　　汲取的經(jīng)驗(yàn)教訓(xùn)

　　論文第 7 節(jié)深入談?wù)摿碎_發(fā) SF 過程中汲取的經(jīng)驗(yàn)教訓(xùn)。由于篇幅所限，我在這里只給出標(biāo)題，建議您參閱論文以了解詳細(xì)信息：

• 　　分布式系統(tǒng)不僅僅是節(jié)點(diǎn)和網(wǎng)絡(luò)?；疑收虾艹Ｒ姟?/p>

• 　　應(yīng)用程序/平臺(tái)的責(zé)任需要明確分離（你不能相信開發(fā)人員總是做對(duì)事情）。

• 　　容量規(guī)劃是應(yīng)用程序的責(zé)任（但開發(fā)人員需要幫助）。

• 　　不同的子系統(tǒng)需要不同級(jí)別的投入。

　　下一步是什么？

　　我們的日常工作主要解決這個(gè)問題：降低管理集群的復(fù)雜性。為此，一項(xiàng)工作就是改用這種服務(wù)：客戶永遠(yuǎn)看不到一臺(tái)臺(tái)服務(wù)器......其他值得關(guān)注、長期的模式圍繞著讓客戶擁有服務(wù)器，還要能夠在那些服務(wù)器加入進(jìn)來后將微服務(wù)管理作為一項(xiàng)服務(wù)來運(yùn)行。此外從短期來看，我們考慮在可靠集合中實(shí)現(xiàn)不同的一致性級(jí)別，自動(dòng)向內(nèi)擴(kuò)展和向外擴(kuò)展可靠集合分區(qū)，并提供地理分布副本集的功能。從稍長遠(yuǎn)來看，我們在考慮最有效地利用非易失性內(nèi)存，作為 ServiceFabric 的可靠集合的存儲(chǔ)區(qū)。這需要處理許多值得關(guān)注的問題，從記錄字節(jié)與面向塊的存儲(chǔ)、高效加密到感知事務(wù)的內(nèi)存分配，不一而足。

　　論文：