实践高可用

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

  说实践之前先说概念。

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

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

  1. MTBF:发生频率要低
  2. MTTR:故障恢复要快

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

架构高可用

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

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

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

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

强依赖高可用

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

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

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

 有损降级

我理解的降级:

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

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

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

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

实例-容错降级:

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

  我理解的限流:

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

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

  针对我们交易系统:

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

          具体目标:

    • 维度一:
      • 集群不死
      • 单机不死
    • 维度二:
      • 异常流量下线程池不被打满
      • 异常流量下CPU不得高于75%
      • 异常流量下FULL GC1分钟不得超过5次
      • 异常流量下数据库连接数不得达到上限
      • 异常流量下负载不得超过2
      • 异常流量下线程不得被block
      • 异常流量下磁盘IO不得超过7
    • 维度三:
      • 不对业务方单独限流,各个业务方如果有流量异常及时报警

      交易限流原则:

    • 每月压测后重新限流阈值评估
    • 单机QPS 10起步,集群QPS<=(单机房机器数-1)*单机QPS. 原因:应对机房不可用和负载不绝对均匀问题
    • 需小于压测峰值,大于2倍的月底预估容量
    • 需大于目前最高峰的2倍
    • 待下线接口维持当前最高峰值1.5倍
    • 所有接口总阈值不得超出压测值. 原因:以防数据库瓶颈

总结与思考:

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

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

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

跑题时间:

烤箱晚餐

  和小鲜肉一起吃烤箱晚餐算是一种亲子游戏。肉啦,菜啦都可以放到烤盘里去烤。但是开烤之前一定要用很多糖、黄油、牛奶、鸡蛋、蜂蜜和面粉和一大块面团。然后和小鲜肉用面团做出各做形状的烤饼。有时候做出鱼的形状。我们就按平时吃鱼的习惯来分配着吃:爸爸吃鱼头,妈妈吃鱼尾,小鲜肉吃鱼肚子。

  烤的是创意和梦想,一起做出来然后装进肚子里。

野菜摊鸡蛋

   春天的习惯,总要带小鲜肉出去摘一次野菜。我总在想我想让小鲜肉经历一个怎样的人生。我希望他是单纯的、快乐的、爱自然的,对周围的美是敏感的。比如四月飞雪时虽然地上雪都化了,但周围的行道树叶子都是新发的,颜色是翠绿的,叶子上的雪是不化的。新绿上的白雪,比花还要美。

  摘野菜是希望小鲜肉认识到地下这些矮小的东西是不同的。小鲜肉不会只摘一种野菜,各种野菜的硬度、温性寒性都不同,理论上食用的烹饪方法也应该区别对待。但是用来摊鸡蛋总不会错。还有一个原因是:野菜很难清洗,洗完后剩下很少,只够当配料而已。

梧桐花蜜

  姥姥家在大山里,院子里有一颗梧桐树。因为上学的时候听说梧桐是贵族的标志,再加上也听老人说我家之前也是大户人家。就一直理所当然的以为那就是李煜词里“寂寞梧桐深院锁清秋”的梧桐。后来上班,在五道口到清华科技园的路上,也有家乡的梧桐树,才知道这是泡桐,而一般说的梧桐是叶缺如花的青桐。

  小时候梧桐开花的季节,大人就把花儿一串串的掏下来,小朋友们爱咂花儿根部的花蜜。后来带小鲜肉回老家,很少能见到梧桐了。只好拿牵牛花给小鲜肉尝尝,总不是儿时的味道。

  缺月挂疏桐,漏断人初静。谁见幽人独往来,缥缈孤鸿影。

  惊起却回头,有恨无人省。拣尽寒枝不肯栖,寂寞沙洲冷。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏后台系统海量服务

自适应柔性模型

“弃车保帅”, 是对柔性的一个最形象的描述。但是传统的柔性,一般存在各种缺陷。

1405
来自专栏视频直播

世界杯直播技术揭秘及视频云直播回源系统的应用

近些年,视频直播应用蓬勃发展,带宽也是日渐新高,腾讯云旗下的视频云直播为斗鱼、快手、虎牙、龙珠、CNTV广大的企业客户提供了很大的支持,在行业内起到了引领的作用...

852
来自专栏SDNLAB

SDN实战团分享(二十八):VMware NSX技术分享

Vmware是虚拟化技术的先驱者,其强大的计算虚拟化产品已经深入了各行各业的日常使用中。当然,如果没有网络虚拟化的支撑,计算的虚拟化是根本玩不转的。 Vmwar...

3645
来自专栏腾讯大数据的专栏

海量终端,秒级送达!腾讯云移动推送信鸽后台探秘

终端单连接 消息推送已经成为APP的标配,要推送就要有长连接,而长连接要靠后台服务来维持。传统的推送实现中,每个APP使用一条长连接,启动一个后台服务,你一个我...

1955
来自专栏领域驱动设计DDD实战进阶

微服务实战(一):落地微服务架构到直销系统(什么是微服务)

网上有很多关于微服务的文章,从不同的维度对微服务进行了相关的讲述;有些高屋建瓴,有些涉及细节,有些侧重理论,有些侧重代码,都是非常不错的了解微服务的文章。

982
来自专栏CSDN技术头条

底层技术大PK!分分钟带你看透区块链和云计算

作者 | 谢文杰、金钰 责编 | 贾维娣 本文转载自 智链ChainNova,已经授权CSDN转载 我们在研究区块链的过程中发现,区块链的发展和云计算有非常多的...

2265
来自专栏IT大咖说

一线工程师宝贵经验:架构的深入思考 From FunData

内容来源:之前作者写了一篇《FunData — 电竞大数据系统架构演进》的文章,传送门:http://t.cn/RdgKWGW 觉得没有深入写出一些深层次的东西...

873
来自专栏SDNLAB

云数据中心网络虚拟化——大二层技术巡礼之控制平面多虚一

控制平面多虚一,指的是将两台或者多台设备的资源(包括操作系统、转发实例、转发表、端口等)进行整合,对外表现为一台逻辑设备,以Cisco VSS,Huawei C...

3535
来自专栏IT大咖说

FunData — 电竞大数据系统架构演进

背景来源:FunData作为电竞数据平台,v1.0 beta版本主要提供由Valve公司出品的顶级MOBA类游戏DOTA2相关数据接口(详情:open.vare...

983
来自专栏沃趣科技

容器化RDS|未来已来

“你不是不够好, 你只是过时了” 这句话用到 IT 行业特别合适, 每隔一段时间都会有新的技术出现, 让码农们应接不暇. 借着回顾 DBA 工作中的几个时期,...

3856

扫码关注云+社区