有狀態服務器和無狀態服務器

• 對服務器程序來說，有兩個基本假設十分重要，究竟服務器是基於狀態請求還是無狀態請求。狀態化的判斷是指兩個來自相同發起者的請求在服務器端是否具備上下文關系。如果是狀態化請求，那麽服務器端一般都要保存請求的相關信息，每個請求可以默認地使用以前的請求信息。而無狀態請求則不行，服務器端所能夠處理的過程，他的處理信息必須全部來自於請求所攜帶的信息以及其他服務器端自身所保存的、並且可以被所有請求所使用的公共信息。

為什麽要做無狀態化

• 很多應用拆分成微服務，是為了承載高並發，往往一個進程扛不住這麽大的量，因而需要拆分成多組進程，每組進程承載特定的工作，根據並發的壓力用多個副本公共承擔流量。
• 將一個進程變成多組進程，每組進程多個副本，需要程序的修改支撐這種分布式的架構，如果架構不支持，僅僅在資源層創建多個副本是解決不了問題的。
• 阻礙單體架構變為分布式架構的關鍵點就在於狀態的處理。如果狀態全部保存在本地，無論是本地的內存，還是本地的硬盤，都會給架構的橫向擴展帶來瓶頸。
• 狀態分為分發、處理、存儲幾個過程，如果對於一個用戶的所有的信息都保存在一個進程中，則從分發階段，就必須將這個用戶分發到這個進程，否則無法對這個用戶進行處理，然而當一個進程壓力很大的時候，根本無法擴容，新啟動的進程根本無法處理那些保存在原來進程的用戶的數據，不能分擔壓力。
• 所以要講整個架構分成兩個部分，無狀態部分和有狀態部分，而業務邏輯的部分往往作為無狀態的部分，而將狀態保存在有狀態的中間件中，如緩存、數據庫、對象存儲、大數據平臺、消息隊列等
  。
• 這樣無狀態的部分可以很容易的橫向擴展，在用戶分發的時候，可以很容易分發到新的進程進行處理，而狀態保存到後端。而後端的中間件是有狀態的，這些中間件設計之初，就考慮了擴容的時候，狀態的遷移，復制，同步等機制，不用業務層關心。
• 

容器和狀態

• 容器和微服務是雙胞胎，因為微服務會將單體應用拆分成很多小的應用，因而運維和持續集成會工作量變大，而容器技術能很好的解決這個問題。然而在微服務化之前，建議先進行容器化，在容器化之前，建議先無狀態化，當整個流程容器化了，以後的微服務拆分才會水到渠成。

無狀態化的幾個要點

• 
• 對於數據的存儲，主要包含幾類數據：
  • 會話數據等，主要保存在內存中。
    • 對於保存在內存裏的數據，例如Session，可以放在外部統一的緩存中。
  • 結構化數據，主要是業務邏輯相關
    • 對於業務相關的數據，則應該保存在統一的數據庫中
  • 文件圖片數據，比較大，往往通過CDN下發
    • 對於文件，照片之類的數據，應該存放在統一的對象存儲裏面，通過CDN進行預加載
  • 非結構化數據，例如文本、評論等
    • 對於非結構化數據，可以存在在統一的搜索引擎裏面，例如ElasticSearch。
• 而所有的外部統一存儲，無論是緩存、數據庫、對象存儲、搜索引擎、都有自身的分布式橫向擴展機制。
• 

有狀態和無狀態服務