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

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



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

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

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

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

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