码迷,mamicode.com
首页 > 其他好文 > 详细

如何做高可用的架构设计

时间:2018-03-09 17:53:08      阅读:196      评论:0      收藏:0      [点我收藏+]

标签:场景   网卡流量   工作   网络层   机器   影响   操作系统   题目   net   

本篇的题目其实比较大,所以在写的时候,我其实是有些“惶恐”的,怕这篇完成后有标题档的嫌疑。不过为了将自己过去多年的经历和最近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的优化,异地多活等等,欢迎大家一起讨论。

推荐一个交流学习群:650385180里面会分享一些资深架构师录制的视频录像:有Spring,MyBatis,Netty源码分析,高并发、高性能、分布式、微服务架构的原理,JVM性能优化这些成为架构师必备的知识体系。还能领取免费的学习资源,目前受益良多:

技术分享图片

如何做高可用的架构设计

标签:场景   网卡流量   工作   网络层   机器   影响   操作系统   题目   net   

原文地址:https://www.cnblogs.com/lfs2640666960/p/8534820.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!