高可用性设计

如果您曾经乘过印度铁路旅行，您会注意到火车应该承载的容量没有意义，因为它将要承载的人数已经过去了。 这样便可以管理全国各地的客运量和平台。 该方法通常效果很好，但有时会出现故障，火车会延迟，有时会取消，但随着人们对印度铁路公司的期望，这种生活会继续下去。

当我们设计和编写那些大型平台/软件时，会发生类似的情况，但是最大的不同是，为软件付费的客户/客户不喜欢那些停机时间（取消）和延误（延迟）。 在过去的两年左右的时间里，我进行了如此多的对话，其中2个关键的NFR相交-性能和可用性。 我已经注意到并开始意识到，尽管这两个最终成为一体，需要密切合作，但它们仍然意味着世界的不同，当我们谈论性能和可用性时，这意味着什么，而每一个都需要解决不一样。

当然，最终，通过所有的修复程序，您将根除许多导致失败的案例，但是这花费了您很长时间，而且该品牌所拥有的宝贵声誉已经受到损害。

开始

当今世界，大多数项目（几乎所有项目）都有一些非功能性需求，而性能，可用性和安全性是最重要的三项。 一些最常见的数字是：

• 页面应在1秒内打开，依此类推
• 正常运行时间应为99.99％ ，实际上是每周1.01分钟

就是这样。 当然，还有更多，但是95％的对话围绕这里的两者进行。 然后我们开始设计解决方案以满足这些数字。

就在GO Live之前

当我们正在实施时，一切都很好，我们会尽一切努力确保我们满足两个或两个以上未经设计的要求。 我们进行性能建模，然后执行这些性能模型，并证明对于我们理解的客户用例的交通模型/模拟可以正常工作。 因此，这并不是我们有信心说我们的系统将满足性能需求。 在此模型中，我们确实将容量增加了40％左右； 再次基于模拟量和未来的增长，我们将这些数字纳入计算中，然后甚至可以确定，如果有时发生这种情况，我们的系统将能够处理更多的数据。

现在我们已经确定性能对于预期获得的流量来说都是好的，我们相信我们的软件应该可以继续正常运行，因为一切都将在我们测试软件的相同约束下进行。 而且由于这些约束条件定义明确，因此满足我们的可用性数字应该没有任何问题。

我们在休斯敦飞行

然后，下一个很酷的事情发生了–我们上线了，我们建立的系统充满了自豪和谨慎，并且我们测试了太多的Live，并开始有很多人使用它。 看到您的汗水和艰苦的工作上线，人们看到您所构建的东西并与之交互，这无疑是一种令人振奋的感觉。

直到系统出现故障为止。 您将在半夜睡觉，并且您会接到一个电话，并且有人会告诉您起床，打开笔记本电脑，并准备调试为什么系统停机并使其快速启动和运行。 您需要花一些时间思考–到底发生了什么。 我们做了我们必须做的一切。 甚至有我们做过的评论，一切都看起来不错。 它怎么会掉下去。

好吧，有一个名为Universe的东西为您提供了一套不同的计划，而这些计划才刚刚付诸实施。

那么会发生什么呢？

印度铁路发生了！ 您意识到，有一种流量模式突然来了，并击中了您不知道的服务器。 一个中文搜索引擎已经开始在您的整个网站上进行爬网，而该网站甚至不在中国。 好吧，这是一次免费的互联网之旅，任何人都可以继续前进。 为什么坐在一个国家/地区的某些人看不到不应以他们为目标的网站-但我们没有这些规范。 我们进行了所有检查，但从未想到所有这些搜索引擎和机器人以及它们将进行的爬网。

我们做什么？

我们解决了这个问题，并放了一个块来阻止该流量模式，或者我们限制它或添加服务器来处理它。 然后我们开始思考，现在我很好。 这是完成和灰尘，不会再次发生。

宇宙还有其他计划

下次有人将一些不良服务器添加到WIP中时，群集将失败。 下次有人删除数据库时，数据库将再次崩溃，下一个，下一个和下一个…

在整个软件开发过程中，我们错过了这一关键步骤–为该游戏进行设计，以及如何进行设置以使系统在该时间段内恢复正常运行。

修复开始

当然，我们必须做些什么，但是我们要做的是开始研究我们的解决方案并检查为什么性能不好。 性能–真的吗？ 我们会尽一切努力解决性能问题，但是我们不会在可用性方面花费任何时间。

回到印度铁路的比喻，我是事先绘制的。 一列火车–建造了引擎和柏忌来应对一定的负荷，他们对此表示同意。 由于有座位并且需要购票才能进入那列火车，所以这不可能更加精确。 只要进入的人数在这些限制之内，我们的问题就会少很多。 我们软件（我们的火车）周围的所有东西都需要协同工作。 但是，很难控制。 互联网比印度的铁路要宽得多，谁来了，何时来以及有多少来是无法预料的。 重要的是要认识到，无论您怎么做，总会有来来往往的流量模型来访问您，这会使您的系统超出已知范围，而一旦我们的系统在这些范围之外运行，这种情况就更常见了。一定会失败。 这是需要将可用性和弹性视图纳入其中的地方。

可用性和弹性

从他们的核心出发，这种观点要求您设定一些设计，实践，最重要的是与您的客户对所要处理的东西产生期望。 我们都知道，在过去十年中，我们的业务运营方式以及与Internet托管站点的交易方式与过去的系统制造方式截然不同。 我从文章中解释：“如果您的站点关闭，您的业务将遭受损失”，但是每个人都希望24×7的正常运行时间，但是我们卖出了NFR – 99.99（1.06分钟）或99.9999（0.605秒），认为还可以。 如果期望是24×7，那我们为什么还要从更少的东西开始呢？

