Netflix的高可用架构建议

Netflix 技术博客给开发者提了 10 条高可用架构的建议，这些都是工程师们从实战中总结出来的经验与技巧，且具有通用性，具体如下。

1. 优先考虑区域部署而不是全球部署

我们的目标是尽可能提供最佳的客户体验。因此，要限制系统变更的影响范围，对变更进行验证，然后将变更推给客户。此外，在每个区域部署之间对应用程序功能进行验证，并避免在目标区域的高峰时段进行部署。

2. 使用红黑部署策略进行生产部署

在红黑部署中，新版本的应用程序，也就是红色版本在通过健康检查之后立即开始接收流量。在确定红色版本的健康状态之后，之前的黑色版本将被禁用，并且不会收到任何流量。如果要回滚，只需要启用以前的版本即可。这种模型可以加快我们的部署流程，并可以在出现问题时回滚到之前的状态。

3. 使用部署窗口

每当你在部署新版本应用时，都要记住以下两点：第一，你或你的同事是否有监控部署，并在必要时进行补救？第二，如果出现了问题，你是否能够尽可能减小影响范围？

我们的流媒体流量遵循相对可预测的模式，大多数人会在晚上打开视频流，所以，建议你选择工作时段和非高峰时段的部署窗口。

4. 确保不要在非工作时段或周末自动触发部署

部署窗口也适用于自动触发的事件。无论你使用哪一种自动化机制，都要确保任何自动触发的管道都可以在无人值守的模式下运行。

5. 在将代码推送到生产环境之前使用各种测试和金丝雀分析来验证代码

实现快速部署的关键是在部署之前自动验证新版本的软件。理想情况下，所有必要的测试套件都应该在没有人工干预的情况下运行。另外，建议使用金丝雀分析。金丝雀分析是一种通过实时流量来验证服务变更的有效方法。

6. 在部署时尽可能只用已经测试过的东西

既然你已经对新版本进行了大量的测试和验证，那么，建议你在进行生产环境部署时只用测试过的东西，而不是再重新构建一套新的东西。

7. 定期检查联系人设置

有时候，为了确保应用程序的可用性，你需要定期检查你的联系人设置，这样可以确保在发生事故时能够迅速找到解决问题的人。

8. 知道如何快速回滚部署

即使有可靠的测试、金丝雀和其他验证过程，将某些东西部署到生产环境中仍然会出现问题。也许这是一种由竞态条件导致的罕见错误，只会在达到一定规模时才发生。但无论是何种情况，最重要的是你要知道在必要时如何快速恢复到之前正常的状态。

9. 如果实例运行不正常，将部署视为失败

有时候我们在部署成功后感觉状态不对，实例起来了，但不能正常处理流量。当一个关键的服务运行不正常时，请求很快会堆积起来，有时会导致重试雪崩，造成各种各样的破坏。因此，当实例运行不正常时，要将部署视为失败。

10. 自动化非典型部署，而不是进行一次性手动部署

每个工程师都为非典型情况编写过一次性脚本。而当这类“一次性”情况再次发生时，团队的其他成员并不知道写脚本的那位工程师在脚本里都做了什么，因为脚本本来是打算运行一次就丢掉的。因此，别忘了定期测试非关键场景的非典型和典型部署管道。管道是自动执行一系列步骤的有效手段，即使有些步骤并不会每天都执行。

除此以外，建议你尽可能使用自动化，但在必要的时候也需要人工干预。在进行自动部署时，也最好通知团队有关部署的情况，让他们密切关注服务的健康状况。还有一点是，使用先决条件验证预期状态，来确保在部署新代码或进行其他变更时假设仍然有效。