如何建设高可用系统

“高可用性”(High Availability)通常来描述一个系统经过专门的设计,从而减少停工时间,而保持其服务的高度可用性。以下是高可用系统的设计建议:

减少单点

去单点首先要识别整个系统所有主链路的单点,如机房(同城异地双机房),应用服务器,DNS服务器,SFTP服务器,LBS,缓存服务器,数据库,消息服务器,代理服务器和专线等,如系统通过专线调用对方服务,需要考虑同时拉联通和电信的专线,联通或电信的专线还是有一定概率会出现问题的,但是同时出问题的概率会小非常多。优先使用软负载,使用硬负载兜底。

减少依赖

减少DNS依赖,减少远程服务依赖,DNS依赖可以尝试设置本地host,用工具给所有服务器推送最新的域名映射关系,通过本地缓存或近端服务减少RPC调用。

限制循环

避免无限死循环,导致CPU利用率百分百,可以设置for循环的最大循环次数,如最大循环1000次。

控制流量

避免异常流量对应用服务器产生影响,可以对指定服务设置流量限制,如QPS,TPS,QPH(每小时总请求量)和QPD(每天总请求量)。

精准监控

对CPU利用率,load,内存,带宽,系统调用量,应用错误量,PV,UV和业务量进行监控,避免内存泄露和异常代码对系统产生影响,配置监控一定要精准,如平时内存利用率是50%,监控可以配置成60%进行报警,这样可以提前感知内存泄露问题,避免应用无响应。

无状态

服务器不能保存用户状态数据,如在集群环境下不能用static变量保存用户数据,不能长时间把用户文件存放在服务器本地。服务器有状态会难以扩容,且出现单点问题。

容量规划

定期对容量进行评估。如大促前进行压测和容量预估,根据需要进行扩容。

功能开关

打开和关闭某些功能,比如消息量过大,系统处理不了,把开关打开后直接丢弃消息不处理。上线新功能增加开关,如果有问题关闭新功能。

设置超时

设置连接超时和读超时设置,不应该太大,如果是内部调用连接超时可以设置成1秒,读超时3秒,外部系统调用连接超时可以设置成3秒,读超时设置成20秒。

重试策略

当调用外部服务异常时可以设置重试策略,每次重试时间递增,但是需要设置最大重试次数和重试开关,避免对下游系统产生影响。

隔离

应用隔离,模块隔离,机房隔离和线程池隔离。可以按照优先级,不变和变几个维度来隔离应用和模块,如抽象和不变的代码放在一个模块,这个模块的代码几乎不会修改,可用性高,经常变的业务逻辑放在一个模块里,这样就算有问题,也只会影响到某一个业务。不同的业务使用不同的线程池,避免低优先级任务阻塞高优先级,或高优先级任务过多时影响低优先级任务永远不会执行。

异步调用

同步调用改成异步调用,解决远程调用故障或调用超时对系统的影响。

热点缓存

对热点数据进行缓存,降低RPC调用。如B系统提供名单服务,B系统可以提供一个client SDK提供近端缓存服务,定期去服务器端取数据,减少RPC调用。
缓存容灾 – 当数据库不可用时可以使用缓存的数据。并设置分级缓存,如优先读本地缓存,其次读分布式缓存。

分级缓存

优先读本地缓存,其次读分布式缓存。通过推模式更新本地缓存。

系统分级

对系统进行分级,如ABC三个等级,高级别系统不依赖于低级别系统,并且高级别系统比底级别系统高可用率要高。

服务降级

如果系统出现响应缓慢等状况,可以关闭部分功能,从而释放系统资源,保证核心服务的正常运行。需要识别哪些服务可以降级,比如突然有大量消息流入,导致服务不可用,我们会把消息直接丢弃掉。或通过设置流控,拒绝为低级别系统提供服务。

流量蓄洪

当流量陡增时,可以将请求进行蓄洪,如把请求保存在数据库中,再按照指定的QPS进行泄洪,有效的保护下游系统,也保证了服务的可用性。当调用对方系统,对方系统响应缓慢或无响应时,可采取自动蓄洪。

