高可用系統4大原則之一：無狀態服務vs有狀態服務

本文內容較多，分為如下部分

• 無狀態服務和有狀態服務定義

• 無狀態服務應用場景

• 有狀態服務應用場景

• 有無狀態倆種服務的架構質量對比

• 實現有狀態服務的挑戰

• 有狀態服務重構成無狀態服務

警告：任何情況下都優先考慮使用無狀態服務，即使你閱讀本文，包括以后寫的有狀態服務實現模式后。

高可用4大原則我自認為分別是 端到端[1]，有狀態vs無狀態[2]，可觀測，萬一，其他微服務框架，容器化我認為是次要的。

分布式系統里，節點服務包含了業務處理和數據倆部分， 如果數據是從持久化系統加載，則認為是此節點是狀態的。 如果數據常駐于節點內，業務邏輯是從外部加載進來的，則認為是有狀態節點。

state_definition

絕大多數系統都是無狀態服務，服務不需要在服務本地（JVM）記錄同一個客戶端（如用戶，設備，或者其他作為客戶端的服務等）請求的的歷史狀態或者記錄客戶端的信息，服務需要的這些數據將從數據庫或者Redis，MongDB加載。這些服務類似如下

• 登錄服務，服務節點根據請求用戶名，從數據庫查詢用戶名和HASH后的密碼，然后判斷請求的密碼是否與數據庫查詢的密碼一致

• 搜索服務 ，服務節點會把查詢條件轉為ElasticSearch查詢JSON，請求Elastic Search查詢結果。

• 電商中庫存查詢，服務節點會根據商品SKU以及查詢所在的地區，查詢存放在Redis的庫存信息。同時庫存服務節點也會請求商品查詢服務查詢商品的名稱和價格等信息。

• 物聯網中查詢家庭設備的狀態，服務節點會查詢倆個Redis，一個是緩存設備信息的Redis，一個設備在離線狀態的Redis

無狀態服務的技術實現非常成熟，如果你的服務是無狀態，僅僅需要增加節點既可實現系統高可用和高性能。 如下圖，代理服務采用輪詢（Round Robin）或則隨機，對于客戶端C，每個服務節點都能提供服務。如果需要擴容，簡單增加服務節點4即可。

state_stateless

需要注意的是，隨著流量增加，而服務節點增加，導致代理服務和數據庫本身可能是高可用高性能的瓶頸。因此代理服務和數據庫節點也應該支持擴展節點

無狀態服務的主要優點

優點

實現簡單

像編寫CURD代碼那樣簡單

擴容簡單

增加節點即可，代理服務可以使用輪詢，隨機等路由技術實現。

與無狀態是服務對應的是有狀態服務，要求服務端記錄同一個客戶端的交互歷史數據和狀態數據，有狀態服務通常從外部加載執邏輯而不是數據。比如

• 用戶前端流程表單在最終提交前保留在服務端的臨時表單數據

• 用戶登錄后的會話信息放在Session，Session信息存放在JMV內存里

• 物聯網的接入網關，需要記錄長鏈接到此網關的設備的版本信息。網關服務有可能加載規則腳本，規則引擎會根據設備上報的數據來執行特定的業務邏輯

• 游戲服務，一群用戶會被路由到特定的地圖服務器上協作完成游戲

• 通過互聯網協作編寫一份文檔

• 導航系統，用戶的信息和旅程信息都在一個服務器上。實時導航信息也在這一臺服務器上更新

• Zookeeper 內存中保持的有ZTree數據結構，它通過ZAB協議保持所有節點數據都一致。

• Redis 本身也是有個有狀態服務節點，它支持在內存存儲各種數據結構以及加載執行腳本。它通過從節點來實現高可用

有狀態需要客戶端始終連接到同一個服務節點（持久化連接），需要客戶端或者代理服務采取的路由策略保證同一個客戶任何請求都在同一個節點執行，比如來自同一個IP的用戶

state_statefull.png

有狀態服務的主要優點如下

優點

高性能

主要避免了從數據庫加載數據的延遲； 也避免了從持久化系統反復加載數據，比如節點1加載數據執行業務邏輯完畢后，當請求路由到節點2的時候，又會在節點2再次加載同樣數據

任意狀態數據結構

