你有沒有想過在程序的世界里，狀態(tài)是怎么樣被定義和描述的？
在這篇文章中你將了解到服務狀態(tài)的定義，有狀態(tài)和無狀態(tài)的轉(zhuǎn)化和應用實踐場景。
如何理解狀態(tài)
我們簡明扼要，為狀態(tài)賦個定義
狀態(tài)指服務的運行結(jié)果，以及服務相互依賴產(chǎn)生的上下文。
提到狀態(tài)，都會想到 HTTP 協(xié)議，HTTP 協(xié)議特點之一是無狀態(tài)。
HTTP 中的無狀態(tài)理解為單次 HTTP 請求響應 可以獨立完成，每次請求不需要與上次請求有太多的關(guān)聯(lián)和牽扯。
無狀態(tài)的應用實踐
在應用程序開發(fā)中，最基本的關(guān)于狀態(tài)的應用實踐就是 【用戶信息】的保存和維護。
我們要理解：任何的應用程序都是要處理業(yè)務的。
我們以用戶狀態(tài)的流轉(zhuǎn)為例來說明。
誰在處理業(yè)務，當然是系統(tǒng)的用戶，所以用戶在處理業(yè)務過程中的狀態(tài)是需要被完整的，延續(xù)的保存。例如多頁面跳轉(zhuǎn)，企業(yè)內(nèi)部多系統(tǒng)切換過程。
從系統(tǒng)層面來說，需要類似 SSO 或者通行證 Passport 這樣的系統(tǒng)維護用戶的狀態(tài)，從技術(shù)概念來講，需要 Cookie Session 和 Token 來記錄完成。
狀態(tài)的底層邏輯是數(shù)據(jù)存儲
狀態(tài)的底層邏輯是數(shù)據(jù)存儲，應用程序的底層邏輯是業(yè)務邏輯。 從這個角度來說 無狀態(tài)就是實現(xiàn)業(yè)務邏輯和數(shù)據(jù)存儲的分離。
因此 服務無狀態(tài)的實現(xiàn)要依賴于第三方的數(shù)據(jù)存儲。
數(shù)據(jù)存儲主要涉及到關(guān)系型 數(shù)據(jù)庫，Redis，Zookeepker，文件存儲，消息隊列 等第三方中間件。
而編程的本質(zhì)是實現(xiàn)控制和邏輯分離和接耦，無狀態(tài)是實現(xiàn)數(shù)據(jù)和程序的分離，這兩個一起理解，有沒有異曲同工之妙？參看我之前關(guān)于關(guān)注點分離的文章
服務無狀態(tài)的優(yōu)勢
當請求壓力來臨的時候，應用服務器可以不顧慮數(shù)據(jù)存儲的情況下，在程序維度輕松實現(xiàn)水平擴展。
說白話就是說加機器可以扛流量
有狀態(tài)的應用實踐
上文提出狀態(tài)的底層邏輯是數(shù)據(jù)存儲，那么有狀態(tài)的應用的底層邏輯 就是數(shù)據(jù)存儲和服務工程粘連耦合。
單體應用，和傳統(tǒng)的單個項目發(fā)布部署都是采用的這么模式。有幾個特點，你不妨對應一下，是否存在。
系統(tǒng)中有個導出文件功能，文件會存儲到項目工程的指定目錄下，每次讀取都從這里下載。
多個服務共同訪問服務器上某個文件，實現(xiàn)權(quán)限的控制和記錄。
訪問日志按用戶編號存儲，只在應用程序指定目錄下保存一份。
因為服務和文件都在同樣的節(jié)點下，在訪問和處理時，不會涉及到網(wǎng)絡開銷。
而這些服務需要擴展和調(diào)整時，對應的文件就會成為累贅和負擔。
拓展
業(yè)界很流行的微服務架構(gòu)中，實現(xiàn)微服務有四大步驟，其中有一點就是服務的無狀態(tài)。
從架構(gòu)設(shè)計層面，可以把系統(tǒng)分為有狀態(tài)部分和無狀態(tài)部分
服務是無狀態(tài)化的，而業(yè)務必定是有狀態(tài)的，所以一個應用系統(tǒng)必定可以分為有狀態(tài)部分和無狀態(tài)部分。 這也是一種架構(gòu)切割方案。
之所以是無狀態(tài)化的，是因為有狀態(tài)部分被轉(zhuǎn)移來，這就要靠中間件了。
合適的就是最好的
服務的無狀態(tài)演化升級是實現(xiàn)分布式架構(gòu)和微服務的充分不必要條件。
現(xiàn)實開發(fā)中，并不是所有的公司都能撐得起服務的完全無狀態(tài)，然而這并不影響我們趨向于無狀態(tài)化的設(shè)計我們的系統(tǒng)。
指導思想不會變，服務無狀態(tài)，業(yè)務有狀態(tài)。
還是那句話合適的就是最好的。
希望這篇文章可以在狀態(tài)的認知上，幫助到你，歡迎留言評論。
