实践高可用

简介: 实践高可用

 本篇文章是之前一篇《大话高可用》的高可用心法的案例篇。


  说实践之前先说概念。


  业界可靠性和可用性的衡量标准:


1112728-20180405143537223-823657476.png


1112728-20180405143617825-5154764.png


1112728-20180405143646855-274574273.png


 将可用性做一个目标分解即为:


  1. MTBF:发生频率要低


  1. MTTR:故障恢复要快

 

  先考虑发生频率低的问题。就是怎样别人死我们不死;自己不作死;不被队友搞死。故障恢复要快,那就需要事先做好应急备案,快速准确的监控报警,故障时快速切换备案。具体实践如下:


架构高可用


  交易这边进行在进行重构。将原有的核心交易从职责上划分为交易收单、交易保障和数据中心三个大块。


  从高可用上,交易收单要保证实时交易现场的可用。除了交易现场必需的事情,其他什么都不做。除了发号器、加密器、监控报警等自身必需的中间件外,不使用其他与其他端通信的中间件。核心策略是去依赖。主要考虑点在MTBF。


  交易保障的定位是交易现场完成后一切让交易数据正确的工作都是交易保障的工作。为了可以高效的及时修补数据、检测交易数据与各个端的一致性就需要适当用到一些中间件和交易收单进行通信。这就有依赖关系了。有依赖就要容灾。如果一个中间件出现问题了,就切换另外一个中间件。用的是同一个中间件,只是在不同的机房,这就是机房互备容灾。如果是不同的中间件,就是旁路容灾。都行不通怎么办?数据库轮询兜底,这属于降级容灾。对交易来说,交易保障为后续结算提供准确的数据,只要定时结算的时候数据是准确的,主要考虑点在MTTR。


  最后说数据中心。交易除了完成交易现场和为结算提供准确数据外,一定还会有其他的产品上的需求。各种查询需求、统计需求、营销需求,商家消费成功语音提示等。各方都会需要各种形式的和实时性要求不同的数据。数据中心的定位是所有交易不干的活儿它都干。所以它才是对高可用需要考虑最多的,对MTBF和MTTR都要考虑和权衡。但是在对高可用要求上交易收单和交易保障是基本职责,指标就是稳定、稳定和稳定。数据中心关乎的用户体验,是可以持续优化的,但是对高可用是有一定容忍度的:比如页面会加载慢,或者第一次加载不了刷新就成功了。


1112728-20180405155333276-477667863.png


强依赖高可用


  比如数据库的密码,不仅是加密的,而且是在中央集群秘钥管理中心统一管理的。中央集群的就会有秘钥获取不到的风险。按照API,如果获取不到则会抛出指定异常。


  这是强依赖,需要容灾。首先,中央集群的,服务端有可能会升级。升级如果出现问题,在转换的时候没有抛出约定的异常怎么办?比如实际上获取不到抛出了空指针。空指针是非检查异常,不需要被显示处理。所以对这种中央集群的我们都全部捕获Exception父类,所有的异常。


  出了异常了怎么办?一种是秘钥我们在客户端缓存一份,重启时服务端获取不到则加载本地的。如果安全性要求高,不允许堆栈外本地缓存呢?我们的策略是一损俱损。就是如果任何依赖加密器的都是启动时加载。如果加载失败则服务根本启动不起来。我们发版启动都是在低峰期,服务器有足够的余量。发版的并行执行机器数不超过3台。3台服务启动不起来对系统没有影响。实现了无损容灾的目的。


1112728-20180405161531409-125779777.png


有损降级


   我理解的降级:


    从整体负荷考虑,人工的或者自动的对部分服务进行低优先级的处理。手段主要有:拒绝服务、关闭服务等。

 

     实例-牺牲部分业务逻辑的降级:


  之前在乐视做媒资后台,遇到如果说某剧热播,访问量巨大。此时万一无法支撑,我们的策略就是有损降级。核心保证访问量大的单视频调用接口。停止对访问量小,却对缓存压力很大的列表接口的服务。


  看过其他公司的一些架构,他们都会在大促来临之前对非核心服务主动降级,以集中资源进行资源调配。

 

  实例-容错降级:


  容错降级是一个很宽泛的概念,限流、超时、重试、熔断、故障隔离都属于容错的范畴。下面就拿限流举例讲一下实现时考虑的方面。


  我理解的限流:


    限流目标:限制业务上游突增异常流量


    限流原则:1>评估系统性能瓶颈、接口流量比例2>保障业务正常流量同时留足增长空间

 

  针对我们交易系统:


         总目标:可以有损,不允许宕机


         具体目标:


  • 维度一:


  • 集群不死


  • 单机不死


  • 维度二:


  • 异常流量下线程池不被打满


  • 异常流量下CPU不得高于75%


  • 异常流量下FULL GC1分钟不得超过5次


  • 异常流量下数据库连接数不得达到上限


  • 异常流量下负载不得超过2


  • 异常流量下线程不得被block


  • 异常流量下磁盘IO不得超过7


  • 维度三:


  • 不对业务方单独限流,各个业务方如果有流量异常及时报警


      交易限流原则:


  • 每月压测后重新限流阈值评估


  • 单机QPS 10起步,集群QPS<=(单机房机器数-1)*单机QPS. 原因:应对


  • 机房不可用和负载不绝对均匀问题


  • 需小于压测峰值,大于2倍的月底预估容量


  • 需大于目前最高峰的2倍


  • 待下线接口维持当前最高峰值1.5倍


  • 所有接口总阈值不得超出压测值. 原因:以防数据库瓶颈


1112728-20180406201635715-658272751.png


总结与思考:


  嫉妒是看到别人某方面好,觉得自己也可以这么好却不愿意为此努力


  自负是嫉妒某方面,就在其他方面打压别人


  自信是面对自负者的打压,痛则思变

相关文章
|
Oracle 关系型数据库 MySQL
OceanBase实践入门:高可用原理和容灾方案
OceanBase的多副本(奇数)设计,以及使用Paxos协议同步事务日志,是OceanBase高可用能做到自动切换(RTO约20s)和不丢数据(RPO=0)的关键。OceanBase在这个设计上还衍生出很多特性:如负载均衡和异地多活等。
5565 0
|
4月前
|
Kubernetes 应用服务中间件 nginx
搭建高可用k8s
搭建高可用k8s
85 6
|
5月前
|
负载均衡 监控 网络协议
高可用架构设计
高可用架构设计
244 1
|
存储 负载均衡 监控
高可用
当今数字化时代,高可用性已经成为许多企业和组织的重要关注点。无论是云计算、大数据、电子商务还是日常生活中的各种应用程序,高可用性都是确保系统稳定运行和用户满意度的关键因素。本文将深入探讨高可用性的概念、重要性以及实现高可用性的方法。
|
6月前
|
消息中间件 缓存 数据库
高可用之故障隔离
【2月更文挑战第21天】
|
弹性计算 负载均衡 关系型数据库
部署高可用架构
本场景主要介绍如何使用云服务器ECS、负载均衡SLB、云数据库RDS和数据传输服务产品来部署多可用区高可用架构。
部署高可用架构
|
存储 运维 Kubernetes
Kuberntes云原生实战一 高可用部署架构
Kuberntes云原生实战一 高可用部署架构
277 1
|
存储 安全 NoSQL
|
消息中间件 监控 算法
高可用怎么设计呢
《高可用》系列
181 0
高可用怎么设计呢
|
调度 容器
在CCE中实现高可用部署
在CCE中实现高可用部署
566 0
下一篇
无影云桌面