规则4——启用与禁用功能
内容：搭建一个框架来启用与禁用产品的功能。
场景：考虑使用上线和下线框架控制新研发的、非关键性的或者依赖第三方的功能。
用法：研发共享库以自动或基于请求的方式控制功能的启用与禁用，参见表9-5中的推荐。
原因：为了保护对最终用户很重要的关键功能，关闭有问题或非关键性的功能。
要点：当实施成本低于风险损失时，实现上线和下线框架。开发可以复用的共享库以降低未来实施的成本。
在讨论故障隔离设计方法时也提过它。最终这些类型的框架有助于确保系统可以优雅地出故障（在事件自诊断框架下）或在通过人为干预禁用某些功能的基础上继续提供服务。有时公司将类似的功能称为“功能切换”或“断路器”。
过去有几种方法可以控制功能的上线和下线，每种方法都有一定的优点与缺点。启用和禁用服务很可能取决于技术团队和运营团队的能力，以及出现问题的服务的业务关键性。表9-5涵盖了一些方法。
表9-5并不是启用和禁用功能的所有可能性的完整清单。事实上，许多公司融合了一些选项。他们可以在启动时从数据库读取参数或者文件，以控制应用代码显示或不显示某组功能。PayPal在第一次实现国际化时所实施的就是这样的一个例子。有些国家的银行或资金转移规定只允许一些有限的支付功能。根据用户使用网站的地理位置，他可能只看到主网站提供的功能中的一部分。
当考虑功能的上线／下线框架时，要解决的同等重要的问题是，在哪里和什么时候应该使用决策。显然，实施框架意味着额外的工作以及由此带来的额外业务成本。让我们以（不太可能而且可能不正确）某些永远都不会出故障的功能为起点。如果知道哪些功能永远不会出故障，我们将不想为这些功能实现此控制功能，因为这是没有回报的投入。以此为起点，我们就可以确定投资在哪里具有价值或能带来业务回报。使用率高（高吞吐量）并且其故障会影响网站上其他重要功能的任何功能是合适的选择。另一个选择是在给定版本中正在经历大幅修改的那些功能。选择这两类功能的想法是，实施上线/下线的成本小于给业务带来的风险（风险是失败概率和失败影响的函数）。如果开发这些功能花费额外1000美元的成本，该功能无法处理的故障可能造成1万美元的业务损失，这个成本投入划算吗？
如果处理得当，技术团队可以通过实现一组跨功能的共享库，降低实施上线/下线框架的成本。对新的开发，这种方法不会把实施框架的成本降低为零，但它确实有助于降低未来几代框架启用功能的成本。
我们建议实施上线/下线框架有几个重要的原因。首先，新功能或正在积极开发的功能很有可能有缺陷。有能力关闭有问题的功能非常有价值。其次，如果功能对所提供的服务不重要，有可能想要关闭非关键功能。当计算资源成为瓶颈时，也许存在内存泄漏，把应用送入垃圾回收过程，关闭非关键功能以保护更多关键功能是个很好的选择。第三，调用第三方服务经常要以同步方式进行。当供应商的API开始响应缓慢时，能够关闭功能可以防止它减缓整个应用或服务，是非常可取的。显然，我们不相信一切都应该能够启用/禁用或上线/下线。这种做法成本昂贵而且不建议的，但运转良好的团队应该能够发现风险，为实施合适的保障措施共享组件。
总结
我们相信可用性和可扩展性紧密相关。可用性不高的产品不需要扩展，因为用户过不了多久就不来了。无法扩展的网站不会有高可用性，因为网站会变慢，甚至完全停下来。因此不能顾此失彼。本章提供了四个规则，它们有助于确保网站保持高可用性以及持续扩展。不要因为专注于可扩展性而使你忘记可用性对客户多么重要。
