如何做高可用的架构设计

内容简介：如何做高可用的架构设计

本篇的题目其实比较大，所以在写的时候，我其实是有些“惶恐”的，怕这篇完成后有标题档的嫌疑。不过为了将自己过去多年的经历和最近1年改造架构的想法，做一个阶段性总结，还是有必要好好写一写的，所以如果写得不好，大家多包涵，欢迎大家补充。

定义目标

既然我们的目标是做到高可用，那么我们就有必要先明确清楚高可用的含义，并通过拆解目标，让目标可以被量化。按照我的理解，可以将目标按照以下三条进行拆解：

1. 保持业务高稳定性

系统稳定性是高可用的根本目的，通俗的说，系统能持续可用，不会无故宕机，在高压下仍然能正常工作。

2. 支持快速定位故障

从实际工程的角度看，不出故障的服务是不存在的，所以出了故障要能够快速发现和定位，在外部用户发现前，通过报警机制，能准确定位故障原因，帮助工程师尽快处理问题，防止进一步影响业务。

3. 支持快速恢复业务

这一点需要多说两句，有关“恢复业务”和“解决问题”之间的区别，这两个词也正好说明了线上出现故障后，我们解决问题的两种不同思路。简单的说，“恢复业务”的意思是线上故障是什么原因可以先暂时放在一边，我们先找到快速的临时方案，让业务跑起来。很多同学在处理生产故障的时候有一个思维惯性：先努力找到问题的起因，然后改代码解决问题，测试，发布上线，最后业务功能才能正常工作。实际上，一个流程走下来，时间成本是很高的，业务因为本次故障受到较大的影响。比如说某台机器上的服务响应很慢，导致请求超时，可能的原因有：网络带宽出现问题、机器磁盘有问题、机器的CPU或者Memory不够用了、应用程序有死循环、jvm垃圾回收时间变长......要在短短几分钟内排查这么多可能的原因是很难的，但我们不知道真正的原因也可以恢复业务，比如说最简单的方法就是直接把这台机器立刻下线，让流量分配到其它的机器或者新添加的机器上。

现在我们有了这三条分拆后的目标，那么接下来的架构方案就会围绕着这三个目标来执行。

服务分级 + 服务降级

服务分级：根据业务的需求，将服务进行分类，划分核心服务和普通服务，核心服务与普通服务不会相互影响，服务背后的资源，缓存，数据库，MQ相互分离。服务分级，对应于我们的子目标1。

这里有两个关键点：

1. 抽取核心服务，例如我们互金业务中，用户，订单，支付这三个服务是核心业务，消息推送、营销券积分等是普通服务，核心服务的稳定与否也关乎业务的KPI。核心服务是客户必须要使用的，核心服务一旦有问题，客户就不能购买产品了；而普通服务即使有问题，暂时也不会对交易产生影响。从另外一个角度看，普通服务的代码在我们日常的工作中反而变动频繁。因此，优先保证核心服务正常使用，是我们首要目标。

2. 不同级别的服务资源分离，包括服务器, 缓存,MQ, DB等建议都分离出来，因为只要不同服务共享资源，就有可能因为普通服务影响核心服务。举个最简单的例子，如果服务间共用一套redis，那么如果大量的消息请求占用了 redis 的连接数，那么核心服务的质量就会因此受到很大的影响。

服务降级：当出现故障的时候，可以将普通服务直接降级，保护核心服务不受影响。服务降级，对应于我们的子目标3。

拆分为核心服务和普通服务后，在很多业务场景下，服务间是相互调用的，这就存在服务之间可能是相互影响的。例如，我们在推送消息（普通服务）之前，需要查询用户的信息（核心服务），大量消息下发，就会给核心业务系统产生较大的压力。这种情况下我们可以通过将非核心服务停掉，以保证核心服务不受影响。

另外，在做服务降级的时候，最佳的方式，是通过修改动态配置来执行。而不是靠手工到线上修改静态配置或者发布新版本的方式来完成，因为容易出错，而且效率还不高。所以，这里我比较推荐类似阿里diamond的服务, 接入diamond后，通过diamond后台，修改配置后，groovy脚本直接就将最新的配置同步到服务中，甚至都不要重启服务就完成了降级操作。

建立分层监控

建立监控分层的目的对应于我们的子目标2，就是将故障分析和定位时涉及的所有的相关信息都要监控起来，共分为5层，具体各层和含义如下：

网络层

分析网络出入的情况，比方说有大量的外部请求，导致外网网卡的带宽被占满，需要立刻分析是否是正常流量，如果是活动带来高频访问，那么需要做带宽升级，如果是外部攻击，那么需要考虑做流量清洗等防护操作。

接口层

收集对外暴露的接口的访问情况，包括接口执行时间、返回状态码、调用次数等，我们需要时刻关注我们访问次数最多的API接口，根据接口的访问情况，决定了是否需要服务扩容，并判断是否有外部的不正常访问，机刷等。如果存在某些接口有大量的错误码返回，我们需要第一时间查明这些接口访问失败的原因。

业务层

收集和分析核心业务和普通服务的运行情况和相互调用情况，比方说，如果某个服务产生了大量的Exceptions或者dubbo服务调用超时。

中间件层

中间件层指服务依赖的各类中间件，例如容器、缓存、消息队列。不同的中间件关注不一样的信息，例如数据库Redis监控指标包括连接数、请求数, rdb&aof的执行情况, IO的频率等，缓存命中率等。

系统层

系统层指操作系统状态、收集的信息包括cpu使用率、内存使用率、网卡流量、连接数等。

总结

将实现高可用架构拆分为3个子目标，针对这3个子目标提出了三个优化思路：服务分级 + 服务降级+分层监控。围绕这三块优化的方向，层层推进，最终让系统的技术架构得到质的提升。未来，我会针对里面的每一点，进一步展开讨论一下里面的细节，除此之外，还会讨论一些本文还未涉及到的内容，例如DNS的优化，异地多活等等，欢迎大家一起讨论。

扫描二维码或手动搜索微信公众号： ForestNotes

欢迎转载，带上以下二维码即可

以上就是本文的全部内容，希望对大家的学习有所帮助，也希望大家多多支持 码农网

查看所有标签

猜你喜欢:

• 架构设计(8)—高可用架构设计
• 储存高可用架构
• 高可用架构补充篇
• 可用性高达5个9！支付系统高可用架构设计实战
• Canal 高可用架构部署
• Redis 高可用架构最佳实践

本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。