大家好，我是砸锅。一个摸鱼八年的后端开发。熟悉 Go、Lua。今天和大家一起学习分布式技术😊
开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 21 天，点击查看活动详情
扩容
为什么需要扩容
熔断和限流都是降级的一种特殊情况，而扩容则是一种动态的思维模式。当系统过载了，就增加资源让系统重新恢复正常，这是一种无损的系统过载恢复手段
因为扩容需要更多的资源来应对系统过载，也就是需要更多的钱。拥有扩容机制后，在一些流量突增场景，会先投入一定资源对系统进行扩容，来应对系统的过载问题。如果扩容之后无法解决过载问题，再通过熔断、限流和降级等有损机制
如何实现扩容
一般情况下是通过监控来捕捉系统的过载服务和程度，然后才进行扩容。自动扩容流程如下：
过载判断
可以依据请求在队列中的平均等待时间来计算服务的负载，例如一个服务 1 分钟内的平均等待时间超过 3 秒，就认为该服务进入过载状态。这种方案可以自适应硬件和服务的迭代变化，但是需要入侵到每个服务的实现逻辑里，每个服务都需要在实现的时候暴露接口请求的排队时间
另一个判断服务过载的方案是将服务和节点绑定，一个节点只运行一个服务，如果节点的系统指标过载则表示该服务出现过载。K8S 的 Pod 是一个比较好的方案，例如判断 CPU 的使用率、内存的使用率
自动扩容
对于容器层面来说，扩容有两个维度。一个是水平扩容，即通过增加服务的实例数量对系统进行扩容；一个是垂直扩容，通过升级服务部署节点的资源对系统扩容。在 K8S 里 Horizontal Pod Autoscaler（ HPA ）对应水平扩展，Vertical Pod Autoscaler（ VPA ）对应垂直扩展
HPA
VPA
水平扩容不受单机硬件影响，可以优先考虑。但是对于有状态的服务，水平扩容的时候涉及数据迁移，如果对数据迁移支持不好，则可以考虑垂直扩容。当进行容器层面的扩容时，如果集群的资源不足或者比较空闲，则会通过 Cluster Autoscaler 对机器节点层面进行扩缩容
可观测性
为什么需要监控
- 从规则角度，监控信息是扩容、缩容和报警等规则的数据来源
- 从全局角度，基于监控信息才能构建监控大盘，监控大盘可以帮助我们快速了解当前系统情况
- 从长期角度，通过监控信息来分析系统的长期趋势，例如系统当前磁盘的使用情况和增长速率
- 从实时角度，当系统出现变更时，可以通过监控了解最新的变更是否异常
- 从调试角度，当系统出现报警信息时，通过监控系统可以快速定位问题
监控和可观测性的关系
可观测性是指系统可以由其外部输出，来推断内部状态的程度，系统的可观测性越强，对系统的可控制性就越强
监控主要体现在结果，例如 CPU 超过 80%，机器宕机等直观的现象。对于一个可观测系统来说，除了这些直观的信息，还可以看到导致这些结果的原因，性能问题的瓶颈在哪，请求执行过程经过哪些服务，失败原因之类的
IT 建设中，可观测性能力可以分为 5 个层次：
无论是否告警，运用主要发现能力，对系统的运行情况进行诊断，通过指标呈现系统运行的实时状态。一旦发现异常，进行性能分析，调取详细信息，深入洞察
可观测性系统的开源组件
搭建一个可观测性平台，主要通过对日志、链路、指标这三类数据进行采集、计算和展示：
日志信息（Logs），记录处理的离散事件。通过 ELK 来处理日志数据
追踪链路（Traces），处理请求范围内的信息，可以绑定到系统中，单个事务对象的生命周期的任何数据。主要通过分布式调用链跟踪系统 Jaeger 来处理
指标信息（Metrics），作为可聚合性数据，通常是一段时间内可度量的数据指标，透过这个信息来观察系统的状态和趋势。主要通过 Prometheus 进行采集和存储，然后再用 Grafana 进行展示
OpenTelemetry 可以将 Logs、Traces、Metrics 三种数据实现互通
监控系统的四个黄金指标
- 延迟，指的是服务处理某个请求所需要的时间
- 流量，用来度量系统负载的，对于接口来说就是请求的 QPS，对于音视频处理来说，就是并发数或者网络 I/O 速率
- 错误，请求失败的速率
- 饱和度，当前系统的负载占满载的百分比
分位值是指将所有数值从小到大排序，然后取前面 n% 位置的值，就是该分位的值
告警系统的评价指标
告警系统的作用是将线上已经出现的、即将出现的故障及时通知，所以要确保所有的通知都是有效、需要立即处理的，并且不漏报，所有的故障或者即将出现的故障都要有告警通知。以及所有通知对象都应该是处理这个问题的最佳人选
此文章为2月Day17学习笔记，内容来源于极客时间《深入浅出分布式技术原理》