然后，我们需要查看下两个最重要的指标，这些指标我们一直都没有，我们也从未计划，设计或测试。 就像我们认为它们是理所当然的。 这是恢复时间目标（RTO）和RPO（恢复点目标）。 在谈到正常运行时间和停机时，每当发生计划外停机并承诺一定的正常运行时间时，我们都需要具备操作能力，以执行使系统正常运行所需的一切工作。 如果我们为99.99％进行了设计，则需要有适当的方法来在1.06秒内恢复系统-感觉就像是赢得胜利的分钟 。 在整个软件开发过程中，我们错过了这一关键步骤–为该游戏进行设计，以及如何进行设置以使系统在该时间段内恢复正常运行。

操作视点

当构建软件系统和平台时， Operation Viewpoint是我们省略设计的关键架构原则。 在过去的十年中，随着云托管，我们现在运行软件的方式已完全改变。 随着云使事情变得如此容易配置和托管（AWS），我们相信一切都应该很容易。 因此，在过去我们经常着重于可用性设计的地方，我们几乎将其视为理所当然。 这个观点将在实施阶段成为我们的面包脂，由一支专门的团队来研究运营流程和工具，并提供在预期的时间内实现恢复的方法。

分类和优先级

在这里，与客户进行对话并了解如何识别系统的各个部分并将其分解为服务变得至关重要。 诸如“ Platinum”，“ Gold”，“ Bronze”之类的分类开始变得有意义，它可以使企业优先考虑在计划外中断的情况下应优先考虑的服务。 然后，运营设计和实施团队的重点需要集中在如何看待系统以及如何使这些服务快速启动和运行上。 这是实现阶段的关键输入，因为除非不知道这些服务，否则就不会有这样的编码方式。

恢复而不调试

当这些计划外的中断发生时，负责管理系统的团队通常会以不同的思维方式开始工作。 他们就像警察，在犯罪发生后到达犯罪现场。 他们从四处寻找证据并分析犯罪现场的发生情况。 这个想法是寻找证据，然后解决犯罪，希望然后找到罪犯并将其关押。 好吧，我们都知道到达那里需要很长时间。 有了警察，我明白了这一点–您不可能在所有家庭和任何地方都拥有相机，因此您需要进行验尸。 但这是一个软件系统，我们需要成为消防员。 这个想法必须是将火扑灭，并在火势消失之前Swift采取行动。 这个想法必须是要意识到已经造成了一些损害–那是一个丢失的原因； 让我们看看如何保存剩余的内容。

在我们编写的软件和托管的平台中，我们需要有一个被我称为“最后知道的良好状态”的东西，当发生中断时我们需要做的事情就是让我们自己回到那个状态。 但是，当状态或行为不受您控制时，我们应该何时做。 回到印度铁路，当您无法控制进站到火车上的人员的数量时，您会怎么做？ 不管您是否找到替换火车的方法，它们都会不断涌入。另一种方法当然是开始在平台上添加更多火车。 使用云，您可以做到这一点，并不断添加服务器，直到处理完所有流量为止。 这是我们无缝进入“ 性能和可伸缩性”角度的地方 。

这是我们看不到问题的地方，我们尝试修复现代软件中的其他问题。

因此，如果我们无法控制流量，该怎么办。 我们需要在火车上建立一种有效的机制，不允许所有人进入。我们需要有能力知道谁可以进入。我们在平台上拥有这些ID卡和Turnstil。 因此，如果我们的平台没有给我们提供这些服务，那为什么我们不能将它们放到我们的火车上。 它可能不会阻止所有恶意流量，但肯定会阻止很多恶意流量。 最重要的是，您可以返回并授权您的白金级用户进入，而您阻止其他所有人。

因此，在软件世界中，您需要具有一个转换开关，该开关将停止所有流量，仅允许业务关键。 除非大多数情况下不是白金卡，否则您将能够轻松地恢复最重要的服务。 当然，其他服务也会降级，但是您已经对客户和企业设定了期望。 他们会生气但不会生气。

300

如果您还没有看到300 ，则必须先看一下，并了解它对系统的作用，以及通过漏斗应对敌人（交通）的能力。 您将更长，并且您将有更多时间与敌人作战。 最重要的是，当铂金服务不可用时，企业所承受的压力和压力也将减少。 一旦包含就可以进行调试。

没有什么是免费的

当然，我们做得更多，但是做得越多，成本就越高。 回到印度铁路，我们可以选择不安装那些身份证旋转栅门来节省建造火车的钱，或者我们可以投资那笔钱并确保我们的连续性。 旋转栅门将越来越复杂，需要进行更多的微调才能处理所有情况。 因此，如果您还需要处理不希望您的旋转闸失灵的用例，那么您需要在所有的柏忌上安装其中的两个，这将花费更多，并且安装将继续进行。

我要说的是，当我们从99％升至99.99％到99.999％时，我们不会关注成本驱动因素及其对项目的影响。 我们可能会认为–这意味着需要进行几轮性能测试，我们应该这样做。 我们现在知道会发生什么。

如果您未能向客户说明这些数字对他们的成本意味着什么，那么您将永远不会使他们接受互联网和宇宙的现实。 很多时候，您会意识到企业将如何认识到他们所不能缺少的服务。 当然，最终，通过所有的修复程序，您将根除许多导致失败的案例，但是这花费了您很长时间，而且该品牌所拥有的宝贵声誉已经受到损害。 如果您认为这是“风险钱”，并且您如何投资以维护自己的声誉，那么每次都会证明这笔费用是合理的–我可以向您保证。

翻译自: https://www.javacodegeeks.com/2014/09/high-availability-design.html