狀態和無狀態－－2種服務器架構之間的比較 .

  對服務器程序來說，有兩個基本假設十分重要，究竟服務器是基於狀態請求還是無狀態請求。狀態化的判斷是指兩個來自相同發起者的請求在服務器端是否具備上下文關係。如果是狀態化請求，那麼服務器端一般都要保存請求的相關信息，每個請求可以默認地使用以前的請求信息。而無狀態請求則不行，服務器端所能夠處理的過程，他的處理信息必須全部來自於請求所攜帶的信息以及其他服務器端自身所保存的、並且可以被所有請求所使用的公共信息。
        無狀態的服務器程序，最著名的就是WEB服務器。每次HTTP請求和以前都沒有啥關係，只是獲取目標URI。得到目標內容之後，這次連接就被殺死，沒有任何痕跡。在後來的發展進程中，逐漸在無狀態化的過程中，加入狀態化的信息，比如COOKIE。服務端在響應客戶端的請求的時候，會向客戶端推送一個COOKIE，這個COOKIE記錄服務端上面的一些信息。客戶端在後續的請求中，可以攜帶這個COOKIE，服務端可以根據這個COOKIE判斷這個請求的上下文關係。COOKIE的存在，是無狀態化向狀態化的一個過渡手段，他通過外部擴展手段，COOKIE來維護上下文關係。
        狀態化的服務器有更廣闊的應用範圍，比如MSN、網絡遊戲等服務器。他在服務端維護每個連接的狀態信息，服務端在接收到每個連接的發送的請求時，可以從本地存儲的信息來重現上下文關係。這樣，客戶端可以很容易使用缺省的信息，服務端也可以很容易地進行狀態管理。比如說，當一個用戶登錄後，服務端可以根據用戶名獲取他的生日等先前的註冊信息；而且在後續的處理中，服務端也很容易找到這個用戶的歷史信息。
        狀態化服務器在功能實現方面具有更加強大的優勢，但由於他需要維護大量的信息和狀態，在性能方面要稍遜於無狀態服務器。無狀態服務器在處理簡單服務方面有優勢，但複雜功能方面有很多弊端，比如，用無狀態服務器來實現即時通訊服務器，將會是場惡夢。

        這些年，在金融軟件行業發展，對這些行業軟件的開發倍感古怪。原來是一家資訊公司，雖然是行業壟斷地位，但是他們的技術架構倒沒有什麼特別之處，只能說很一般。最近在一家交易軟件公司，也是行業壟斷地位，技術架構極其古怪，倒值得說道和探討。
        交易軟件的所有架構的理論基礎是基於無狀態假設，主要分爲3個層次：
        1、虛擬網絡。這是最底層的基於架構，在原有的TCP/IP網絡上構建了一個虛擬的TCP/UDP網絡，這個概念和VPN很像。但也有很多不同。比如虛擬網絡上的節點和節點所接入的實體是按數字化的標識來區別。
        2、業務中心。在虛擬網絡上，建立一個業務邏輯中心，管理所有的業務邏輯單元。這個中心本身不處理業務邏輯，而是一個業務邏輯的管理器。
        3、業務單元。這個組件是專門實現各個業務邏輯的單元。業務單元本身是建立在業務中心的基礎上。本身具有一定的獨立性，但主要功能還是被綁定在業務中心上。業務中心相當於他的容器。
        這3個層次之間消息傳輸都是無狀態的，當客戶端從虛擬網絡上發起一個請求之後，這個請求在整個傳輸過程中，都被認爲是攜帶了完整的信息。這樣的處理有個好處，允許傳輸層次進行負載均衡，自由路由，爲虛擬網絡的建設提供了很大的彈性。
        在業務中心和業務單元之間也是這樣的。他們之間的關係借鑑了MQ的架構。每個消息都是一個完整的、獨立的處理單位。這種架構由於耦合性低，所以實現難度比較低，錯誤發生的概率也改善很多。但從另外一方面來說，要獲取信息的難度卻加大了。比如一個業務邏輯想知道哪些客戶端在線，幾乎是不可能的事情。
        由於客戶端之間的狀態是不可知的。所以主動推送需要十分複雜的過程才能實現。不能簡單地做到主動推送，輪詢就成爲主要的手段。當輪詢被頻繁地使用之後，系統的實時性就無法保證了。

        當然，我在這裏不是爲了對狀態化和無狀態化的服務器要分個三六九等，實際上他們都有自己適用的範圍。但各個覺得，只要狀態化的服務器的技術風險能夠被克服，應該具備更廣闊的前景，應該是個未來的發展方向。從交易軟件的架構，我還是認爲他是個比較成功的應用，畢竟是得到事實的檢驗。但在具體過程中遇到的很多問題，還是和他的無狀態假設有關。感覺這種架構是將錯誤發生的時間和地點給延後了，而不是消滅。
        在這種系統中，狀態化依然是最好的架構，但是難度是同樣巨大。期待中...。努力實現他。