Service Fabric 應用程序方案
2017/08/14 作者 Edward Chen Jack Zeng
Azure Service Fabric提供了一個可靠而靈活的平台，可用於編寫和運行多種類型的商業應用程序和服務。這些應用程序和微服務可以無狀態也可以有狀態，它們在各虛擬機間資源平衡，可最大限度提高工作效率。 通過 Service Fabric的獨特體系結構，可以在應用程序中執行准實時數據分析、內存中計算、並行事務和事件處理。 可根據不斷變化的資源要求輕松向上或向下縮放應用程序（其實是擴展或縮減）。
Azure 中的 Service Fabric 平台非常適合以下類別的應用程序：
- 高度可用的服務：Service Fabric服務通過創建多個輔助服務副本提供快速的故障轉移。 節點、進程或單個服務因硬件或其他故障而不可用時，其中一個次要副本會提升為主要副本，將服務的損失降到最低。
- 可縮放的服務：可對單個服務進行分區，以允許在群集范圍內擴大狀態。 此外，還可動態創建和刪除各項服務。 可根據資源需求簡便快捷地擴大服務，從幾個節點上的幾個實例增加到多個節點上的數千個實例，然后再次縮小。 可以使用 Service Fabric 生成這些服務並管理其整個生命周期。
- 非靜態數據計算：Service Fabric 使用戶能夠生成數據、輸入/輸出並計算密集型有狀態應用程序。 Service Fabric 允許在應用程序中共置處理（計算）和數據。 當應用程序需要訪問數據時，通常會存在與外部數據緩存或存儲層關聯的網絡延遲。 使用 Service Fabric 有狀態服務可消除這種延遲，從而提高讀取和寫入性能。 例如，假設有應用程序為客戶執行准實時建議選擇，且要求往返時間小於 100 毫秒。 與必須從遠程存儲中提取所需數據的標准實現模型相比，Service Fabric 服務（其中的建議選擇計算與數據和規則共置）的延遲和性能特征向用戶提供一種響應體驗。
- 基於會話的交互式應用程序：在應用程序（例如在線游戲或即時消息）需要低延遲讀取和寫入時，Service Fabric 非常有用。 通過 Service Fabric，可生成這些交互式有狀態應用程序，而無需創建無狀態應用所需的單獨存儲或緩存。 （這會增加延遲時間並可能產生一致性問題）。
- 數據分析和工作流：Service Fabric 的快速讀取和寫入使應用程序能夠可靠處理事件或數據流。 Service Fabric 還可讓應用程序描述處理管道，其中的結果必須能夠可靠地傳遞到下一個處理階段而不會丟失。 這包括交易和財務系統，其中的數據一致性和計算保證至關重要。
- 數據收集、處理和 IoT：由於 Service Fabric 處理大規模數據並通過其有狀態服務實現低延遲，因此它非常適合於設備的數據和計算共存的數百萬台設備上的數據處理。 我們已看到多個客戶使用 Service Fabric（包括 BMW、Schneider Electric 和 Mesh Systems）構建 IoT 系統。
應用程序設計案例研究
介紹如何使用 Service Fabric 設計應用程序的大量案例研究已發布在 Service Fabric 團隊博客和微服務解決方案站點上。
設計由無狀態和有狀態微服務組成的應用程序
構建使用 Azure 雲服務輔助角色的應用程序是無狀態服務的一個示例。 相比之下，有狀態微服務不僅維護請求及其響應，還維護其權威狀態。 在副本支持下提供交易保證的簡單 API，從而提供狀態的高可用性和一致性。 Service Fabric 的有狀態服務使高可用性變得大眾化，將其引入所有類型的應用程序，而不僅僅是數據庫和其他數據存儲。 這是一種自然的進步。 為實現高可用性，應用程序已從使用單純的關系數據庫發展到 NoSQL 數據庫。 現在，應用程序可在自身內部管理其“熱”狀態和數據，以便進一步提高性能，而無需損失可靠性、一致性或可用性。
生成包含微服務的應用程序時，通常有一個無狀態 Web 應用（ASP.NET 和 Node.js 等）組合調用應用於無狀態和有狀態業務中間層服務，這些服務使用 Service Fabric 部署命令全部部署到了同一 Service Fabric 群集中。 在規模、可靠性和資源使用情況方面，每種這些服務都是獨立的，從而大大提高了開發和生命周期管理的靈活性。
有狀態微服務可簡化應用程序設計，因為它們不再需要傳統上需要用來處理純無狀態應用程序的可用性和延遲需求的附加隊列和緩存。 由於有狀態服務原本就具有高可用性和低延遲，這意味着在應用程序中要作為一個整體進行管理的移動部件更少。 下圖說明了設計有狀態應用程序與無狀態應用程序之間的差異。 通過利用 Reliable Services 和 Reliable Actors 編程模型，有狀態服務降低了應用程序的復雜性，同時實現了高吞吐量和低延遲。
使用無狀態服務生成的應用程序
使用無狀態服務的應用程序
無狀態服務(Stateless Service)說起，這個是目前大多數應用采用的方式。比如這個圖是一個很典型的三層結構：前端，中間層和存儲層，此外通常還會加個緩存層。前端和中間層都是無狀態的，就是說其中不保存數據，可以比較容易地增加或減少節點。存儲層是有狀態的，需要特別留意數據安全性和一致性。由於前端過來的請求可能由於網絡或者硬件故障而丟失，就需要使用隊列來增強可靠性。如果訪問數據速度是瓶頸，還需要增加緩存層，緩存層也是有狀態的，所以緩存本身以及緩存和存儲層的數據一致性也需要很小心。
使用有狀態服務生成的應用程序
有狀態服務(Stateful Service)采用另一種思路，把數據與處理它的程序部署在一起，如下圖里面，把存儲層的數據進行分片后移到中間層，每片數據對應自己的一套處理程序。每片數據有奇數個副本，由SF來保證這些副本之間的數據的可靠性和一致性。好處就是，首先數據處理程序只需要關心本地數據，邏輯大大簡化；其次數據的傳輸變少了，性能可以得到很大改善；而且系統架構變簡單了，不需要在存儲層、緩存層、隊列等地方分別管理可靠性和一致性，只在SF一個地方管理。
參考：https://www.zhihu.com/question/268819708/answer/343732457