設計和實現無狀態(tài)系統。適用于設計新系統或重新設計已有系統時。盡可能選擇無狀態(tài)實現。如果出于業(yè)務需求，合理地實了狀態(tài)。實現狀態(tài)會限制可擴展性，增大成本。在任何系統中，都要抵制對狀態(tài)的需要。使用業(yè)務指標和多元(或AB)測試，判斷應用中的狀態(tài)是否真的實現了用戶預期的行為和業(yè)務價值。

當應用發(fā)展到用一臺服務器已經不能處理產品的需求時，我們的感受會相當矛盾，既興奮又沮喪。興奮是因為我們的業(yè)務增長了，沮喪是因為我們要迎來開發(fā)的新時代，需要采用新技術擴展系統。根據實現，我們有時可以依賴集群化的軟件復制狀態(tài)或會話進行擴展，但這種方法只能拖延系統達到極限的時間，如果我們的業(yè)務持續(xù)以指數級發(fā)展，或者只是呈線性發(fā)展，遲早都會達到這種極限。如果你的公司經營得很成功，那么即使是成本很高的會話同步方法也會很快不能滿足它的發(fā)展需求。你很快就會發(fā)現自己在許多應用服務器的內存中復制了太多信息，很可能需要進行Y軸或Z軸的劃分了。



我們的許多客戶通常都不進行這類劃分，而是依靠負載均衡器維護的關聯性處理會話和狀態(tài)的需求。一旦用戶登錄了，或啟動了應用服務器池專用的某個流程，負載均均衡器就會維持與該應用服務器的關聯性，直到功能(就Y軸劃分而言，是由不同的池提供不同的功能)或會話(就Z軸劃分而言，客戶被劃分入不同的池中)完成為止。對于許多發(fā)展放慢了的產品，或客戶對可用性的需求不那么強烈的產品，這種方法足夠了。
 
以前，維護關聯性意味著相當高的成本。當幾個大的或長期運行的會話定到很少幾臺服務器上時，容量計劃就會變得非常麻煩；當為某些用戶運行的應用服務器出故障時，這些用戶的可用性會受影響。雖然可以依靠會話復制創(chuàng)造另一臺主機，在系統出現故障時遷入其中，但如前所述，這種方法要復制內存消耗和系統容量，因此成本很高。

最后，為超高速發(fā)展的客戶提供的最好解決方案還是盡量不使用狀態(tài)。我們更愿意從“為什么你需要它”這個問題著手，開始討論狀態(tài)這個主題。我們的客戶則常常會大吃一驚，典型的反應是:“通常不都如此嗎，我們需要知道剛剛發(fā)生了什么，然后才能決定下一步做什么。”如果用收益、增加的交易量等數據來說明狀態(tài)的功效，他們常常會不知所措。但是，的確有些解決方案可能需要狀態(tài)，如實施工作流的狀態(tài)機的解決方案。更常見的情況是，狀態(tài)是種奢侈品，而且成本很高。

永遠不要低估了應用中“簡單且容易”這個原則的力量，它是對付“昂貴和復雜”的有效武器。 Craigslist用一個大型的基于文本的無狀態(tài)應用，在本地分類廣告的競爭中戰(zhàn)勝了eBay，雖然eBay總是盡可能地保持應用無狀態(tài)，有一個含許多重要功能，并且比競爭對手 Craigslist早出現很多年的頗具競爭力的分類廣告產品。在本地分類廣告的競爭中簡單勝出。不相信嗎? Google在搜索市場又是如何應對對手的呢?在其他人都致力于開發(fā)豐富的界面時， Google最初建立的理念就是:你的最后一個搜索結果才是最重要的，并且你真正想要的就是最好的搜索結果。沒有狀態(tài)，沒有會話，非常實際。

關鍵就在于，會話和狀態(tài)都是需要花錢的，只有通過AB測試或多元分析確定它們在關鍵的操作指標上顯示出了具有競爭性的優(yōu)勢時，才應該實現它們。會話(和狀態(tài))需要內存，這就意味著編編碼復雜度更大了，而運行交易的時間也會稍有加長。這會減少每臺服務器每秒可以處理的交易量，從而增加需要的服務器的數量?？紤]到容納狀態(tài)所需的內存，那么所需的系統可能會更大或更貴?？赡苄枰_發(fā)“狀態(tài)群”(本章后面會介紹)，這就意味著更多的設備。當然，更多的設備意味著需要更多的空間、電力和冷卻設備，在虛擬化世界中，還需要支付更多的云資源。記住，對每臺服務器(或虛擬機)，我們都需要支付相當于它的成本多倍的錢，因為需要給它提供空間、提供制冷系統以及提供電力。即使采用云資源，成本也是一樣的，它們只是打包提供給了我們。

最好的就是總是對任何應用或網站制作服務中的狀態(tài)需求提出疑問。要與“開發(fā)無狀態(tài)應用”一起著重強調本原則。要搞清楚的是，狀態(tài)分發(fā)(把狀態(tài)轉移到瀏覽器上，或分布式狀態(tài)服務器上或緩存中)不同于無狀態(tài)。