如何做高可用的架构设计

定义目标

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

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使用率、内存使用率、网卡流量、连接数等。

总结

欢迎工作一到十年的Java工程师朋友们加入Java进阶高级架构裙:858327216

本群提供免费的学习指导 架构资料 以及免费的解答

不懂得问题都可以在本群提出来 之后还会有职业生涯规划以及面试指导

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

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 157,298评论 4 360
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 66,701评论 1 290
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 107,078评论 0 237
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,687评论 0 202
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,018评论 3 286
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,410评论 1 211
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,729评论 2 310
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,412评论 0 194
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,124评论 1 239
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,379评论 2 242
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 31,903评论 1 257
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,268评论 2 251
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 32,894评论 3 233
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,014评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,770评论 0 192
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,435评论 2 269
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,312评论 2 260

推荐阅读更多精彩内容