系统稳定性与高可用保障的几种思路

点滴~

已于 2024-12-29 20:34:43 修改

阅读量1.6k

点赞数 13

文章标签：网络数据库

于 2024-12-25 20:02:11 首次发布

本文链接：https://blog.youkuaiyun.com/oqkdws/article/details/144714651

版权

七、美团点评智能支付核心交易系统的可用性实践

一、前言

高并发、高可用、高性能被称为互联网三高架构，这三者都是工程师和架构师在系统架构设计中必须考虑的因素之一。今天我们就来聊一聊三H中的高可用，也是我们常说的系统稳定性。

本篇文章只聊思路，没有太多的深入细节。阅读全文大概需要5~10分钟。

业界常用 N 个 9 来量化一个系统可用性程度：比如4个9表示年故障时间为365*24*60*0.9999=52分钟

TPS（Transactions Per Second）：每秒事务处理量。在这里，一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。

QPS（Queries Per Second）：每秒查询率。表示每秒钟系统能够处理的查询数量。这里的查询一般是指从数据库中获取数据的操作。

虽然TPS和QPS都表示每秒钟处理的数量，但TPS计算的是事务的数量，而QPS计算的是查询的数量。一个事务可能包含多个查询操作。

二、高可用的定义

业界常用 N 个 9 来量化一个系统可用性程度，可以直接映射到网站正常运行时间的百分比上。

可用性的计算公式：

大部分公司的要求是4个9，也就是年度宕机时长不能超过53分钟，实际要达到这个目标还是非常困难的，需要各个子模块相互配合。

要想提升一个系统的可用性，首先需要知道影响系统稳定性的因素有哪些。

三、影响稳定性的因素

首先我们先梳理一下影响系统稳定性的一些常见的问题场景，大致可分为三类：

人为因素

不合理的变更、外部攻击等等

软件因素

代码bug、设计漏洞、GC问题、线程池异常、上下游异常

硬件因素

网络故障、机器故障等

下面就是对症下药，首先是故障前的预防，其次是故障后的快速恢复能力，下面我们就聊聊几种常见的解决思路。

四、提升稳定性的几种思路

4.1 系统拆分

拆分不是以减少不可用时间为目的，而是以减少故障影响面为目的。因为一个大的系统拆分成了几个小的独立模块，一个模块出了问题不会影响到其他的模块，从而降低故障的影响面。系统拆分又包括接入层拆分、服务拆分、数据库拆分。

接入层&服务层

一般是按照业务模块、重要程度、变更频次等维度拆分。

数据层

一般先按照业务拆分后，如果有需要还可以做垂直拆分也就是数据分片、读写分离、数据冷热分离等。

4.2 解耦

系统进行拆分之后，会分成多个模块。模块之间的依赖有强弱之分。如果是强依赖的，那么如果依赖方出问题了，也会受到牵连出问题。这时可以梳理整个流程的调用关系，做成弱依赖调用。弱依赖调用可以用MQ的方式来实现解耦。即使下游出现问题，也不会影响当前模块。

4.3 技术选型

可以在适用性、优缺点、产品口碑、社区活跃度、实战案例、扩展性等多个方面进行全量评估，挑选出适合当前业务场景的中间件&数据库。前期的调研一定要充分，先对比、测试、研究，再决定，磨刀不误砍柴工。

4.4 冗余部署&故障自动转移

服务层的冗余部署很好理解，一个服务部署多个节点，有了冗余之后还不够，每次出现故障需要人工介入恢复势必会增加系统的不可服务时间。所以，又往往是通过“自动故障转移”来实现系统的高可用。即某个节点宕机后需要能自动摘除上游流量，这些能力基本上都可以通过负载均衡的探活机制来实现。

涉及到数据层就比较复杂了，但是一般都有成熟的方案可以做参考。一般分为一主一从、一主多从、多主多从。不过大致的原理都是数据同步实现多从，数据分片实现多主，故障转移时都是通过选举算法选出新的主节点后在对外提供服务（这里如果写入的时候不做强一致同步，故障转移时会丢失一部分数据）。具体可以参考Redis Cluster、ZK、Kafka等集群架构。