初创公司技术困境：弹性部署与详尽测试

作为一家初创公司，构建软件要僵持创新，要有吸引力和竞争力。由于，市场在不绝变革，新的需求也在不绝呈现。

从软件角度来说，要保持这样的上风就意味着必需尽也许缩随笔档和开拓阶段所占的时刻。虽然，保持软件的弹性也很重要，提供优越的处事是 Algolia 的重要方针之一。我们有很多高端用户，搜刮成果对营业有很是重要的影响，以是不能接管宕机时刻，尤其是在玄色礼拜五之类的非凡时刻段。

因此，开拓者 必需在软件的弹性与创新之间找到吻合的均衡点。 这两方面是彼此管束的：要让软件具有弹性，就要举办细致的测试，这会耗损大量精神，占用我们举办创新的时刻。因此，一个较量好的折衷方案就是在出产情形举办测试。

在出产情形举办测试就是把新代码宣布到出产情形中，直接用真实的出产数据和流量举办“测试”的进程。与之形成比拟的就是运行全面的测试用例集。这个风险很大，开拓者的第一向觉必定不要这么做。但跟着软件局限的成长，你会发明举办细致的测试越来越不行能了。

让我们看看 Algolia 引擎。我们有二十多个查询参数。假设它们满是 Boolean 范例，那么要运行的用例总数就会到达一百万个，二十个参数，每个有两个也许值，那就是 2^20 种也许的场景。

谈到与测试相干的事变所要耗损的时刻，有三方面要思量：

• 写测试用例的时刻
• 维护测试用例的时刻
• 运行测试用例的时刻

写出一百万个测试用例来，这个事变量已经很惊人了。一旦写出来，它们就成了项目内容的一部门。就像维护此外源代码一样，也要花精神去维护它们，以是每次软件迭代所要做的工作就更多了。

假设你的团队足够大，有富裕的人力可以编写和维护这些测试用例，但运行它们一样必要不少时刻。假设运行每个测试用例只必要 10 毫秒，那全运行一遍就必要 2 小时 45 分钟。不管代码中有什么更新，都必要花 2 小时 45 分钟才气验证完。

客户购置我们的产物不止是看中了当前已经具备的成果，更是看中了将来将会宣布的成果。他们但愿我们可以按期宣布新成果，辅佐他们生长，变得更轻易创新和更具有弹性。因此，我们必需晋升本身的服从。

在开拓新成果时，我们只会写些简朴的用例来验证成果，并对明明的界线前提举办测试。要对成果举办全面验证，我们会采纳灰度宣布的方法，直接在出产情形中举办测试。这样纵然代码中有缺陷，也可以把对客户的影响节制得只管小。通过这样的要领，我们就可以定时宣布新成果了。

以我们最近重写的一个 Algolia 的焦点成果做具编制子。假如要对它举办充实测试，就要用全部也许的 Unicode 字符（高出一百万个）对这二十几个参数组合成的一百万个用例举办测试。这样算起来总数会高出十亿次。假设运行一个测试要用 10 毫秒，那完玉成部测试内容就要 11 天。

我们不得不探求更好的办理方案。因此我们放弃了这十亿次测试。不能由于这件事而明显地拖慢我们的宣布流程，我们抉择在出产情形举办测试。

我们最大的记挂就是也许对用户造成的影响，因此我们界说了要把它陈设出去所必必要做的事：

• 一个渐进式的宣布流程
• 一种在好的基本办法之长举办重试的要领
• 起劲主动的题目检测

全部通过我们的网站发往 Algolia 的哀求，最终都是由一个集群来提供处事的，集群由三个节点构成。每个节点中都包括 100% 的数据，可以独立相应哀求，因此可以提供结实的陈设方案。假设平凡的处事器均匀可用率为 95%，那这种方案可以提供 99.987% 的可用性。只有当全部处事器所有宕机的时辰，你的处事才会真的宕机。以是这种也许性是 5% x 5% x 5%，即也许会有 0.0125% 的宕机时刻。

但纵然是在这样的架构下，软件的缺陷如故也许造成处事间断。因此，我们采纳了渐进式的灰度宣布方案。新的软件所有宣布完成必要三天的时刻。这样的陈计划策给了我们足够的时刻来发明题目。

其它尚有一点很重要的，就是我们的客户端 API 会回收重试的计策。若是它正好把哀求发往了一个有题目的节点，那么在哀求失败之后，它会自动探求另一个节点举办重试，直到取得乐成的相应为止。因此最终用户对这个题目是没有感知的。

在我们陈设新版本的高亮成果时，曾经产生过一个尺度化题目。我们的方针是把全部文本都转化成尺度化的名目，这样就可以利便地对差异的输入举办比拟。一样平常来说，尺度化后的内容长度不会比输入的原文更长，这也是高亮成果的条件。功效，我们却发明有些字符在尺度化之后长度会增进：字母ß（德语）就会被尺度化成了“ss”。在重写的时辰，我们增进了运行时前置前提搜查，以确保尺度化后的长度比原本长度更小，可能相称。这段代码施展了浸染，把这个题目袒暴露来了。

当我们把新版本代码陈设到第一个节点上时，对付那些尺度化之后长度会增进的哀求，它顿时就遏制了相应。好在我们的客户端 API 有重试的成果，以是客户没有受到影响，没有效户留意到这一点。而在靠山，我们的监控体系则发出了告警，以是我们顿时对宣布举办了回滚，以保持整个集群的不变。通过这种步伐，我们为本身争取到了足够的时刻来领略题目和完成代码修复，并举办响应的测试。

假如你也想在出产情形举办测试的话，有三个至关重要的条件前提：

• 可复制的基本办法；
• 弹性的软件；
• 安详的陈计划策；
• 可复制的基本办法

在此刻这个期间，设置一套可复制的基本办法长短常轻易的：全部云处事商都可以在多个假造机的前面提供负载平衡。就我们公司的架构来说，我们在整个集群的级别复制搜刮引擎的数据，每个节点都 100% 地拥有全量数据。通过这种方法，每个节点都可以独立完成对哀求的相应。

这一部门就要看你是奈何构建软件的了。在 Algolia 引擎的代码中，有很多关于康健状态的搜查，会校验函数的前置前提是否满意，以及是否处于祈望的状态等。当运行到非正常的状态时，引擎就会遏制处理赏罚，以停止返回有题目的数据。它会逼迫 API 客户端在此外节点上透明地举办重试。

这一点被最后提到，但它也一样很是重要。这里提到的陈计划策的首要方针，就是要在慢慢宣布新版本软件的进程同时，留意节制风险。

Algolia 的基本办法首要包罗四个情形：测试情形、准出产情形、出产情形和安详情形。每个情形都有差异的 SLA：

（编辑：河北网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!