共计 10317 个字符，预计需要花费 26 分钟才能阅读完成。
导语 | 故障是开发者高频关注的问题。在分布式系统建设的过程中，咱们思考的重点不是防止故障，而是拥抱故障，通过构建高可用架构体系来取得优雅应答故障的能力。本文作者冯煦亮从架构、工具链、可观测三个维度，介绍了 QQ 音乐多年来积攒的高可用架构实际。冀望对你有帮忙。
QQ 音乐高可用架构体系全景
故障无处不在，而且无奈防止。在分布式系统建设的过程中，咱们思考的重点不是防止故障，而是拥抱故障，通过构建高可用架构体系来取得优雅应答故障的能力。QQ 音乐高可用架构体系蕴含三个子系统：架构、工具链和可观测性。
架构：架构包含冗余架构、主动故障转移和稳定性策略。高可用架构的根底是通过冗余架构来防止单点故障。其中，基础设施的冗余包含集群部署、多机房部署，多核心部署等；软件架构上要反对横向扩大、负载平衡和主动故障转移。这样零碎就具备了根底的容灾容错能力。在冗余架构的根底之上，能够通过一系列稳定性策略来进一步晋升架构的可用性。稳定性策略包含分布式限流，熔断，动静超时等。
工具链：工具链指一套可相互集成和合作的工具，从外围对架构进行试验和测试以达到晋升架构可用性的目标，包含混沌工程和全链路压测等。混沌工程通过注入故障的形式，来发现零碎的软弱环节并针对性地加固，帮忙咱们晋升零碎的可用性。全链路压测通过实在、高效的压测，来帮忙业务实现性能测试工作，进行容量评估和瓶颈定位，保障系统稳固。
可观测性：通过观测零碎的具体运行状态来晋升零碎的可用性，包含日志、指标、全链路跟踪、性能剖析和 panic 剖析。可观测性能够用于服务生命周期的所有阶段，包含服务开发，测试，公布，线上运行，混沌工程，全链路压测等各种场景。
容灾架构
业内支流的容灾计划，包含异地冷备，同城双活，两地三核心，异地双活 / 多活等。
异地冷备 ：冷备核心不工作，老本节约，关键时刻不敢切换。 同城双活 ：同城依然存在很多故障因素(如自然灾害) 导致整体不可用。异地双活 / 多活：双写 / 多写对数据一致性是个极大挑战。有些做法是按用户 ID 哈希，使用户跟数据中心绑定，防止写抵触问题，但这样一来舍弃了就近接入的准则，而且劫难产生时要手动调度流量，也无奈做到 API 粒度的容灾。
容灾架构的选型咱们须要掂量投入产出比，不要为了预防哪些极低概率的危险事件而去投入过大的老本，毕竟业务的规模和支出才是重中之重。QQ 音乐的外围体验是听歌以及围绕听歌的一系列行为，这部分业务以只读服务为主。而写容灾须要反对双写，带来的数据一致性危险较大，且有肯定的施行老本。综合衡量，咱们舍弃写容灾，采纳一写 双读的异地双活 模式。
1）异地双核心
在原有深圳核心的根底上，建设上海核心，笼罩接入层、逻辑层和存储层，造成异地双核心。
接入层：深圳核心和上海核心各部署一套 STGW 和 API 网关。通过 GSLB 把流量按就近准则划分为两份，调配给深圳核心和上海核心，深圳核心和上海核心做流量隔离。
逻辑层：服务做读写拆散。深圳部署读 / 写服务，上海部署只读服务，上海的写申请由 API 网关路由到深圳核心解决。
存储层：深圳核心和上海核心各有一套存储。写服务从深圳写入存储，通过同步核心 / 存储组件同步到上海，同步核心 / 存储组件确保两地数据的一致性。同步形式有两种，对于有建设异地同步能力的组件 Cmongo 和 CKV+，依赖存储组件的异地同步能力，其余不具备异地同步能力的，如 ckv，tssd 等老存储，应用同步核心进行同步。
2）主动故障转移
异地容灾反对主动故障转移才有意义。如果劫难产生后，咱们在劫难发现、劫难响应以及评估迁徙危险下面节约大量工夫，劫难可能曾经复原。
咱们最后的计划是，客户端对两地接入 IP 进行动静评分（申请胜利加分，申请失败减分），取最优的 IP 接入来达到容灾的成果。通过近两年多的外网实际，遇到一些问题，动静评分算法敏感度高会导致流量在两地频繁漂移，算法敏感度低起不了容灾成果。而算法调优依赖客户端版本更新也导致老本很高。
起初咱们基于异地自适应重试对容灾计划做了优化，核心思想是在 API 网关上做故障转移，升高客户端参与度。
计划次要有两点：
第一点，API 网关故障转移：当本地核心 API 返回失败时（包含触发熔断和限流），API 网关把申请路由到异地解决。以此解决 API 故障的场景。
第二点，客户端故障转移：当 API 网关产生超时的时候，客户单进行异地重试。如果网关有回包，即便 API 返回失败，客户端也不重试。解决 API 网关故障的场景。
应用最新计划后，API 网关重试比客户端调度更可控，双核心流量绝对稳固，一系列自适应限流和熔断策略也对消重试带来的申请量放大问题。接下来介绍计划细节。
3）API 网关故障转移
API 网关故障转移须要思考重试流量不能压垮异地，否则会造成双核心同时雪崩。这里咱们做了一个自适应重试的计划，在异地成功率降落的时候，勾销重试。
自适应重试计划：
引入重试窗口：如果以后周期窗口为 10，则最多只能重试 10 次，超过的局部抛弃。
网关申请服务失败，判断重试窗口是否耗光。如果耗光则不重试，如果还有余额，重试异地。
上述计划中的重试窗口，由 探测及退却策略 决定：探测策略 ：当探测成功率失常时，增大下一次窗口并持续探测。通过管制窗口大小，防止重试流量霎时把异地打垮。 退却策略 ：在探测成功率出现异常时，重试窗口疾速退却。 减少重试开关，管制整体及服务两个维度的重试。
探测策略及退却策略图示：
探测策略及退却策略的算法形容：
// 设第 i 次探测的窗口为 f(i)，理论探测量为 g(i)，第 i 次探测的成功率为 s(i)，第 i 次本地总申请数为 t。// 那么第 i+1 次探测的窗口为 f(i+1)，取值如下：if s(i) = [98%, 100%] // 第 i 次探测成功率 >= 98%，探测失常
if g(i) >= f(i) // 如果第 i 次理论探测量等于以后窗口，增大第 i+1 次窗口大小
f(i+1) = f(i) + max (min ( 1% * t, f(i) ) , 1)
else
f(i+1) = f(i) // 如果第 i 次理论探测量小于以后窗口，第 i+1 次探测窗口维持不变
else
f(i+1) = max(1,f(i)/2) // 如果第 i 次探测异样，第 i+1 次窗口退却置 1
// 其中，重试窗口即 f(i) 初始大小为 1。算法中参数及细节，依据理论测试和线上成果进行调整。自适应重试成果：
4）客户端故障转移
当客户端未收到响应时，阐明 API 网关异样或者网络不通，客户端重试异地。当客户端收到响应，而 http 状态码为 5xx，阐明 API 网关异样，客户端重试异地。当 http 状态码失常，阐明 API 网关失常，此时即便 API 失败也不重试。
当双核心均超时，探测网络是否失常，如果网络失常，阐明两地 API 网关均异样，所有客户端申请解冻一段时间。
稳定性策略
1）分布式限流
即便咱们在容量布局上投入大量精力，依据教训充分考虑各种申请起源，评估出正当的申请峰值，并在生产环境中筹备好足够的设施。但预期外的突发流量总会呈现，对咱们布局的容量造成微小冲击，极其状况下甚至会导致雪崩。咱们对容量布局的后果须要坚守不信赖准则，做好进攻式架构。
限流能够帮忙咱们应答突发流量，咱们有几个抉择：
第一，固定窗口计算器 长处是简略，但存在临界场景无奈限流的状况。第二，漏桶 是通过排队来管制消费者的速率，适宜刹时突发流量的场景，面对恒定流量上涨的场景，排队中的申请容易超时饿死。第三，令牌桶 容许肯定的突发流量通过，如果上游（callee）解决不了会有危险。第四，滑动窗口计数器 能够绝对精确地实现限流。
咱们采纳的是 滑动窗口计数器，次要思考以下几点：
第一点，超过限度后微服务框架间接抛弃申请。第二点，对原有架构不引入要害依赖，用分布式限流的形式代替全局限流。
上图形容 ServceA 到 ServiceB 之间的 RPC 调用过程中的限流：
Sidecar 用于接管微服务的信令管制，限流器则以插件的形式集成到 Sidecar。限流器通过限流核心 Agent，从限流核心获取限流后果数据。ServiceA 发动申请到 ServiceB 前，通过 Sidecar 的限流器判断是否超出限度，如果超出，则进入降级逻辑。限流核心采纳滑动窗口的形式，计算每个 Service 的限流数据。
限流算法的抉择，还有一种可行的计划是，框架提供不同的限流组件，业务方依据业务场景来抉择，但也要思考老本。社区也有 Sentinel 等成熟解决方案，新业务能够思考集成现成的计划。
2）自适应限流
上一节的分布式限流是在 Client-side 限度流量，即申请量超出阈值后在主调间接抛弃申请，被调不须要承当拒绝请求的资源开销，可最大水平爱护被调。然而，Client-side 限度流量强依赖主调接入分布式限流，这一点比拟难齐全受控。同时，分布式限流在集群扩缩容后须要及时更新限流阈值，而全量微服务接入有肯定的保护老本。而且分布式限流间接抛弃申请更偏刚性。作为分布式限流的互补能力，自适应限流是在 Server-side 对入口流量进行管制，主动嗅探负载、入口 QPS、申请耗时等指标，让零碎的入口 QPS 和负载达到一个均衡，确保零碎以高水位 QPS 失常运行，而且不须要人工保护限流阈值。相比分布式限流，自适应限流更偏柔性。
指标阐明：
算法原理：依据 Little’s Law，inflight = 延时 QPS。则最优 inflight 为 MaxPass MinRt，当零碎以后 inflight 超过最优 inflight，执行限流动作。用公式示意为：cpu > 800 AND InFlight > (MaxQPS * MinRt)。其中 MaxQPS 和 MinRt 的估算须要减少平滑策略，防止秒杀场景下最优 inflight 的估算失真。
限流成果：
3）熔断
在微服务零碎中，服务会依赖于多个服务，并且有一些服务也依赖于它。如下图，“对立权限”服务，依赖歌曲权限配置、购买信息、会员身份等服务，综合判断用户是否领有对某首歌曲进行播放 / 下载等操作的权限，而这些权限信息，又会被歌单、专辑等歌曲列表服务依赖。
当“对立权限”服务的其中一个依赖服务（比方歌曲权限配置服务）呈现故障，“对立权限”服务只能被动的期待依赖服务报错或者申请超时，上游连接池会逐步被耗光，入口申请大量沉积，CPU、内存等资源逐步耗尽，导致服务宕掉。而依赖“对立权限”服务的上游服务，也会因为雷同的起因呈现故障，一系列的级联故障最终会导致整个零碎宕掉。
正当的解决方案是断路器和优雅降级，通过尽早失败来防止部分不稳固而导致的整体雪崩。
传统熔断器实现 Closed、Half Open、Open 三个状态，当进入 Open 状态时会回绝所有申请，而进入 Closed 状态时霎时会有大量申请，服务端可能还没有完全恢复，会导致熔断器又切换到 Open 状态，一种比拟刚性的熔断策略。SRE 熔断只有打 Closed 和 Half-Open 两种状态，依据申请成功率自适应地抛弃申请，尽可能多地让申请胜利申请到服务端，是一种更弹性的熔断策略。QQ 音乐采纳更弹性的 SRE 熔断器：
requests：窗口工夫内的申请总数。accepts：失常解决的申请数量。K：敏感度，K 越小抛弃概率越大，个别在 1.5~2 之间。
失常状况下，requests 等于 accepts，所以抛弃概率为 0 。随着失常解决的申请缩小，直到 requests 等于 K * accepts，一旦超过这个限度，熔断器就会关上，并依照概率抛弃申请。
4）动静超时
超时是一件很容易被忽视的事件。在晚期架构倒退阶段，置信大家都有因为脱漏设置超时或者超时设置太长导致系统被拖慢甚至挂起的经验。随着微服务架构的演进，超时逐步被标准化到 RPC 中，并可通过微服务治理平台快捷调整超时参数。但仍有有余，传统超时会设定一个固定的阈值，响应工夫超过阈值就返回失败。在网络短暂抖动的状况下，响应工夫减少很容易产生大规模的成功率稳定。另一方面，服务的响应工夫并不是恒定的，在某些长尾条件下可能须要更多的计算工夫，为了有足够的工夫期待这种长尾申请响应，咱们须要把超时设置足够长，但超时设置太长又会减少危险，超时的精确设置常常困扰咱们。
其实咱们的微服务系统对这种短暂的延时上涨具备足够的容忍能力，能够思考基于 EMA 算法动静调整超时时长。EMA 算法引入“均匀超时”的概念，用均匀响应工夫代替固定超时工夫，只有均匀响应工夫没有超时即可，而不是要求每次都不能超时。次要算法：总体状况不能超标；均匀状况体现越好，弹性越大；均匀状况体现越差，弹性越小。
如下图，当均匀响应工夫 (EMA) 大于超时工夫限度 (Thwm)，阐明均匀状况体现很差，动静超时时长(Tdto) 就会趋近至超时工夫限度 (Thwm)，升高弹性。当均匀响应工夫(EMA) 小于超时工夫限度 (Thwm)，阐明均匀状况体现很好，动静超时时长(Tdto) 就能够超出超时工夫限度(Thwm)，但会低于最大弹性工夫(Tmax)，具备肯定的弹性。
为升高应用门槛，QQ 音乐微服务只提供超时工夫限度 (Thwm) 和最大弹性工夫 (Tmax) 两个参数的设置，并可在微服务治理平台调整参数。算法实现参考：https://github.com/jiamao/ema…
5）服务分级
咱们做了很多弹性能力比方限流。咱们是否能够依据服务的重要水平来决策抛弃申请。此外，在架构迭代的过程中，有许多波及整体零碎的大工程，如微服务革新，容器化，限流熔断能力落地等我的项目，咱们须要依据服务的重要水平来决策哪些服务后行。
如何为服务确定级别：
1 级：零碎中最要害的服务，如果呈现故障会导致用户或业务产生重大损失，比方登录服务、流媒体服务、权限服务、数专服务等。
2 级：对于业务十分重要，如果呈现故障会导致用户体验受到影响，然而不会齐全无奈应用咱们的零碎，比方排行榜服务、评论服务等。
3 级：会对用户造成较小的影响，不容易留神或很难发现，比方用户头像服务，弹窗服务等。
4 级：即便失败，也不会对用户体验造成影响，比方红点服务等。
服务分级的利用场景：
第一，外围接口经营品质日报：每日邮件推送 1 级服务和 2 级服务的观测数据。第二，SLA：针对 1 级服务和 2 级服务，制订 SLO。第三，API 网关依据服务分级限流，优先确保 1 级服务通过。第四，重大项目参考服务重要水平制订优先级打算，如容灾演练，大型流动压测等。
6）API 网关分级限流
API 网关既是用户拜访的流量入口，也是后盾业务响应的最终进口，其可用性是 QQ 音乐架构体系的重中之重。除了反对自适应限流能力，针对服务重要水平，当触发限流时优先抛弃不重要的服务。
成果如下图，网关高负载时，2 级、3 级、4 级服务抛弃，只有 1 级服务通过。
工具链
随着产品的迭代，零碎一直在变更。性能、延时、业务逻辑、用户量等因素的变动都有可能引入新的危险，而现有的架构弹性能力可能不足以优雅地应答新的危险。事实上，即便架构思考的场景再多，外网依然存在很多未知的危险，在某些非凡条件满足后就会引发故障。个别状况下，咱们只能等着告警呈现。当告警呈现后，复盘总结，探讨躲避计划，进行下一轮的架构优化。应答故障的形式比拟被动。
那么，咱们有没有方法变被动为被动？在故障触发之前，尽可能多地辨认危险，针对性地加固和防备，而不是等着故障产生。业界有比拟成熟的实践和工具，混沌工程和全链路压测。
1）混沌工程
混沌工程通过在生产环境上进行试验，注入网络超时等故障，被动找出零碎中的软弱环节，一直晋升零碎的弹性。
TMEChaos 以 ChaosMesh 为底层故障注入引擎，联合 TME 微服务架构、mTKE 容器平台打造成云原生混沌工程试验平台。反对丰盛的故障模拟类型，具备弱小的故障场景编排能力，不便研发共事在开发测试中以及生产环境中模仿事实世界中可能呈现的各类异样，帮忙验证架构设计是否正当，零碎容错能力是否合乎预期，为组织提供常态化应急响应演练，帮忙业务推动高可用建设。
TMEChaos Dashboard Web：TMEChaos 的可视化组件，提供了一套用户敌对的 Web 界面，用户可通过该界面对混沌试验进行操作和观测。
TMEChaos Dashboard Backend：NodeJS 实现的 Dashboard 中间层，为 Web 提供 Rest API 接口，并进行 TMEOA 权限 / 微服务权限验证。
TMEChaos APIServer：TMEChaos 的逻辑组件，次要负责服务维度的爆炸半径设置，ChaosMesh 多集群治理、试验状态治理、Mock 行为注入。
Status Manager：负责查问各 ChaosMesh 集群中的试验状态同步到 TMEChaos 的存储组件。
SteadyState Monitor：稳态指标组件，负责监控混沌试验运行过程中 IAAS 层 / 服务相干指标，如果超出阈值主动终止相干试验。
ChaosMesh Dashboard API：ChaosMesh 对外裸露的 Rest API 接口层，用于试验的增删改查，间接跟 K8S APIServer 交互。
Chaos Controller Manager：ChaosMesh 的外围逻辑组件，次要负责混沌试验的调度与治理。该组件蕴含多个 CRD Controller，例如 Workflow Controller、Scheduler Controller 以及各类故障类型的 Controller。
Chaos Daemon：ChaosMesh 的次要执行组件，以 DaemonSet 的形式运行。该组件次要通过侵入指标 Pod Namespace 的形式烦扰具体的网络设备、文件系统、内核等。
2）全链路压测
上一节的混沌工程是通过注入故障的形式，来发现零碎的软弱环节。而全链路压测，则是通过注入流量给零碎施加压力的形式，来发现零碎的性能瓶颈，并帮忙咱们进行容量布局，以应答生产环境各种流量冲击。
全链路压测的外围模块有 4 个：流量结构、流量染色、压测引擎和智能监控。
流量结构：为了保障真实性，从正式环境 API 网关抽样采集实在流水，同时也提供自定义流量结构。
流量染色：全链路压测在生产环境进行。生产环境须要具备数据与流量隔离能力，不能影响到原有的用户数据、BI 报表以及举荐算法等等。要实现这个指标，首先要求压测流量能被辨认，咱们采纳的做法是在 RPC 的 context 外面减少染色标记，所有的压测流量都带有这个染色标记，并且这些标记可能随 RPC 调用关系进行传递。而后，业务零碎依据标记识别压测流量，在存储时，将压测数据存储到影子存储而不是笼罩原有数据。
压测引擎：对接各类协定，治理发压资源，以可调节的速率发送申请。
智能监控：依附可观测能力，收集链路数据并展现，依据熔断规定智能熔断。
可观测性
随着微服务架构和基础设施变得越来越简单，传统监控曾经无奈残缺把握零碎的健康状况。此外，服务等级指标要求较小的故障复原工夫，所以咱们须要具备疾速发现和定位故障的能力。可观测性能够帮忙咱们解决这些问题。
指标、日志和链路追踪形成可观测的三大基石，为咱们提供架构感知、瓶颈定位、故障溯源等能力。借助可观测性，咱们能够对系统有更全面和精密的洞察，发现更深层次的零碎问题，从而晋升可用性。
在实际方面，目前业界曾经有很多成熟的技术栈，包含 Prometheus，Grafana，ELK，Jaeger 等。基于这些技术栈，咱们能够疾速搭建起可观测零碎。
1）Metrics
指标监控可能从宏观上对系统的状态进行度量，借助 QPS、成功率、延时、系统资源、业务指标等多维度监控来反映零碎整体的健康状况和性能。
咱们基于 Prometheus 构建联邦集群，实现千万指标的采集和存储，提供秒级监控，搭配 Grafana 做可视化展现。
咱们在微服务框架中重点提供四个黄金指标的观测：Traffic（QPS）、Latency（延时）、Error（成功率）、Staturation（资源利用率）。
QQ 音乐 Metrics 解决方案劣势：
秒级监控：QQ 音乐存在多个高并发场景，数专、演唱会直播、明星空降评论 / 社区等，会带来比日常高出几倍甚至数十倍的流量，而且流量集中在流动开始头几秒，容量评估难度极大。咱们通过搭建 Prometheus 联邦，每 3 秒抓取一次数据，实现了准实时监控。并对流动进行快照采集，记录流动产生时所有微服务的申请峰值，用于下次同级别艺人的峰值评估。
历史数据回溯：QQ 音乐海量用户及上万微服务，每天产生的数据量级很大。当咱们须要回溯近一个月甚至一年前的指标趋势时，性能是个极大挑战。因为历史数据的精度要求不高，咱们通过 Prometheus 联邦进行阶梯降采样，能够永恒寄存历史数据，同时也极大升高存储老本。
2）Logging
随着业务体量壮大，机器数量宏大，应用 SSH 检索日志的形式效率低下。咱们须要有专门的日志解决平台，从宏大的集群中收集日志并提供集中式的日志检索。同时咱们心愿业务接入日志解决平台的形式是无侵入的，不须要应用特定的日志打印组件。
咱们应用 ELK（ElasticSearch、Logstash、Kibana）构建日志解决平台，提供无侵入、集中式的近程日志采集和检索系统。
Filebeat 作为日志采集和传送器。Filebeat 监督服务日志文件并将日志数据发送到 Kafka。Kafka 在 Filebeat 和 Logstash 之间做解耦。Logstash 解析多种日志格局并发送给上游。ElasticSearch 存储 Logstash 解决后的数据，并建设索引以便疾速检索。Kibana 是一个基于 ElasticSearch 查看日志的零碎，能够应用查问语法来搜寻日志，在查问时制订工夫和日期范畴或应用正则表达式来查找匹配的字符串。
下图为音乐馆首页服务的近程日志：
3）Tracing
在微服务架构的简单分布式系统中，一个客户端申请由零碎中大量微服务配合实现解决，这减少了定位问题的难度。如果一个上游服务返回谬误，咱们心愿找到整个上游的调用链来帮忙咱们复现和解决问题，相似 gdb 的 backtrace 查看函数的调用栈帧和层级关系。
Tracing 在触发第一个调用时生成关联标识 Trace ID，咱们能够通过 RPC 把它传递给所有的后续调用，就能关联整条调用链。Tracing 还通过 Span 来示意调用链中的各个调用之间的关系。
咱们基于 jaeger 构建分布式链路追踪零碎，能够实现分布式架构下的事务追踪、性能剖析、故障溯源、服务依赖拓扑。
jaeger-agent 作为代理，把 jaeger client 发送的 spans 转发到
jaeger-collector。jaeger-collector 接管来自 jaeger-agent 上报的数据，验证和荡涤数据后转发至 kafka。jaeger-ingester 从 kafka 生产数据，并存储到 ElasticSearch。jaeger-query 封装用于从 ElasticSearch 中检索 traces 的 APIs。
下图为音乐馆首页服务的链路图：
4）Profiles
想必大家都遇到过服务在凌晨三点呈现 CPU 毛刺。个别状况下，咱们须要减少 pprof 剖析代码，而后期待问题复现，问题解决完后删掉 pprof 相干代码，效率底下。如果这是个偶现的问题，定位难度就更大。咱们须要建设一个可在生产环境应用分析器的零碎。
建设这个零碎须要解决三个问题：性能数据采集后须要长久化，不便回溯剖析；可视化检索和剖析性能数据；分析器在生产环境采集数据会有额定开销，须要正当采样。
咱们基于 conprof 搭建继续性能剖析零碎：线上服务依据负载以及采样决定采集机会，并裸露 profile 接口；conprof 定时将 profile 信息采集并存储；conprof 提供对立的可视化平台检索和剖析。
如下图，咱们能够通过服务名、实例、工夫区间来检索 profile 信息，每一个点对应一个记录。
5）Dumps
传统的形式是在过程解体时把过程内存写入一个镜像中以供剖析，或者把 panic 信息写到日志中。core dumps 的形式在容器环境中施行艰难，panic 信息写入日志则容易被其余日志冲掉且感知太弱。QQ 音乐应用的形式是在 RPC 框架中以拦截器的形式注入，产生 panic 后上报到 sentry 平台。
总结
本文从架构、工具链、可观测三个维度，介绍了 QQ 音乐多年来积攒的高可用架构实际。先从架构登程，介绍了双核心容灾计划以及一系列稳定性策略。再从工具链维度，介绍如何通过工具平台对架构进行测试和风险管理。最初介绍如何通过可观测来晋升架构可用性。这三个维度的子系统紧密联系，互相协同。架构的脆弱性是工具链和可观测性的建设能源，工具链和可观测性的不断完善又会反哺架构的可用性晋升。
此外，QQ 音乐微服务建设、Devops 建设、容器化建设也是晋升可用性的重要因素。单体利用不可用会导致所有的性能不可用，而微服务化按繁多职责拆分服务，能够很好地解决服务不可用和性能降级问题。Devops 把服务生命周期的治理自动化，通过继续集成、继续测试、继续公布等来升高人工失误的危险。容器化最大水平升高基础设施的影响，让咱们可能将更多精力放在服务的可用性上，此外，资源隔离，HPA，健康检查等，也在肯定水平上晋升可用性。
至此，基础架构提供了各种高可用的能力，但可用性最终还是要回归业务架构自身。业务零碎须要依据业务个性抉择最优的可用性计划，并在零碎架构中遵循一些准则，如最大限度缩小要害依赖；幂等性等可重试设计；打消扩容瓶颈；预防和缓解流量峰值；过载时做好优雅降级等等。而更重要的一点是，开发者须要时刻思考架构如何撑持业务的长期增长。
你可能感兴趣的腾讯工程师作品
| 一文读懂 Go 函数调用
| 内存泄露？腾讯工程师 2 个压箱底的办法工具
| 十亿人都在用的衰弱码，运维体系是怎么设计的
|最全 Go select 底层原理，一文学透高频用法
技术盲盒：前端 | 后端 |AI 与算法| 运维 | 工程师文化
