在我的上一篇文章中，我讨论了如何在您的基础设施中实施最佳实践。站点可靠性工程师 (SRE) 的首要职责是可靠性，执行有助于系统持续运行的策略至关重要。
分布式共识
随着微服务、容器和云原生架构的普及，如今几乎每个应用程序都将是分布式应用程序。分布式共识是驱动分布式系统的核心技术。
分布式共识是用于构建可靠分布式系统的协议。您不能依赖“心跳”（来自硬件或软件的信号，表明它们运行正常），因为网络故障是不可避免的。
在分布式系统方面，有一些固有的问题需要强调。硬件会发生故障。分布式系统中的节点可能会随机发生故障。
这是在设计分布式系统之前必须做出的重要假设之一。网络中断是不可避免的。您不能始终保证 100% 的网络连接。最后，您需要分布式系统中任何节点的一致视图。
根据 CAP 定理，分布式系统不能同时拥有以下所有三个属性
- 一致性： 每个节点的数据视图一致。这意味着从分布式系统中的 2 个不同节点查看时，您可能看不到相同的数据。
- 可用性： 指的是每个节点的数据可用性。
- 分区容错性： 指的是对网络故障（导致网络分区）的容错能力。
因此，节点需要具备这些品质才能正常运行。
多年来，在分布式共识领域开发了多种协议，包括 Paxos、Raft 和 Zab。
例如，Paxos 是分布式共识问题的最初解决方案之一。在 Paxos 算法中，分布式系统中的节点发送一系列带有唯一序列号的提议。当分布式系统中大多数进程接受该提议时，该提议获胜，并且发送者生成提交消息。这里的关键是大多数进程接受该提议。
提议的严格序列编号方式避免了数据重复，并解决了排序问题。
开源分布式共识
您不必通过编写自己的分布式共识代码来重新发明轮子。已经有很多开源实现可用，例如最流行的 Zookeeper。其他实现包括 Consul 和 etcd。
设计自动扩缩容
自动扩缩容是一个过程，通过该过程，服务器场中的服务器数量根据负载自动增加或减少。“服务器场”在这里用于指代分布式系统中的任何服务器池。这些服务器通常位于负载均衡器之后，如我的上一篇文章中所述。
自动扩缩容有很多好处，但以下是 4 个主要好处
- 通过仅运行所需的服务器来降低成本。例如，当负载相对较低时，您可以自动从池中删除服务器。
- 在低流量期间灵活运行对时间不太敏感的工作负载，这是自动减少服务器数量的另一种变体。
- 自动替换不健康的服务器（大多数云供应商都提供此功能）。
- 提高服务的可靠性和正常运行时间。
虽然有很多好处，但自动扩缩容也存在一些固有的问题
- 当您自动扩展服务器池时，依赖的后端服务器或服务可能会不堪重负。例如，您所依赖的服务，即您的应用程序连接到的远程服务，可能不知道您的服务的自动扩缩容活动。
- 软件错误可能会触发自动扩缩器突然扩展服务器场。这是一种可能在生产系统中发生的危险情况。例如，配置错误可能会导致自动扩缩器无法控制地启动新实例。
- 负载均衡可能不够智能，无法考虑新服务器。例如，新添加到池中的服务器通常需要一个预热期，然后才能真正接收来自负载均衡器的流量。当负载均衡器没有完全意识到这种情况时，它可能会在新服务器准备好之前就将其淹没。
自动扩缩容最佳实践
缩减比扩容更敏感和危险。您必须充分测试所有缩减场景。
确保后端系统（例如您的数据库、远程 Web 服务等）或您的应用程序依赖的任何外部系统都可以处理增加的负载。您可能会自动向池中添加新服务器以处理增加的负载，但您的应用程序依赖的远程服务可能不知道这一点。
您必须配置服务器数量的上限。这很重要。您不希望自动扩缩器无法控制地启动新实例。
拥有一个“终止开关”，您可以轻松地停止自动扩缩容过程。如果您遇到错误或配置错误导致自动扩缩器行为异常，您需要一种方法来停止它。
3 个协同工作的系统，实现成功的自动扩缩容
有三个系统需要考虑，以成功实施自动扩缩容
- 负载均衡： 负载均衡 的关键优势之一是通过将流量路由到离用户最近的位置来最大限度地减少延迟。
- 负载削减： 为了接受所有传入的请求，您只处理您可以处理的请求。丢弃多余的流量。负载削减系统的示例包括 Netflix Zuul 和 Envoy。
- 自动扩缩容： 根据负载，您的基础设施自动向上或向下扩展。
当您设计分布式应用程序时，请仔细考虑您的应用程序可能遇到的所有情况。您应该清楚地记录负载均衡、负载削减和自动扩缩容如何协同工作以处理所有情况。
实施有效的健康检查
负载均衡器的核心工作是将流量定向到一组后端服务器。负载均衡器需要知道哪些服务器是活跃且健康的，以便成功地将流量定向到它们。您可以使用健康检查来确定哪些服务器是健康的并且可以接收请求。
以下是您需要了解的有关有效健康检查的信息
- 简单： 监控后端服务器的可用性。
- 内容验证： 向后端服务器发送一个小请求并检查响应。例如，您可以查找特定的字符串或响应代码。
- 失败： 您的服务器可能已启动，但侦听特定 pod 的应用程序可能已关闭。或者 pod 可能正在侦听，但可能不接受新连接。健康检查必须足够智能，能够识别有问题的后端服务器。
具有复杂内容验证的健康检查会增加网络流量。在简单的健康检查（例如简单的 ping）和复杂的基于内容的健康检查之间找到平衡。
一般来说，对于 Web 应用程序，访问 Web 服务器的主页并查找正确的 HTML 响应可以作为合理的健康检查。可以使用 curl 命令 自动化这些类型的检查。
每当您对中断进行事后分析时，请查看您的健康检查策略，并确定您的负载均衡器将服务器标记为启动或关闭的速度有多快。这对于确定您的健康检查策略非常有用。
保持健康
保持基础设施健康需要时间和精力，但如果做得正确，它将是一个自动化过程，使您的系统平稳运行。SRE 的工作还有更多内容要讨论，但这些是我的下一篇文章的主题。
评论已关闭。