#研发解决方案#异地多活让商户无感知

郑昀 创建于2018/3/23 最后更新于2018/3/24

关键词:异地多活,扩容,容灾,地域,分布式架构,单元格,分片

提纲:

  1. 为什么异地多活?扩容,容灾,地域优先

  2. 异地多活是什么场景?

  3. 什么样的神操作?


 

    异地多活(multi-idc-live)是杨海波主设计、刘勤红主导的项目,3月21日在线下环境测试通过,3月23日面向全员做了场景和接入讲解,张振坤做了云小盒收银和退款演示。

 

一.WHY

有人会问,为什么要做异地多活?阿里云还能挂掉?!

云纵现阶段做异地多活,主要有三个目的。

 

第一,扩容。

扩容有两种办法。

 

第一种,单IDC架构。

应用分层(Web层,缓存层,中心层,中间件层,存储层),每一层可伸缩,比如订单中心可以横向加节点,10个不够,加到20个。这也是我们自2011年以来的七年里所实践的扩容模式。

随着业务量爆发,这个模式的缺点会愈来愈凸显。节点不可能无限制地增加下去。流量入口的负载均衡节点将成为瓶颈(Nginx、SLB、F5……)。服务可能出现雪崩,一损俱损,连累其他的用户和商户,连累其他的业务。

举个例子,我们做团购商城的时候,全国有很多薅羊毛的团购代理,比如团购导航公司或淘宝店主,就会注册很多代购帐号,囤积大量的代金券,他们的用户把钱付给他们,他们通过代购帐号购买各大团购公司的团购商品。这些大帐号登录之后,就会随机卡住用户中心、订单中心、优惠券中心等集群的线程,拖慢他们所在的数据库分片节点处理能力,最后所有人都感知到服务变得超慢。

 

第二种,多IDC架构。

将业务封闭在一个个逻辑单元内,然后在多地部署多个这样的逻辑单元,满足了业务对容量和容灾的需求。这也是我们正要前往的领域,单元格部署方式。

所以,十万个商户,两个单元格搞定,一百万商户,二十个单元格,妥妥的,互不影响,业务隔离。

 

问题来了。

这二十个单元格都放在一个机房里,有何不妥?

 

首先,大家总觉得扩容不就是,有钱任性,说加节点就加了嘛。

可惜。并不是说有光就有光。

自建IDC机房,机柜空余容量是有限的,并不是你今天说要几个机柜就能租给你几个机柜。没有机柜,你买的机器搁哪儿。

阿里云,扩容节点多的话,也需要提前通知客服,有点像你去银行兑换外币,得预约!

其次,要考虑容灾。

 

第二,容灾。

分布式系统的维护者总会反复问自己:

我们的系统什么情况下会挂?假如机房挂了怎么办?假如一个城市停电了怎么办(洪水,海啸,地震,滑坡,……)?业务高峰期怎么降低灾难影响?

所以,很多互联网公司都会在多个城市同时支撑商户和用户交易,并且能做到在一个城市所有机房瘫痪的情况下,能够在几分钟内恢复(或者继续新的)所有的交易。

 

小朋友会问,机房真的会挂吗?

请先阅读一下我写的《经历不可抗力是一种什么体验》,了解一下什么是 too young too naive。

然后我们再来回顾一下:

A,2017年1月,公有云 UCloud 公司正在开年会,结果在他们北京B可用区的数据中心外3公里处,架空光缆线杆因卡车撞倒导致光缆断裂,工程师在年会现场紧急处理,如下图所示:

 

B,2015年6月21日上午9点到10点之间,一些使用阿里云香港数据中心的用户发现服务出了问题,此后阿里云公告称由于运营商电力问题造成香港机房故障。因为供电系统故障导致数据中心大楼整体断电,并触发消防报警。根据当地的消防规定,必须彻底排查隐患并完全消除后,才能获准进场做电力抢修。直至当晚21点22分机房正式恢复稳定供电,阿里云立即执行既定预案逐项恢复服务,21点32分安全防护服务恢复正常,各项服务陆续恢复,截至23点39分全部服务恢复。

 