不再需要持久化系統保存狀態數據，其狀態不限制于JSON，表數據結構。

CAP

分布式常見的AP能得到滿足外，由于數據在同一個節點,其C也能滿足。需要注意，但是如果主節點宕機（或者客戶端認為C宕機路由到從節點），從節點接管，則C不成立。

避免使用性能不佳的數據庫

無狀態服務的擴容，也會導致其用的數據庫節點擴容。無狀態節點因為不需要數據庫，則省去了數據庫的使用成本，以及其導致的性能瓶頸

有狀態服務不難實現，但要達成高可用目標，則難得多。 下圖是一個通常有狀態服務高可用的部署架構。

state_statefull_slave

這個架構里，有非常多的技術挑戰性，列表如下。 這些挑戰是分布式系統高可用的深水區，后面章節簡述如何攻克這些挑戰。

難點

舉例

持久連接

代理服務采用何種策略讓客戶端保持持久連接到同一個節點，包括客戶端的每次請求，客戶端重啟，服務節點重啟，以及擴容縮容后通知客戶端重連新節點。如果沒有代理服務，則需要客戶端實現持久化連接

設備總是鏈接到同一個網關，游戲玩家總是鏈接到同一個區域服務器

復制

為節點增加一個從節點，數據從主節點備份到從節點。當節點宕機，，從節點接替主節點工作。從節點也可收接收只讀服務請求，緩解主節點負載

Redis主從數據復制，Zk的主從數據復制

讀寫一致

如果從節點提供讀服務，如何保證客戶端讀到最新寫到此分區的數據。

阿里云Redis可以配置只有主分片提供服務以避免讀寫不一致。

分區

把有狀態服務分成多個節點，解決有狀態服務的存儲瓶頸和訪問性能。

物聯網網關集群，Redis數據分片，數據庫分區，Kafka分區等

分區再平衡

在擴容時候，如果不差錢，每個分區都再次拆分2個分區，此分區數據只需要復制到倆分區。這種擴容成本極高但數據均勻。如果擴容時候是增加少量節點。則因為持久化連接緣故，新增節點負載長期都較低。擴容效果不能立即顯現出來。

阿里云的Redis擴容采用的是成倍增長，支持4,8,16....2048個分片。不支持增加少量分區

分布式共識

數據備份給多個節點，當主節點掛掉，采用那個節點的數據為主節點。另外，新當選的的主節點需要繼續同步數據到從節點

ZK通過ZAB實現分布式共識

集群管理

需要感知整個集群的節點狀態，其主從的工作狀態。代理服務需要獲取這些數據以實現路由

物聯網設備的主網關，Redis集群的代理

業務邏輯加載

如果有狀態服務的業務邏輯通過外部加載實現，如果管理這些業務邏輯

物聯網的規則鏈，通過配置其規則節點和執行邏輯實現設備在離線，屬性上報等執行邏輯。Reids作為有狀態節點，可以加載和執行Lua腳本

基于無狀態服務和有狀態服務各自的優缺點，下表總結了倆種服務的架構質量

架構特點

關注點

無狀態服務

有狀態服務

高可用

API網關

API網關可以實現各種負載均衡策略。如隨機，輪詢，負載

API網關實現較為復雜，需要識別客戶端，保證每次路由到同一個有狀態服務，依據信息可能是客戶端IP和端口，也可能是HTTP頭中包含的客戶ID

故障恢復

重啟服務即可恢復故障

有狀態服務重啟后，狀態丟失。需要重新建立這些狀態，如設備的版本信息，用戶的購物車。因此故障恢復較慢這些狀態需要從持久化系統加載，或者依賴客戶端重置狀態。

故障容錯

無狀態服務支持重試，當服務宕機，API網關可以將請求路由到另外其他服務。不存在單機故障

有狀態服務宕機，狀態丟失。需要在其他節點重建狀態，比如有狀態服務保持的有用戶登錄信息，當宕機后，用戶再訪問其他服務前，需要再次登錄。

高性能

啟動性能

無狀態服務不需要加載狀態，因此重啟后訪問較快。

有狀態服務，服務重啟后，需要初始化端狀態，訪問性能第一次較慢。重啟可能造成服務響應延遲

訪問性能