服务权重

在集群环境中,可自动识别高性能服务,拒绝调用性能低的服务。如在集群环境中,对调用超时的服务器进行权重降低,优先调用权重高的服务器。

依赖简化

减少系统之间的依赖,比如使用消息驱动,A和B系统通过消息服务器传递数据,A和B系统使用数据库进行读写分离,A系统负责往数据库中写数据,B系统负责读数据,因为数据存放在数据库中,当A不可用时,短时间内不影响B系统提供服务。

弹性扩容

根据资源的使用率自动或手动进行扩容。如带宽不够用时,快速增加带宽。

灰度和回滚

发布新功能只让部分服务器生效,且观察几天逐渐切流,如果出现问题只影响部分客户。出现问题快速回滚,或者直接下线灰度的机器。

减少远程调用

优先调用本地JVM内服务,其次是同机房服务,然后是同城服务,最后是跨城服务。如A调用B,B调用互联网的C系统获取数据,B系统可以把数据缓存起来,并设置数据的保鲜度,减少B对C的依赖。配置中心把注册服务的地址推送到调用服务的系统本地。参数中心把参数配置信息推送到系统的本地内存,而不是让系统去远程服务器获取参数信息。

熔断机制

增加熔断机制,当监控出线上数据出现大幅跌涨时,及时中断,避免对业务产生更大影响。如我们做指标计算时,指标可以计算慢,但是不能算错,如果发现某个用户的指标环比或同比增长一倍或跌零,会考虑保存所有消息,并中止该用户的指标计算。

运行时加载模块

我们会把经常变的业务代码变成一个个业务模块,使用Java的ClassLoader在运行时动态加载和卸载模块,当某个模块有问题时候,可以快速修复。

代码扫描

使用IDEA代码分析等工具进行代码扫描,识别出程序中的BUG,如空指针异常,循环依赖等。

自动备份

程序,系统配置和数据定期进行备份。可使用linux命令和shell脚本定时执行备份策略,自动进行本地或异地。出现问题时能快速重新部署。

线上压测

系统的对外服务需要进行压测,知道该服务能承受的QPS和TPS,从而做出相对准确的限流。

转自:https://www.cnblogs.com/modou/p/9661022.html

原文地址:https://www.cnblogs.com/xkzhangsanx/p/11110715.html

时间: 2024-08-01 04:21:05

如何建设高可用系统的相关文章

搭建一个redis高可用系统

一.单个实例 当系统中只有一台redis运行时,一旦该redis挂了,会导致整个系统无法运行. 单个实例 二.备份 由于单台redis出现单点故障,就会导致整个系统不可用,所以想到的办法自然就是备份(一般工业界认为比较安全的备份数应该是3份).当一台redis出现问题了,另一台redis可以继续提供服务. 备份 三.自动故障转移 虽然上面redis做了备份,看上去很完美.但由于redis目前只支持主从复制备份(不支持主主复制),当主redis挂了,从redis只能提供读服务,无法提供写服务.所以

高可用系统开发可能遇到的问题

高可用系统开发中可能遇到的问题一般处理思路如下:

高可用系统在点评的实践与经验--讲座思考

SDCC 2016架构峰会纪要(三) 关键词:深度.干货.大牛.火爆.一线.图书 题目 主讲人 主讲人个人简介 支付宝红包稳定性实践与思考 王 俊 蚂蚁金服支付清算平台架构师 宅米网技术架构变迁与实践 李智慧 宅米CTO 携程下一代无线App架构设计 陈浩然 携程旅行网无线开发总监 新型架构实践与应用 孙子荀 腾讯手Q公众号后台负责人 从概率和用户感知出发实现高可用架构 史海峰 当当网架构部总监 高可用系统在点评的实践与经验 陈一方 大众点评交易平台技术团队负责人 微服务架构设计与实践 黄 勇

如何设计一个高可用系统?要考虑哪些地方?

