实践高可用

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

  说实践之前先说概念。

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

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

  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 条评论
登录 后参与评论

相关文章

来自专栏微信终端开发团队的专栏

关于Android N的那些事

今年3月,Google破天荒提前半年发布了Android N开发者预览版。当然,作为一个不合格的谷粉并没有第一时间体验安装,因为至今仍然能够回忆起来去年今日此门...

2786
来自专栏程序人生

停下来,歇口气,造轮子

上周四至今,我大概有 50-70% 的时间在造一个轮子,一个叫 merlin 的工具。 事情的起源是这样的 —— 我们内部的一个重要服务,要升级到 elixir...

35716
来自专栏LET

CPU简介

2769
来自专栏大数据文摘

去IOE的另外一条路径:全内存数据库弯道超车

1698
来自专栏企鹅号快讯

什么样的密码才是安全的?

什么样的密码才是安全的?相信这样的老生常谈你已经听腻了:密码设置得长一些,混合数字字母符号,避免任何可能容易联系到你本身的密码。但现实是在街头调查中大多数人并没...

1896
来自专栏编程一生

IO和socket编程

1153
来自专栏一个会写诗的程序员的博客

20+个很棒的Android开源项目

20+个很棒的Android开源项目 本文摘自文章: 20+ Awesome Open-Source Android Apps To Boost Your D...

1102
来自专栏小狼的世界

HTTP2.0之战

2009年,Google提议HTTP协议的举动引起了工业界的大讨论。当时的概念叫做 SPDY,时至今日,虽然人们对于Google的动机始终不是很清楚,但是毫无疑...

1022
来自专栏大数据和云计算技术

3D Xpoint

3D Xpoint 3D Xpoint这个东西比较新,但是可能对未来软件架构带来深刻的影响和变更,本节简单介绍下3D Xpoint到底是什么。 原理 3D Xp...

2979
来自专栏take time, save time

python 爬虫 入门 commit by commit -- 前言&&准备篇

"每一个commit都是程序员的心酸,哦不,心路历程的最好展示。" -- by 我自己

2172

扫码关注云+社区