设计和实现无状况体系。实用于设计新体系或从新设计已有体系时。尽可能选择无状况实现。假如出于营业需求，合理地实了状况。实近况态会限制可扩大性，增年夜成本。在任何体系中，都要抵制对状况的须要。应用营业指标和多元(或AB)测试，断定运用中的状况是否真的实现了用户预期的行动和营业价值。

当运用成长到用一台办事器已经不克不及处置产物的需求时，我们的感触感染会相当抵触，既高兴又沮丧。高兴是因为我们的营业增加了，沮丧是因为我们要迎来开辟的新时期，须要采取新技巧扩大体系。依据实现，我们有时可以依附集群化的软件复制状况或会话进行扩大，但这种办法只能迁延体系到达极限的时光，假如我们的营业连续以指数级成长，或者只是呈线性成长，迟早都邑到达这种极限。假如你的公司经营得很胜利，那么即使是成本很高的会话同步办法也会很快不克不及知足它的成长需求。你很快就会发明本身在很多运用办事器的内存中复制了太多信息，很可能须要进行Y轴或Z轴的划分了。

我们的很多客户平日都不进行这类划分，而是依附负载平衡器保护的联系关系性处置会话和状况的需求。一旦用户登录了，或启动了运用办事器池专用的某个流程，负载均平衡器就会保持与该运用办事器的联系关系性，直到功效(就Y轴划分而言，是由分歧的池供给分歧的功效)或会话(就Z轴划分而言，客户被划分入分歧的池中)完成为止。对于很多成长放慢了的产物，或客户对可用性的需求不那么强烈的产物，这种办法足够了。

以前，保护联系关系性意味着相当高的成本。当几个年夜的或历久运行的会话定到很少几台办事器上时，容量筹划就会变得异常麻烦；当为某些用户运行的运用办事器出故障时，这些用户的可用性会受影响。固然可以依附会话复制发明另一台主机，在体系涌现故障时迁入个中，但如前所述，这种办法要复制内存消费和体系容量，是以成本很高。

最后，为超高速成长的客户供给的最好解决计划照样尽量不应用状况。我们更愿意从“为什么你须要它”这个问题着手，开端评论辩论状况这个主题。我们的客户则经常会年夜吃一惊，典范的反响是:“平日不都如斯吗，我们须要知道方才产生了什么，然后能力决议下一步做什么。”假如用收益、增长的生意业务量等数据来解释状况的功能，他们经常会不知所措。然则，切实其实有些解决计划可能须要状况，如实行工作流的状况机的解决计划。更常见的情形是，状况是种奢靡品，并且成本很高。

永远不要低估了运用中“简略且轻易”这个原则的力气，它是对于“昂贵和庞杂”的有用兵器。Craigslist用一个年夜型的基于文本的无状况运用，在当地分类告白的竞争中克服了eBay，固然eBay老是尽可能地坚持运用无状况，有一个含很多主要功效，而且比竞争敌手Craigslist早涌现许多年的颇具竞争力的分类告白产物。在当地分类告白的竞争中简略胜出。不信任吗?Google在搜刮市场又是若何应对敌手的呢?在其他人都致力于开辟丰硕的界面时，Google最初树立的理念就是:你的最后一个搜刮成果才是最主要的，而且你真正想要的就是最好的搜刮成果。没有状况，没有会话，异常现实。

症结就在于，会话和状况都是须要花钱的，只有经由过程AB测试或多元剖析肯定它们在症结的操作指标上显示出了具有竞争性的优势时，才应当实现它们。会话(和状况)须要内存，这就意味着编编码庞杂度更年夜了，而运行生意业务的时光也会稍有加长。这会削减每台办事器每秒可以处置的生意业务量，从而增长须要的办事器的数目。斟酌到容纳状况所需的内存，那么所需的体系可能会更年夜或更贵。可能须要开辟“状况群”(本章后面会介绍)，这就意味着更多的装备。当然，更多的装备意味着须要更多的空间、电力和冷却装备，在虚拟化世界中，还须要付出更多的云资本。记住，对每台办事器(或虚拟机)，我们都须要付出相当于它的成本多倍的钱，因为须要给它供给空间、供给制冷体系以及供给电力。即使采取云资本，成本也是一样的，它们只是打包供给给了我们。

最好的就是老是对任何运用或网站制造办事中的状况需求提出疑问。要与“开辟无状况运用”一路侧重强调来源根基则。要搞清晰的是，状况分发(把状况转移到阅读器上，或散布式状况办事器上或缓存中)分歧于无状况。