#研发解决方案#异地多活让商户无感知
郑昀 创建于2018/3/23 最后更新于2018/3/24
关键词：异地多活，扩容，容灾，地域，分布式架构，单元格，分片
提纲：
-
为什么异地多活？扩容，容灾，地域优先
-
异地多活是什么场景？
-
什么样的神操作？
异地多活（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，
@工程师日常：
为啥你感觉工程师木讷响应慢？
