勤奋实现无状况

设计和实现无状况零碎。合用于设计新零碎或从头设计已有零碎时。尽能够选择无状况实现。若是出于营业需求，合理地实了状况。实近况态会限定可扩展性，增大本钱。在任何零碎中，都要抵制对状况的需求。运用营业指标和多元(或ab)测试，判断应用中的状况是否真的实现了用户预期的举动和营业代价。
当应用发展到用一台服务器曾经不克不及处置商品的需求时，咱们的感触感染会至关抵牾，既兴奋又懊丧。兴奋是由于咱们的营业增进了，懊丧是由于咱们要迎来开发的新时代，需求采用新手艺扩展零碎。按照实现，咱们有时可以依赖集群化的软件复制状况或会话进行扩展，但这类要领只能迁延零碎到达极限的时间，若是咱们的营业连续以指数级发展，或者只是呈线性发展，早晚城市到达这类极限。若是你的公司经营得很胜利，那末即便是本钱很高的会话同步要领也会很快不克不及知足它的发展需求。你很快就会发现本身在许多应用服务器的内存中复制了太多信息，很能够需求进行y轴或z轴的划分了。
咱们的许多客户常规都不进行这类划分，而是寄托负载平衡器维护的联系关系性处置会话和状况的需求。一旦用户登陆了，或启动了应用服务器池专用的某个流程，负载均平衡器就会维持与该应用服务器的联系关系性，直到功用(就y轴划分而言，是由差别的池提供差别的功用)或会话(就z轴划分而言，客户被划分入差别的池中)完成为止。对于许高发展放慢了的商品，或客户对可用性的需求不那末猛烈的商品，这类要领足够了。

之前，维护联系关系性象征着至关高的本钱。当多少大的或恒久运转的会话定到很少几台服务器上时，容量计划就会变得十分贫苦；当为某些用户运转的应用服务器出故障时，这些用户的可用性会受影响。尽管可以寄托会话复制缔造另外一台主机，在零碎泛起故障时迁入此中，但如前所述，这类要领要复制内存耗费和零碎容量，因而本钱很高。
末了，为超高速发展的客户提供的最佳解决计划仍是尽可能不运用状况。咱们更愿意从“为甚么你需求它”这个问题着手，起头接头状况这个主题。咱们的客户则经常会大吃一惊，典型的反馈是:“常规不都云云吗，咱们需求知道刚刚产生了甚么，而后才气决议下一步做甚么。”若是用收益、添加的买卖量等数据来讲明状况的成果，他们经常会手足无措。可是，确实有些解决计划能够需求状况，照施行事情流的状况机的解决计划。更常见的情况是，状况是种豪侈品，而且本钱很高。
永远不要低估了应用中“简略且容易”这个准则的力气，它是对于“高贵和庞大”的有用武器。 craigslist用一个大型的基于文本的无状况应用，在当地分类广告的竞争中战胜了ebay，尽管ebay老是尽能够地连结应用无状况，有一个含许多首要功用，而且比竞争敌手 craigslist早泛起不少年的颇具竞争力的分类广告商品。在当地分类广告的竞争中简略胜出。不信赖吗? google在搜索市场又是怎样应答敌手的呢?在其别人都致力于开发丰硕的界面时， google最初建立的理念就是:你的末了一个搜索后果才是最首要的，而且你真正想要的就是最佳的搜索后果。没有状况，没有会话，十分理论。
关键就在于，会话和状况都是需求费钱的，只要经由过程ab测试或多元阐明确定它们在关键的操纵指标上显示出了具备竞争性的劣势时，才应该实现它们。会话(和状况)需求内存，这就象征着编编码庞大度更大了，而运转买卖的时间也会稍有加长。这会削减每台服务器每秒可以处置的买卖量，从而添加需求的服务器的数目。思索到容纳状况所需的内存，那末所需的零碎能够会更大或更贵。能够需求开发“状况群”(本章后面会引见)，这就象征着更多的设备。当然，更多的设备象征着需求更多的空间、电力和冷却设备，在虚拟化世界中，还需求领取更多的云。记住，对每台服务器(或虚机)，咱们都需求领取至关于它的本钱多倍的钱，由于需求给它提供空间、提供制冷零碎以及提供电力。即便采用云，本钱也是同样的，它们只是打包提供应了咱们。
最佳的就是老是对任何应用或网站建设服务中的状况需求提出疑难。要与“开发无状况应用”一块儿着重强调本准则。要搞分明的是，状况分发(把状况转移到阅读器上，或散布式状况服务器上或缓存中)差别于无状况。