架构师眼中的高可用架构设计之道
Posted InsideMySQL
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了架构师眼中的高可用架构设计之道相关的知识，希望对你有一定的参考价值。
破产码农
高可用（High Availability）是每位码农在进行系统设计和代码编写时都不得不思考的重要环节。
即便这样一个常见的问题，其实很多码农依然没有真正理解何为高可用。
大部分码农会说：高可用是指当系统或硬件发生宕机时，确保业务的连续性。
高可用的判定标准是一年内业务宕机时间。高可用99.999%（5个9），意味着一年内只允许宕机5分多钟，达到99.999%代表这个系统在高可用方面做得相当出色。
如何实现系统高可用设计呢？消除单点故障（SPOF single point of failure），实现故障转移（failover）。
业务层无状态，高可用相对简单，可以通过类似LVS、Keepalived等机制，当发现立即剔除节点或实现故障转移。
数据库有状态，相对复杂一些，在mysql数据库中可通过类似MHA机制实现高可用切换，从而保证业务的连续性。
因为数据库是有状态服务，因此高可用切换所需时间更长。不过有了MGR（MySQL Group Replication）这样的机制，数据库的高可用也成为了无（弱）状态。
从高可用设计工程实现角度看，首先建立冗余，一台机器宕机，另外的机器可以马上顶上。
接着，通过高可用实现的作用域，是机房级、同城级、跨城级，来判定自己高可用的实现级别。
最后，再结合业务是否多活多写的特性，判断这个高可用的最终架构水准。
游戏级：同机房单活高可用架构；
电商级：一地三中心同城多活高可用架构；
金融级：三地五中心跨城多活高可用架构；
可惜，上面的这些理解：以上全错。
因为他们没有抓住最为基本的关键点：何为业务的连续性？
网上大部分技术大V对高可用就停留在单一组件或数据库上，但这样的高可用设计显然是不合格的。
陈皓在他《关于高可用的系统》博客中，主要是在讲述数据库高可用的实现，而且他认为这很难，特别是对于数据一致性要求非常高的场景。
然而，对于MySQL来说，这已经是个非常easy的问题，直接上无损复制或者MGR。
还有一些大V是在讲述高可用下的缓存和数据库之间数据一致性的问题。
总之，过于纠结某个组件的高可用，是非常片面的。这不是站在架构师角度来掌控整体高可用架构的设计。
假设一台服务器宕机，高可用机制将其剔除后，若剩余的服务器撑不住业务的访问量，请问这是合格的高可用架构么？
又比如，磁盘突然发生抽风，磁盘使用率100%，导致日志写入变慢，业务的响应时间上升10倍，这是合格的高可用架构么？
若数据库发生了宕机，进行切换，但是切换完后，数据库依然顶不住压力，又发生了切换，请问这是合格的高可用架构么？
显然，这些都不是真正的高可用架构设计。
为什么这些高可用架构都有问题呢？
因为他们只考虑自身的可用性逻辑，没有考虑全链路各个高可用的环节。
所以，这样的高可用设计不具有真正的可衡量性。
有同学会说：有啊。高可用不是计算宕机时间么？几个九不就是高可用的衡量指标么？
再一次的以上全错，因为现在的高可用计算方式是不确定的。
举例来说，1台服务器1年内宕机5分钟15秒内，就符合99.999%的高可用标准。
如果1个数据库集群3台服务器，一主两从，整体宕机5分15秒算99.999%高可用，还是宕机5分15秒 × 3，16分钟内才算是99.999%的高可用标准呢？
其实，真正的高可用标准判断应该是业务一年的影响时长。
每个（子）业务才是一个最完整的高可用计算单元。
如果细化到各个组件，那高可用计算就会复杂很多。
对于数据库来说，如果从机宕机了，哪怕宕机了几个小时，但是他对业务毫无影响，不能算可用性有问题，因为架构设计时就做了冗余处理。
但若业务的请求是主从分离设计，从机宕机，影响了业务的读取请求，那么就应该判断可用性下降。
同样的，当服务活着，但他的响应耗时是10秒，这样业务早已处于不可用的境地。
因此，可用性的判断标准不仅仅是系统活着与否，切换后数据是否丢失。
我们来看Wiki对于高可用的定义：
Wiki的表述相对是比较准确的，红色的部分是需要特别关注的重点。
若用姜老师的话归纳，高可用是指：
保障在指定响应时间内，系统能提供正常的服务。
可以发现这比传统理解的高可用更高一层，不但要求提供正常服务，确保业务连续性，还要求系统能提供稳定的响应时间。
经过上面的讨论，大家应该意识到高可用的真正定义。
因此，为了实现系统真正高可用的标准，在进行架构设计时应至少保障以下四个方面的设计和实现：模块化 + Fail-fast + 幂等重试 + 服务降级
1
模块化
模块化是指将业务拆成很多独立的小模块。
对于电商系统，有用户层、订单层、物流层、库存层。
组件有缓存、消息队列、数据库等。
作为核心有状态服务的数据库，还需要根据模块进行垂直拆分，至少拆分为不同库（database），最好能拆分成不同实例。
模块内，通过冗余和故障转移等机制，实现模块内部的可用性闭环。
模块间，理清互相之间的调用是同步调用还是异步调用。同时，应该尽可能做到一个子模块宕机，对另一个子模块无影响或有限的影响。
模块化是架构设计的基础，先要做好各个模块的拆解，理清楚各业务的调用关系链。若连这块工作先前都没准备好，未来大概率这个系统将会是灾难。
2
Fail-fast
假设经过模块化的拆解，将一个模块拆解为了服务A、服务B、数据库。
对于大型业务来说，可能还有缓存，这里就做简化处理。
接着在整体架构设计时，需要要给每次服务调用可衡量的业务目标。
例如在设计时约定服务A调用服务B必须在5ms内完成，服务B调用数据库必须在30ms完成，否则并不能真正满足业务可用性的指标。
当系统出现不能满足当初系统设计的目标时，则应该尽快地返回“错误”，也就是Fail-fast。
Fail-fast要求尽快返回错误结果，终止正在进行的操作，让潜在错误尽可能早的被发现，以此让更上层的系统去处理错误。
系统设计，特别是对于高可用设计系统来说，这个准则尤为重要。
要实现这样的机制，使用超时机制是最容易的一种方式。
将服务A调用服务B设置超时时间5ms，服务B调用数据库设置30ms，超时立即返回超时错误码。
若没有设置超时，可能发生服务A、服务B、数据库都活着，但是整个业务依然是完全不可用的状态。
数据库这一层，等待通常是因为锁竞争导致，除了使用超时机制外，还可以使用特定SQL去判断是否需要等待，这样对比超时机制，会更高效：
mysql> SELECT * FROM User WHERE userId = 2 FOR UPDATE NOWAIT;ERROR 3572 (HY000): Do not wait for lock.
3
幂等重试
当启用超时机制后，业务这里可能会收到大量的超时错误码。
错误码可以区分为业务错误码和系统错误码。超时应该算是一种业务错误码。
开发同学应该意识到超时并不一定是问题。可能是这时网络发生了抖动，导致业务请求发生了抖动。亦或是是SSD硬盘在进行GC，性能急剧退化所致。当然，也可能是下层数据库组件当前正在发生切换等等。
因此，当捕获超时时，业务层应该进行重试。
但是每个服务层需要保证每一次重试都是幂等的，即多次重放的结果都是一样的。这就是系统设计中的Idempotent Retry。
用户不会因为多次重试导致重复下单，重复扣款等行为出现。
当幂等重试多次依然有问题，则这时应该触发服务降级，而不是无限的继续重试。
4
服务降级
服务降级可以有：限流、熔断两种处理方式。其实，从本质上看，两者是一样的。
限流（flow control）是指当达到指定的阈值时对流量进行控制，以避免被瞬时的流量高峰冲垮，从而保障应用的可用性。
例如服务A是一个电商用户下单业务，设计时服务A的访问上限为3000笔/秒，整体请求控制在50ms内。
服务A可以做水平扩展，扩展为100个节点，则可以支撑30W笔/秒的请求，这可能是双11的要求。
限流是指当发现服务A请求大于3000笔/秒时，应该对其进行限流，保证即便是双11大促场景下用户依然能有很好的交易体验，而不是让用户进行没有必要的等待。
另一种限流情况更为精细，假设服务A是商户库存服务。1个商户的某次促销导致某个产品热销，产生热点竞争，从而影响其他商户的库存服务。
因此服务A除了设定3000笔/秒，50ms的总体目标，还可以细化到业务中每件商品库存每秒的交易量，比如300笔/秒。超过这个阈值需要对特定商品库存进行限流。
熔断是根据业务的整体失败量、失败率、响应耗时达到某一阈值时，触发熔断机制，不再提供服务。用户需尽快排除内部具体问题后，再恢复业务。
在产品层面，可以通过公告的形式告知用户，用户本身无需感知熔断机制的触发。
如上图所示，当充值系统可能存在问题时，这时当用户有新请求时，可告诉用户系统正在维护中，稍后将继续提供服务。
上述的降级方案，无论是限流还是熔断，都要求服务层监控数据的收集，因此需要引入类似健康度平台来进行全链路地监控、调度和管理相关服务。
在上图中，由于各组件需要高可用，因此服务A、服务B、数据库都有各自的高可用机制。
每个组件应该上报自己服务的状态到健康度管理平台，不论是采用服务发现还是心跳机制，这样健康度平台才能精细化做好各组件的降级工作。
若由于硬件问题导致单个服务A或服务B的耗时不达标或错误率上升，则应该尽快剔除相应的服务。
若服务A整体耗时或者超时错误率达到一定的阈值，那么健康度管系统应尽快的启动公告机制。防止更多的请求进入系统，造成雪崩。
若数据库发生了切换，名字服务对应的IP变更了，则可能还需要健康度系统通知服务B去reload服务，获取新的IP。
上面这些都只是抛砖引玉，真正工程上的高可用架构设计会更复杂。
因为在海量并发的互联网业务中，还需要进行分布式架构的设计。这时高可用设计的层级会进一步提升。
分布式拆分完后，会衍生出同城容灾、跨城容灾、多活多写、单元化访问等设计和问题。每个行业还有自己所特有的问题，如游戏、电商、金融等。
一个大型系统架构设计想要一步到位几乎是不可能的，若翻看最早的代码，大部分都是一地鸡毛。
然而，随着业务的不断发展，用户请求的不断增大，对技术的要求也会不断提升，这时会倒逼架构地不断发展和演进。
对架构师来说，高可用架构设计是没有终点的，每年都需要解决新问题。这些又依赖每年业务不断的发展而又有新的感悟。
但模块化、Fail-fast、幂等设计、服务降级，这些都是基础。意识并能解决好这些问题，相信已经是一个很不错的架构师了。
以上。
以上是关于架构师眼中的高可用架构设计之道的主要内容，如果未能解决你的问题，请参考以下文章