分析一下高可用架构设计的底层思想，可能和你想的不太一样
Posted 增长知行
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了分析一下高可用架构设计的底层思想，可能和你想的不太一样相关的知识，希望对你有一定的参考价值。
周末读老乔的专栏，里面分析高可用设计非常到位，很多底层思想都是共通的，加了自己的理解重新梳理如下，希望对大家的认知提升能有所帮助。
一、什么才是真正的高可用架构
想做好架构设计，第一步是将一个 IT 系统从应用层级至底层基础设施，全部拆解为一个个应用模块，可以称之为“元素”或“组件”；
第二步是保证各个模块间不能孤立存在，还要做好充分的协作，协作通过应用模块对外暴露的“服务”来承载，我们也可以称之为“连接”。
所以说，应用模块和服务，或者叫做元素和连接，共同组成了所谓的架构。
那么，要实现架构的高可用，就意味着实现所有元素、连接的高可用。
这是一点非常重要的认知：真正的高可用，是指实现所有元素、所有连接的高可用。
只要一个元素或一个连接没有做高可用设计，都意味着风险的存在。
比如，我们服务端和前端有个迟到发红包小组，早上10点以后到需要在群里发红包，那么你如何保证自己不发红包呢，也就是“出勤系统”是高可用的呢？
一定是全链条做高可用设计。闹钟至少有两个——互为主备、要保证衣物都在、要为堵车准备预案、要保证高峰期能挤上地铁、预留出等电梯的时间（咱们二楼不用等电梯，但是经常高峰期也要排队进门）……你甚至得保证身体健康，不然可能因为拉肚子而迟到。
要注意，在这个例子里。闹钟可能不响、堵车可能会发生，没问题，只要10点前你出现在办公室就行，也就是只要整个系统是高可用的就好。更准确地说，所谓高可用，是要保证“业务的连续性”，即在用户眼里，业务永远是正常（或基本正常）对外提供服务的。
这么看是不是有点难？有些事情就是这样，看似简单，甚至达到99%做到都很简单，但是要到99.999%（俗称5个9）就会非常难。
其实实际工作中，大部分企业的架构设计没有做到高可用，原因一般只有两个：相关负责人压根儿就没考虑高可用设计；做全套高可用的代价太大了，钱不够用，时间不够用。
二、冗余设计 和 trade-off 理念
到了企业层面，很多难题不是“简答题”，而是“选择题”。英文叫 trade-off：在需要而又相互对立的两者间的权衡，协调。
其实人生也如此，职业生涯也如此，如果都有唯一的正确答案，那太简单了。很多教程回答的都是“唯一正确答案”，听着很有道理，实际做的时候，发现根本不是这么一回事。
做好决策，在很多情况下，并不意味着风险就消失了 —— 风险始终存在。根据墨菲定律，如果事情有变坏的可能，无论概率有多小，它一定会发生。那么假设你我就是企业架构的总负责人，现在要保证企业整体业务的连续性，应该怎么办呢？
有一个很通用的办法，叫做“冗余设计”。所谓“集群”、“分布式”，这些名词大体上都是在描绘“冗余设计”的概念。
但冗余设计也不是万能的，它只能解决底层物理机器，也就是某一个实例的不可用问题。如果是代码逻辑出现了问题，冗余设计就失效了 —— 一个恶性 Bug 在生产环境爆发，后果是所有集群都会遭殃。
三、为什么会有 “降级” 和 “熔断”
没钱做 100% 的高可用设计，又想尽量提供系统的抗风险能力。作为架构负责人，应该怎么办呢？
第一个解决方案是，在风险爆发、系统出现问题的情况下，对外提供“降级服务”。也就是说，当团队没有时间去设计、测试并确保当前组件高可用时，如果因为未知原因，导致组件出现故障，我们需要提供一个逻辑相对简单，并且一定可用的服务替代原来的服务实现，实现服务对外的高可用。
降级服务是实打实的高可用保障手段。在用户眼里，业务是连续的，只是可靠性降低了。其实对于架构师而言，高可用和高可靠应该是两个不同的概念，只是很多人将其混为一谈。
在最理想的情况下，我们既保证高可用，也保证高可靠；但出现问题时，我们优先保证高可用，其次保证高可靠。这是另一点关键认知。
其实在不同领域里，有很多类似的做法。比如在流媒体领域，当用户观看直播出现严重卡顿时，很多企业的第一反应不是查服务器 Log，而是为用户自动降码率。因为比起画质降低，卡的看不了显然会让用户更痛苦。
如果“降级服务”还解决不了问题，应该怎么办？答案是提供“熔断服务”，让出现 Bug 的模块从系统中“熔断”，虽然用户会看到某个小的系统报错，但整个业务依然是正常响应的，不会被一个系统的 Bug 拖死。
四、总结一下
高可用意味着对系统全部元素、连接都进行高可用设计，在物理实例层面主要表现为冗余和集群设计，在代码逻辑层面，方法则多种多样。当你的资源和精力不足以实现全链路高可用时，提供“降级服务”和“熔断服务”，优先保证高可用，其次保证高可靠。企业里面有些核心服务是不能降级的，对于这类服务，就一定要通过研发流程管理，确保服务的高可用、高可靠。一名合格的技术管理者，要能够识别核心服务，并引导团队重点关注。
高可用设计，意味着“Design For Failure”，最重要的是让我们做产品没有后顾之忧。如果后院天天起火，研发团队每天胆战心惊，也就无从谈起“将产品打磨至卓越”了。所以，做好高可用，一定程度上就是在实践“慢就是快”的认知理念。
虽然我们或许不能保证所有服务高可靠，但我们是可以保证所有服务高可用的。其关键点在于，面向所有的元素和连接，都要做设计。任何没有被设计过的元素和连接，往往都是不可靠的。
任何一个要达到的目标，都要被量化；任何一个量化的目标，都是一个契约，要有契约精神；任何一个契约，都要进行设计。没有设计的内容，怎么可能如你所愿呢？
以上是关于分析一下高可用架构设计的底层思想，可能和你想的不太一样的主要内容，如果未能解决你的问题，请参考以下文章
MySQL性能调优与架构设计——第 18 章 高可用设计之 MySQL 监控