C,2015年9月1日,阿里云官方发布致歉公告,称“因云盾安骑士server组件的恶意文件查杀功能升级触发了bug,导致部分服务器的少量可执行文件被误隔离”,但造成影响无法估量。

 

D,2016年7月6日,上午10点22分,阿里云华北2地域可用区A由于网络设备出现异常,导致部分产品访问受到影响。故障持续约1小时。

 

E,2016年10月11日,下午16点40分,阿里云华东一区部分服务器故障,导致网络上部分网站无法运行。

 

灾难,总是在你意料之外。

所以对于技术高级干部来说,必须回答这个问题:如果单机房物理不可访问,你怎么办?

 

第三,地域优先访问。

随着商户覆盖越来越广,对交易延时的要求也越来越高,我们肯定是希望北方商户优先访问北方机房,南方商户优先访问南方机房。

这天然就是多IDC架构分片模式的需求。

 

所以,目标很明确了。

在灾难还没有降临之前,在商户还在可控范围之内的时候,我们必须悍然先行进入异地多活的领域。

放心,我们一定会遭遇引入异地多活而带来的各种技术故障……

 

二.HOW

听起来很玄幻,那么异地多活到底是什么场景?

假定我们有阿里云北京机房和上海机房,分片(即单元格)有四个:BJ-01,BJ-02,SH-01,SH-02。

 

那么,异地多活有这样的四个场景:

 

场景一,将某个商户从分片 BJ-01 划拨到 BJ-02。

证明我们控制的最小粒度是商户。

 

场景二,北京机房可用,但 BJ-01 分片出现问题,将 BJ-01 上的商户整体切换到 BJ-02 上。

 

场景三,北京机房不可用。摘除北京机房所有流量,将北京机房的所有商户整体切换到上海机房的分片SH-02。

这里面有一个扩容步骤。即,一键点击,就能将上海机房 SH-02 分片扩容,避免被打垮。

这一切不影响原有SH-01上的商户,灾难影响范围越小越好。

 

场景四,北京机房灾后恢复。将商户切换回北京机房。

 

三.WHAT

一键搞定,听起来很奇幻,怎么操作呢?

¯\_(ツ)_/¯

略。

 

至此,异地多活讲解完毕,切换过程相当地魔幻,弹指一挥间,流量就切了,容就扩了,商户无感知,该收银收银,小盒子工作无碍。

 

-EOF-

 

语录若干:

1,

问:文章中讲到的问题都是大公司的,对小团队来说,什么时候应该开始建立自己的基础研发体系?

支付宝侯振宇答:研发体系的建立可以分为规划和实施两个阶段。规划的话,从一开始就应该有所规划。在前期人力不够的情况下,不用强行追求打造自己的框架和工具,可以用开源的。但应该始终把开源的东西拿到自己的体系中,清楚地知道它在自己体系中的角色,也清晰地知道自己用了它的什么特性,未来还需要补充什么。什么时候开始实施其实有一个象征性的标准,也是我们前面在无序的力量中提到的——出现了不同环节的分工时。有的团队业务扩张太快,人力一直不够,那么建议按五分之一到三分之一的比例来抽出人力打造基础设施。磨刀不误砍柴工,何况投资得到的回报是电锯呢。

 

2,

@玉伯:

带团队的这几年,越来越笃定 Leader 最重要的三件事情是:内心有相信并让人相信、让事情发生(make things happen)、保持谦卑与善良。

 

3,

@蔡学慵:

面试技术人员,其实很困难,因为技术人员常常不擅长表达。有时候你要挖掘半天,才能挖出他的能力,才知道其实他是个能力很好的人。所以技术面试的时间可能要长一点。

 

4,

@梁斌:

创业是一个99死1生的事情,是一个不断否定自己,纠正自己,升华自己的痛苦过程。 曾经和某著名运动员会谈,我问她顶级高手怎样达到?她告诉我一句话,久久难忘。“没有明显弱点,但需要有一手绝活”。创业失败者大多是都是某一个短板不断积累问题导致崩溃的,所以要补短板,同时要配置核心竞争力。

 

5,

@工程师日常:

为啥你感觉工程师木讷响应慢?

 

posted @ 2018-03-30 16:58  旁观者  阅读(1418)  评论(0编辑  收藏