題記：鑑於社群對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有幾個缺點還是值得我們注意（當然隨著時間推移，可能也不成問題）：
- 對Windows的生產級支援剛剛提供，估計還沒有什麼實際案例，嘗試過程也會有很多坑。遇到坑，除非你有能力給Kubernetes提PR，不然只有乾瞪眼。
- 僅支援Windows Server 2019，這就需要對現有基礎設施進行升級。
- 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的體系結構圖，其他的不累述，我強調兩個部分：
- 叢集管理子系統：它背後的核心原理來自於專門研究拜占庭將軍問題的圖靈獎得主Leslie Lamport的研究成果，他在微軟是傑出科學家，解決了大規模叢集中節點狀態一致性問題。
- 可測試性子系統：它讓你可以輕鬆實現混亂測試，這個東西在網際網路公司可是非常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