原文鏈接：http://highscalability.com/blog/2015/10/12/making-the-case-for-building-scalable-stateful-services-in-t.html

在很長一段時間內，分布式系統都采用無狀態服務作為分布式系統擴展的最佳實踐。它可以通過簡單的循環負載均衡來提供擴展能力。它的缺點則在于數據中心之間復雜的一致性問題。
這里有一篇關于有狀態服務（PPT）的分享。這篇分享介紹了基于Azure的Orleans開發Halo4的經驗。Orleans基于有狀態分布式的Actor模型，節點之間實現了高可用的Gossip協議，一個兩層的一致性哈希加上分布式哈希表。基于這些方案提供節點動態負載均衡，動態擴縮容，熱點平衡轉移等等。
下面簡單說一下如何使用有狀態服務：

無狀態服務帶來額外開銷

無狀態服務可以通過添加節點來實現線性可擴展能力的提升。問題在于，我們開發的應用場景是有狀態的，這意味著我們需要通過sharding或者NoSQL來實現擴容。這又喪失了關系型數據庫關于強一致性的保證。
對于單個用戶，經常需要把這個用戶的所有請求路由到同一臺服務器上，這樣可以通過本地數據緩存的措施來減少IO開銷。

集群信息：

靜態配置 配置一份包含所有集群信息的靜態文件分發到所有機器上，缺點在于不夠靈活，線上發生故障需要手動調整配置，不支持動態擴容縮容。

Gossip協議 ?穩定狀態下，系統中所有節點對于節點的健康狀態能夠達成共識，在發生網絡分區或者節點加入/離開時，可能會出現短暫的不一致情況。

共識算法 保證所有節點的一致性，缺點在于可能會是整個系統速度的瓶頸。

路由策略：

隨機路由 一般是根據機器的處理能力進行按處理能力的路由。

一致性哈希 問題在于可能會出現熱點問題，需要精心選擇哈希鍵。
3.分布式哈希表（DHT） 動態哈希表保存服務狀態。

三個例子：
Facebook的Scuba
一個高速的基于內存的分布式數據庫，使用了靜態成員信息配置，寫時采用隨機分發策略，讀取操作有中間件進行聚合返回，不保證可用。

Uber的Ringpop
Ringpop是一個實現了程序層級分片的node.js庫，采用了Swim Gossip協議維護集群信息，這個協議基于AP所以不保證強一致性，一致性哈希負責處理請求路由，所以有可能出現熱點問題。

微軟的Orleans
Orleans是一個基于分布式系統的Actor模型，Actor是計算的核心單元，彼此之間使用異步消息通信，它持有一系列狀態機所以本身是有狀態的，Gossip協議負責集群信息，路由策略是一致性哈希與分布式哈希表的結合：當向集群發送對Actor的請求時，Orleans運行時將計算對Actor ID的一致哈希。哈希映射到具有該ID的分布式哈希表的計算機；Actor的分布式哈希表知道哪個機器包含指定ID的Actor。

有狀態模型帶來的挑戰：
需要關注服務器內存狀況，緩存建設問題，第一次鏈接問題等等。

原文地址：https://www.jianshu.com/p/fdfca8f5d9ec

.NET社區新聞，深度好文，歡迎訪問公眾號文章匯總 http://www.csharpkit.com

總結

以上是生活随笔為你收集整理的构建可扩展的有状态服务的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。