無狀態服務通常將狀態維護在Redis中，性能稍微慢一些，但考慮到Redis這些延遲都是毫秒級的，整體性能很高。如果狀態數據維護在傳統數據，則延遲較高

有狀態服務在JVM內存在保持狀態，訪問速度更快。如游戲地圖，所有玩家都在一個游戲地圖（JVM）里有狀態服務適合游戲，導航等場景。

可修改

易于修改

通常無狀態服務，不需要在JVM里維護狀態，實現更簡單，易于修改。

在JVM里維護的狀態，數據結構私有，難以修改，另外涉及到并發訪問，編寫代碼容易出錯

熱發布

無狀態服務可以采用任何熱發布技術，而沒有風險

有狀態服務，需要把狀態數據遷移到熱發布后的結構，難度較大

可伸縮性

節點擴容

集群環境，無狀態服務可以任意增加或者減少，無狀態服務擴容后，API網關可以通過負載均衡策略，讓負載少的這些擴容節點能很快達到滿負荷

容易造成單點過載。有狀態服務擴容后，由于持久化鏈接需要，至少少量請求能立即路由到新的節點。擴容后需要較長時間新老節點的容量才能達到一個均衡值。

既然無狀態服務有如此多的優點，除非有高性能要求，架構中應該優先使用無狀態服務，如果是有狀態的服務，需要改成無狀態服務，這里有4個辦法

• 有狀態服務的狀態數據存放在Redis等更為可靠的存儲介質。比如用戶Session，訂單，購物車等信息存放到redis，一些長期存在的數據存放到數據庫。 一些高可用基礎設施的改進采用了此方案，比如Kafka新一代方案 Diskless Kafka [3] 的實現AutoMQ ，消息本地存儲變成存儲到對象存儲服務里。 Nacos將配置數據放到Mysql數據庫中。

• 服務端的狀態每次都回傳給客戶端，客戶端下次調用攜帶這些狀態，比如JWT，Cookie

• 有狀態服務把有狀態部分單獨隔離出來，把其他部分放在無狀態服務里。

• 使用Zookeeper，數據庫等強一致工具來實現投票，元數據管理，二階段提交等，而無需自己實現

下圖是Spring Boot提供的Session實現方式，代替傳統的保存會話到內存，Spring Boot 配置spring.session.store-type

spring.session.store-type=Redis

配置后，存在內存中的的用戶會話數據將序列化后存放在redis中。

state_springsession

其他配置還允許使用數據庫,Hazelcast等 存儲系統。需要注意，必須確保存儲系統的高性能和高可用。在我的一個項目里，用此方案把有狀態服務改成無狀態服務，額外引入了一個512分片，容量是1024G的Redis集群以避免系統性能問題。

另外一種把有狀態服務改成無狀態服務的方法是服務器每次把狀態回傳給客戶端。適合用戶狀態數據較少情況。

state_request

交互過程如下

• 服務在接受客戶端請求后，將數據放回到Cookie中，如加密的用戶的信息，或者訂單信息

• 客戶端下次請求，服務端從Cookie中取出的狀態數據，處理請求后新的狀態數據再次保存到Cookie中

在還沒有無紙辦公時代，我在派出所辦理業務的時候，按照要求需要跑多次派出所和其他相關單位，派出所工作人員會把需要跑的單位記錄在一張紙上，每次交互后的結果和剩下需要辦的事情都有記錄，再次去派出所，其他工作人員即使沒有給我辦理過業務，也會讓我拿出這張紙查看，以了解我辦理的進度

第三種是在設計有狀態服務時候，拆分有狀態服務。這樣好處是讓大部分功能保持在無狀態服務里。

state_split

第四種方法與第三種類似，使用zookeeper來管理有狀態，相比于自己實現有狀態服務，zookeeper/etcd這些基礎中間件更為可靠。

有狀態服務的高可用涉技術實現包括大量內容，本書將用后續一節內容說明實現有狀態服務的高可用有哪些模式，再次警告，有狀態服務高可用實現難度較大。類似你正在實現一個Redis，Kafka這樣的中間件。你需要承擔為了性能引入的復雜性。

參考資料

端到端: https://my.oschina.net/u/567839/blog/19641027

有狀態vs無狀態: https://my.oschina.net/u/567839/blog/19658871

Diskless Kafka: https://www.toutiao.com/article/7580613850573636096/