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體系結構

上圖說明了，Service Fabric Native是跨平臺且不綁定任何公有云平臺的。並說明了一些內置的強大能力。

上圖說明了，支持的多種運行形態，同時特有的SDK是支持.NET/.NET Core和Java的。

上圖是Service Fabric Native的體系結構圖，其餘的不累述，我強調兩個部分：

1. 集羣管理子系統：它背後的核心原理來自於專門研究拜占庭將軍問題的圖靈獎得主Leslie Lamport的研究成果，他在微軟是傑出科學家，解決了大規模集羣中節點狀態一致性問題。
2. 可測試性子系統：它讓你能夠輕鬆實現混亂測試，這個東西在互聯網公司但是很是NB的存在哦。

編程模型

Service Fabric Native提供了靈活的編程模型：

• 來賓可執行程序：老是無狀態的
• 容器：本質是一種特殊的來賓。因此一切以容器爲基礎的平臺，狀態都只能在集羣外部維護。
• 可靠服務
• 無狀態服務
• 有狀態服務：集羣能夠幫助你維護狀態
• Actor服務（一種特殊的有狀態服務）
• 容器中的可靠服務：即在容器中運行利用SDK編寫的服務，這樣雖然有點多此一舉，不過讓你的運維環境統一爲容器。

被嚴重低估和忽略的有狀態服務

我一直說Service Fabric Native強大之處是可靠服務中的有狀態服務，它經過提供一個強大的可靠集合（相似於NoSQL，可是是高可用、狀態一致、可伸縮的）讓你整個微服務的開發乃至中間件的開發變得垂手可得。

咱們先來看兩張示意圖：

也就是，不須要依賴外部存儲，直接把數據的保存和處理數據的邏輯放到一塊兒，得到不同的架構。這裏尚未展開可靠Actor服務的強大呢。

有狀態服務的強大不是口說無憑的，咱們知道（估計仍是不少人其實不知道），Azure上的不少PaaS的底層機制都是Service Fabric Native，以下圖所示：

上圖中，最爲引人注目的就是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