本文已经收录自笔者开源的 JavaGuide: https://github.com/Snailclimb (69k+Star[Java学习+面试指南] 一份涵盖大部分Java程序员所需要掌握的核心知识)如果觉得不错的还,不妨去点个Star,鼓励一下! 一篇短小的文章,面试经常遇到的这个问题.本文主要包括下面这些内容: 高可用的定义 哪些情况可能会导致系统不可用? 有些提高系统可用性的方法?只是简单的提一嘴,更具体内容在后续的文章中介绍,就拿限流来说,你需要搞懂:何为限流?如何限流?为什么要限流

浅述实现系统高可用,常用的解决手段

所谓可用性,是指某系统能够提供正常服务的特性. 可用性的高低是使用不可用时间占总时间的比例来衡量.不可用时间是从故障发生到故障恢复的时间.比如,可用性 4 个 9 的系统(99.99%),它一年宕机时间不能超过53分钟(=365*24*60*(1-0.9999)).做到高可用系统,需要尽可能的降低故障发生的次数和减少故障持续的时间. 出现系统不可用的原因,一种是人为的,比如发布了有 bug 的代码.不规范的发布流程导致的宕机或者网站访问量过载造成的雪崩等:另一种则是非人为的,由于外部系统和环境的

支付系统高可用架构设计实战

对于互联网应用和企业大型应用而言,多数都尽可能地要求做到7*24小时不间断运行,而要做到完全的不间断运行可以说“难于上青天”. 为此,对应用的可用性程度一般衡量标准有三个9到五个9. 对于一个功能和数据量不断增加的应用,要保持比较高的可用性并非易事.为了实现高可用,付钱拉从避免单点故障.保证应用自身的高可用.解决交易量增长等方面做了许多探索和实践. 在不考虑外部依赖系统突发故障,如网络问题.三方支付和银行的大面积不可用等情况下,付钱拉的服务能力可达99.999%. 本文重点讨论如何提高应用自身的

系统高可用

讨论系统高可用时,我们在讨论什么? 系统高可用,或者说系统的可用性,在计算机领域是一个相当久远并且重要的概念.小到CPU芯片.内存.硬盘等硬件组件,大到支付宝.微信等日常互联网服务,在设计.开发.维护的时候,都离不开对它的考量.本文首先介绍跟系统可用性相关的关键概念,然后讨论高可用系统的评价指标. 系统和模块 一个系统的可用性,由组成这个系统的模块的可用性,以及模块之间的关系决定.模块可以看成一个系统,由更小的子模块组成,而系统可以看成一个模块,从而组成更大的系统.所以计算机系统的可用性,可以一

亿级流量电商详情页系统的大型高并发与高可用缓存架构实战

对于高并发的场景来说,比如电商类,o2o,门户,等等互联网类的项目,缓存技术是Java项目中最常见的一种应用技术.然而,行业里很多朋友对缓存技术的了解与掌握,仅仅停留在掌握redis/memcached等缓存技术的基础使用,最多了解一些集群相关的知识,大部分人都可以对缓存技术掌握到这个程度.然而,仅仅对缓存相关的技术掌握到这种程度,无论是对于开发复杂的高并发系统,或者是在往Java高级工程师.Java资深工程师.Java架构师这些高阶的职位发展的过程中,都是完全不够用的.技术成长出现瓶颈,在自己

案例二(构建双主高可用HAProxy负载均衡系统)

在案例一介绍HAProxy高可用负载均衡集群架构中,虽然通过Keepalived实现了HAProxy的高可用,但是严重浪费了服务器资源,因为在一主一备的Keepalived环境中,只有主节点处于工作状态,而备用节点则一直处于空闲等待状态,仅当主节点出现问题时备用节点才能开始工作.对于并发量比大的Web应用系统来说,主节点可能会非常繁忙,而备用节点则十分空闲,这种服务器资源分布不均的问题,也是在做应用架构设计时必须要考虑的问题.对于一主一备资源不均衡的问题,可以通过双主互备的方式进行负载分流,下面