努力实现无状态

发布：2018-07-21 17:02:56 浏览：3201

设计和实现无状态系统。适用于设计新系统或重新设计已有系统时。尽可能选择无状态实现。如果出于业务需求，合理地实了状态。实现状态会限制可扩展性，增大成本。在任何系统中，都要抵制对状态的需要。使用业务指标和多元(或AB)测试，判断应用中的状态是否真的实现了用户预期的行为和业务价值。

当应用发展到用一台服务器已经不能处理产品的需求时，我们的感受会相当矛盾，既兴奋又沮丧。兴奋是因为我们的业务增长了，沮丧是因为我们要迎来开发的新时代，需要采用新技术扩展系统。根据实现，我们有时可以依赖集群化的软件复制状态或会话进行扩展，但这种方法只能拖延系统达到极限的时间，如果我们的业务持续以指数级发展，或者只是呈线性发展，迟早都会达到这种极限。如果你的公司经营得很成功，那么即使是成本很高的会话同步方法也会很快不能满足它的发展需求。你很快就会发现自己在许多应用服务器的内存中复制了太多信息，很可能需要进行Y轴或Z轴的划分了。

我们的许多客户通常都不进行这类划分，而是依靠负载均衡器维护的关联性处理会话和状态的需求。一旦用户登录了，或启动了应用服务器池专用的某个流程，负载均均衡器就会维持与该应用服务器的关联性，直到功能(就Y轴划分而言，是由不同的池提供不同的功能)或会话(就Z轴划分而言，客户被划分入不同的池中)完成为止。对于许多发展放慢了的产品，或客户对可用性的需求不那么强烈的产品，这种方法足够了。

以前，维护关联性意味着相当高的成本。当几个大的或长期运行的会话定到很少几台服务器上时，容量计划就会变得非常麻烦；当为某些用户运行的应用服务器出故障时，这些用户的可用性会受影响。虽然可以依靠会话复制创造另一台主机，在系统出现故障时迁入其中，但如前所述，这种方法要复制内存消耗和系统容量，因此成本很高。

最后，为超高速发展的客户提供的最好解决方案还是尽量不使用状态。我们更愿意从“为什么你需要它”这个问题着手，开始讨论状态这个主题。我们的客户则常常会大吃一惊，典型的反应是:“通常不都如此吗，我们需要知道刚刚发生了什么，然后才能决定下一步做什么。”如果用收益、增加的交易量等数据来说明状态的功效，他们常常会不知所措。但是，的确有些解决方案可能需要状态，如实施工作流的状态机的解决方案。更常见的情况是，状态是种奢侈品，而且成本很高。

永远不要低估了应用中“简单且容易”这个原则的力量，它是对付“昂贵和复杂”的有效武器。Craigslist用一个大型的基于文本的无状态应用，在本地分类广告的竞争中战胜了eBay，虽然eBay总是尽可能地保持应用无状态，有一个含许多重要功能，并且比竞争对手Craigslist早出现很多年的颇具竞争力的分类广告产品。在本地分类广告的竞争中简单胜出。不相信吗?Google在搜索市场又是如何应对对手的呢?在其他人都致力于开发丰富的界面时，Google最初建立的理念就是:你的最后一个搜索结果才是最重要的，并且你真正想要的就是最好的搜索结果。没有状态，没有会话，非常实际。

关键就在于，会话和状态都是需要花钱的，只有通过AB测试或多元分析确定它们在关键的操作指标上显示出了具有竞争性的优势时，才应该实现它们。会话(和状态)需要内存，这就意味着编编码复杂度更大了，而运行交易的时间也会稍有加长。这会减少每台服务器每秒可以处理的交易量，从而增加需要的服务器的数量。考虑到容纳状态所需的内存，那么所需的系统可能会更大或更贵。可能需要开发“状态群”(本章后面会介绍)，这就意味着更多的设备。当然，更多的设备意味着需要更多的空间、电力和冷却设备，在虚拟化世界中，还需要支付更多的云资源。记住，对每台服务器(或虚拟机)，我们都需要支付相当于它的成本多倍的钱，因为需要给它提供空间、提供制冷系统以及提供电力。即使采用云资源，成本也是一样的，它们只是打包提供给了我们。

最好的就是总是对任何应用或网站制作服务中的状态需求提出疑问。要与“开发无状态应用”一起着重强调本原则。要搞清楚的是，状态分发(把状态转移到浏览器上，或分布式状态服务器上或缓存中)不同于无状态。