本文包含一些常见模式，可帮助工程师处理数百万用户访问的大规模服务。
根据作者的经验，这并不是一个详尽的列表，但确实 有效 建议。 那么，让我们开始吧。
翻译有支持 .
入门级
下面列出的措施实施起来相对简单，但影响很大。 如果您以前没有尝试过它们，您会对它们的显着改进感到惊讶。
基础设施即代码
建议的第一部分是实施基础设施即代码。 这意味着您必须采用编程方式来部署整个基础设施。 听起来很复杂，但我们实际上讨论的是以下代码：
部署100个虚拟机
- 与Ubuntu
- 每个 2 GB RAM
- 他们将有以下代码
- 有了这些参数
您可以跟踪基础架构的更改并使用版本控制快速恢复它们。
我内心的现代主义者说你可以使用 Kubernetes/Docker 来完成上述所有工作，他是对的。
此外，您可以使用 Chef、Puppet 或 Terraform 提供自动化。
持续集成和交付
要创建可扩展的服务，为每个拉取请求建立一个构建和测试管道非常重要。 即使测试非常简单，它至少会确保您部署的代码可以编译。
每次在此阶段，您都回答以下问题： 我的程序集能编译并通过测试吗？它有效吗？ 这看起来似乎是一个很低的标准，但它解决了很多问题。
没有什么比看到这些蜱虫更美丽的了
对于这项技术，您可以评估 Github、CircleCI 或 Jenkins。
负载均衡器
因此，我们希望运行负载均衡器来重定向流量并确保所有节点上的负载相等，或者在发生故障时服务继续：
负载均衡器通常可以很好地分配流量。 最佳实践是保持平衡，这样就不会出现单点故障。
通常，负载均衡器是在您使用的云中配置的。
请求的 RayID、相关 ID 或 UUID
您是否遇到过应用程序错误并显示如下消息： “出了些问题。 保存此 ID 并将其发送给我们的支持团队”?
唯一标识符、相关 ID、RayID 或任何变体是允许您在请求的整个生命周期中跟踪请求的唯一标识符。 这允许您在日志中跟踪整个请求路径。
用户向系统A发出请求，然后A联系B，B联系C，将其存储在X中，然后将请求返回给A
如果您要远程连接到虚拟机并尝试跟踪请求路径（并手动关联正在进行的调用），您会发疯。 拥有唯一的标识符让生活变得更加轻松。 这是随着服务的发展可以节省时间的最简单的事情之一。
平均水平
这里的建议比前面的建议更复杂，但正确的工具可以使任务变得更容易，甚至为中小型公司提供投资回报。
集中记录
恭喜！ 您已部署 100 个虚拟机。 第二天，首席执行官过来抱怨他在测试服务时遇到的错误。 它会报告我们上面提到的相应 ID，但是您必须查看 100 台机器的日志才能找到导致崩溃的机器。 需要在明天的演示之前找到它。
虽然这听起来像是一次有趣的冒险，但最好确保您能够在一个地方搜索所有杂志。 我使用 ELK 堆栈的内置功能解决了集中日志的问题：它支持可搜索的日志收集。 这确实有助于解决寻找特定期刊的问题。 作为奖励，您可以创建图表和其他类似的有趣的东西。
ELK堆栈功能
监控代理
现在您的服务已启动并运行，您需要确保其顺利运行。 最好的方法是运行几个 代理商，它们并行工作并检查其是否正常工作以及是否执行了基本操作。
此时您检查一下 运行构建感觉良好并且工作正常.
对于中小型项目，我推荐使用 Postman 来监控和记录 API。 但一般来说，您只想确保有办法知道何时发生中断并及时收到通知。
根据负载自动缩放
这很简单。 如果您有虚拟机服务请求并且其内存使用率接近 80%，您可以增加其资源或向集群添加更多虚拟机。 自动执行这些操作非常适合负载下的弹性功率变化。 但您应该始终小心您花费的金额并设定合理的限额。
对于大多数云服务，您可以将其配置为使用更多服务器或更强大的服务器自动扩展。
实验系统
安全推出更新的一个好方法是能够为 1% 的用户测试某些内容一个小时。 当然，您已经看到了此类机制的运作。 例如，Facebook 向部分受众显示不同的颜色或更改字体大小，以了解用户如何看待这些变化。 这称为 A/B 测试。
即使发布一个新功能也可以从实验开始，然后确定如何发布。 您还可以根据导致服务质量下降的功能“记住”或动态更改配置。
先进水平
这里有一些很难实施的技巧。 您可能需要更多的资源，因此中小型公司将很难管理这一点。
蓝绿部署
这就是我所说的“Erlang”展开方式。 当电话公司出现时，Erlang 得到了广泛的使用。 软交换开始用于路由电话呼叫。 这些交换机上软件的主要目的是在系统升级期间不掉线。 Erlang 有一种很好的方法来加载新模块而不会使前一个模块崩溃。
此步骤取决于负载均衡器的存在。 假设您有软件的版本 N，然后您想要部署版本 N+1。
您 可能 只需停止服务并在适合您的用户的时间推出下一个版本并获得一些停机时间即可。 但假设你有 真 严格的 SLA 条件。 所以，SLA 99,99% 意味着你可以下线了 仅 每年增加 52 分钟。
如果真想达到这样的指标，需要同时进行两次部署：
- 现在的那个（N）；
- 下一个版本（N+1）。
您告诉负载均衡器将一定比例的流量重定向到新版本 (N+1)，同时主动监视回归。
这里我们有一个运行良好的绿色 N 部署。 我们正在尝试迁移到此部署的下一个版本
首先，我们发送一个非常小的测试，看看我们的 N+1 部署是否适用于少量流量：
最后，我们有一组自动检查，我们最终会运行这些检查，直到部署完成。 如果你 非常非常 小心，您还可以永久保存 N 部署，以便在出现不良回归时快速回滚：
如果您想达到更高级的水平，请让蓝绿部署中的所有内容自动运行。
异常检测和自动缓解
鉴于您拥有集中式日志记录和良好的日志收集，您已经可以设定更高的目标。 例如，主动预测故障。 在监视器和日志中跟踪功能，并构建各种图表 - 您可以提前预测会出现什么问题：
一旦检测到异常，您就开始检查服务提供的一些线索。 例如，CPU 负载的峰值可能表明硬盘发生故障，而请求的峰值可能表明您需要扩展。 这种统计数据可以让您主动提供服务。
借助这些见解，您可以在任何维度进行扩展，并主动和被动地改变机器、数据库、连接和其他资源的特征。
就是这样！
如果您正在开发云服务，那么这个优先级列表将为您避免很多问题。
原文章作者诚邀读者发表评论并进行修改。 本文作为开源、作者的拉取请求分发 .
关于该主题还可以阅读什么：
来源： habr.com