弘协网络 | F5技术交流

博文精选 | 系统高可用原因分析 & 方案

2021-08-27 09:41:32

F5小安

PHPWord

文章速览:

 

行业:互联网

 

关键字:系统、高可用、架构、运维、技术、方案、系统稳定

 

摘要:保持系统高可用涉及到众多技术,涉及架构层面、运维层面。一个系统如何做到高可用,完全根据业务决定的。设计高可用系统时要注意投入产出比,不要一味追求高可用而浪费过多人力物力。设定可用性指标时,要目标明确,分析系统在特定环境下具体问题和风险,设计简单高效的方案来达成目标。

 

阅读时长:8分钟

 

 

以下文章来源于InfoQ!作者:Mars

 

 

导致系统不可用的原因有哪些?保障系统稳定高可用的方案有哪些?请分别列举并简述


 

可用性度量


对可用性的定性描述,两个 9 是基本可用;3 个 9 是较高可用;4 个 9 是具有自动恢复能力的高可用;5 个 9 是极高可用,年度停机小于 5 分钟,这个需要运气,因为造成系统不可用的因素实在太多。

 

影响系统高可用的因素


l  硬件故障


l  软件 bug


l  系统发布


l  并发压力


l  网络攻击


l  外部灾害

 


高可用系统架构方案



解耦


l  高内聚、低耦合的组件设计原则


l  面向对象基本设计原则


l  面向对象设计模式


l  领域驱动设计建模


隔离


l  业务与子系统隔离


l  微服务与中台架构


l  生产者与消费者隔离


l  虚拟机与容器隔离


异步


l  多线程编程


l  响应式编程


l  异步通信网络编程


l  事件驱动异步架构


备份


l  集群设计


l  数据库复制


l  CAP 原理


Failover(失效转移)


l  数据库主主失效转移


l  负载均衡失效转移


幂等


服务重复调用时不可避免的,必须 保证服务重复调用和调用一次产生的结果相同,即服务具有幂等性。


事务补偿


l  传统事务 ACID


l  分布式事务 BASE


基本可用(Basic Availabilty),软状态(soft-state)、最终一致性(Eventual-consistency)


通过执行业务逻辑逆操作,使事务回滚到事务前状态。


重试


远程服务由于线程阻塞、垃圾回收或者网络抖动,而无法及时返回响应,调用者可以通过重试的方式修复单次调用的故障。


上游调用者超时时间要大于下游调用者超时时间之和。


熔断


当某个服务出现故障,响应延迟或失败率增加,继续调用这个服务会导致调用者请求阻塞,资源消耗增加,进而出现服务级联失效,这种情况使用断路器阻断对故障服务的调用。


断路器三种状态:关闭、打开、半打开


限流


在高并发场景下,如果系统访问量超过系统承载能力,可通过限流进行保护。如果超过系统最大处理能力,就会丢弃一部分用户请求,保证大部分用户能够访问系统。


限流几种算法:


l  计数器算法(固定窗口、滑动窗口)


l  令牌桶算法


l  漏桶算法


自适应限流


实时自动评估 QPS。


业务流量的不确定性与技术方案的自适应性天生一对。


 

降级


非核心功能关闭,减少系统压力。


异地多活


如果数据中心城市遭遇地震,机房遭遇火灾或停电等不可控的因素,一般采用异地多活多机房架构策略,异地多活难点是数据一致


 

高可用系统运维


自动化测试


目前大部分网站采用 web 自动化测试技术,使用自动测试工具或脚本完成测试。比较流行的 selenium 运行在浏览器中,模拟用户操作进行测试,可以同时完成 web 功能测试和浏览器兼容测试。


自动化部署


开发人员开发完功能后,提交代码到 git 仓库,自动测试部署。


持续部署三步走


l  持续集成:允许工程师随时向公共分支提交代码,并立即进行自定化测试。


l  持续交付:除了跑单元测试及软件包,持续交付机制会将软件部署到各种测试环境中。


l  持续部署:代码在没有人工干预的情况下被测试、构建、部署并推送到生产环境。


预发布验证


预发布机器是一种特殊用途服务器,和生产服务器的区别是没有配置在负载均衡服务器上,外部用户无法访问。


代码版本控制


主干开发、分支发布


代码修改都在主干上进行,需要发布时,从主干上拉一个分支发布,该分支即成为一个发布版本,如果该版本发现 bug,继续在该分支上修改发布,并将修改合并回主干,直到下次主干发布。


分支开发、主干发布


任何修改都不得在主干上直接进行,需要开发一个新功能或修复一个 bug 时,从主干拉一个分支进行开发,开发完成测试通过后,合并会主干,然后进行主干发布,主干上代码永远是最新发布的版本。


自动化发布


灰度发布


将服务器集群分成若干部分,每天发布一小部分,期间如果发现问题,就只需要回滚已发布的一部分服务器即可。


灰度发布不只保障系统高可用,还保障系统业务的持续发展。


网站运行监控


尽早发现问题,为问题发现提供数据查询。


用户行为日志收集


日志收集手段有 2 种:


l  服务端日志收集


l  客户端浏览器日志收集


报警


       监控管理系统可以配置报警阈值和值守人员,报警方式包括:邮件、手机短信、手机语音,及时在夜间也能及时通知,迅速响应。


自动控制


l  自动失效转移


l  自动扩容


l  自动限流


总结


保持系统高可用涉及到众多技术,涉及架构层面、运维层面。一个系统如何做到高可用,完全根据业务决定的。设计高可用系统时要注意投入产出比,不要一味追求高可用而浪费过多人力物力。设定可用性指标时,要目标明确,分析系统在特定环境下具体问题和风险,设计简单高效的方案来达成目标。


 

 

以上是针对系统高可用的分享,希望对大家有帮助!

 

 

 

阅读原文

 

声明:本文章版权归原作者及原出处所有 。凡本社区注明“来源:XXX或转自:XXX”的作品均转载自其它媒体,转载目的在于传递分享更多知识,内容为作者个人观点,仅供参考,并不代表本社区赞同其观点和对其真实性负责。本社区转载的文章,我们已经尽可能的对作者和来源进行了注明,若因故疏忽,造成漏注,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本社区拥有对此声明的最终解释权。

 

 

 

你还不能错过:

 

如何善用缓存提升系统的健壮性?(上)

发布评论 加入社群

发布评论

相关文章

金融行业47个场景-AIOps智能运维

Will Tang

2021-03-18 14:31:18 664

“验血”的价值

常旭

2019-10-22 21:34:00 630

Login

手机号
验证码
© 2019 F5 Networks, Inc. 版权所有。京ICP备16013763号-1