关于阿里巴巴技术保障部在集团内部的地位，与阿里云的密切关系，为何连续多年天猫双十一总指挥都是技术保障部负责人刘振飞（现阿里巴巴集团首席风险官），以及他们今年在数据中心领域的突破性实践，可以先看下这三篇文章 《阿里技术保障部：阿里云的幕后英雄》、 《阿里11.11第六年,用我们的视角直播技术与数据》和 《千岛湖数据中心详解》。而对今年支持天猫双十一背后最新技术的观察，这篇或是一个新的窗口。
当在2015杭州云栖大会上看到阿里巴巴技术保障部研究员毕玄时，首先闪过脑海的就是又有“干货”了。
毕玄，2007年加入阿里，到现在已经8年时间。其中，2008-2010年在淘宝平台架构部负责HSF的设计和实现，2011年在数据平台部负责Hbase改进和落地，2012年在核心系统部负责淘宝虚拟化产品和技术，2013年到技术保障部，专注于应用可维护性、稳定性、软硬结合，主要负责能容量架构、异地多活项目（以确保当故障出现时快速恢复）和研究如何通过软件来降低总体成本（硬件是另外一位保障部门同事负责）。
在他看来，当阿里集团的双十一规模越来越大，与平时量差距越来越多时；当因双十一而产生的投入成本越来越高，且不可控因素提升时；当数据已经积累到绝对的大数据时……，如何减掉双十一的峰值投入成本？如何计算出更多的数据价值？是技术保障部门所要重点考虑和实践的。而实践成果已有很多，其中最夺目的是“三活”。
CSDN：2015天猫双十一指挥部将移师北京，但作战部还在杭州。对技术保障部有影响么？你在其中会负责什么？
毕玄：影响不大。我现在负责技术保障性能架构团队,今年负责的最重要的项目就是多活，去年我们做到了异地双活（详见阿里超大数据中心“异地双活”实践），今年是异地三活。和去年双活相比，今年最大变化是去年两个点相隔的距离比较近，今年第三个点距离非常远（1000公里以上）。我们真正从比较近的异地，走到了更远的异地，也证明我们在全国范围内已经可以选任意点部署阿里交易系统。从技术来看，2到3是质的变化，挑战极大。而未来从3到4，相信就会比较顺畅了。
CSDN：从“两地三中心”、“同城双活”到“异地双活”，这方面的尝试很多企业都在做。但“三活”很少。分享下其中遇到的困难和挑战？
毕玄：除了我们，确实还没有看到国内其他企业做出“三活”。挑战很多，也很大。第一大问题就是距离带来的延时问题，去年双活的情况下两点的延时是在10毫秒以内，今年的距离物理延时会比去年多好几倍。我们的系统是一个巨大的分布式系统，访问任何一个淘宝的页面，其实背后的交互都在上百次，单点延时再乘上这个倍数，如果不能很好的解决延时问题，说不定用户连页面都打不开，更不要说双十一那么高的访问量的情况下。所以延时问题是多活中一定要解决的核心问题。因为随着距离越远这个问题会越大，去年的距离不算太远，有些问题没有足够的暴露出来。而在今年在建设另外一个较远的点的时候，就已经看到去年忽视的某些问题被再次放大出来，必须解决。
第二大问题是数据一致性。活和以前金融行业的冷备做法不一样，冷备其实只有一个数据库是可写的，因为只有一个点是可以写的，保证了数据不会错乱。多活以后则变成多个点都可以写，如果两个点同时写了一个用户的同一行数据，那这个时候就无法判断合过来的时候，到底哪边的数据是对的，这是一个很大的问题。阿里平台上都是交易，和社交及搜索都不一样，因为涉及到资金，任何错误都会影响用户信任。
所以在多活实践中，延迟问题相对可控，也许只是用户响应时间从1秒变成3秒，影响体验，但数据一致性是最要保住的点，因为这影响信任。当然我们希望都能保证。
实际上，去年双活中已经积累了很多经验，但双活数据复制的复杂程度比多活要低，因为两点是对等的，两边都100%，为了能够切走，流量可以从这个中心切到另外一个数据中心去。但是在三点的情况下一定不是这样的，一定会变成不对等的状况，数据复制的逻辑就更加复杂，所以我们做了很多架构设计和开发工作，并且已经很好解决这些困难了。
CSDN：刚提到双活没有暴漏出的问题，还有哪些？
毕玄：主要解决延时问题，尽管去年用户层面感知不到，但今年距离变长，延时会增加好几倍。比如测试阶段向第三个点引流的时候，我们发现某些功能点明显不能用，会超时。解决这个问题的方法就是尽量避免跨数据中心调用，我们就通过工具软件分析，比如你访问这次页面背后要交互100次，这100次交互有多少次是要跨出数据中心去访问的，然后再做应用调整，确保用户单次操作背后的所有调用都在同一个数据中心内。因此解决延时问题的挑战不在于技术难度，而在于技术的复杂度，因为会涉及的几百甚至上千个系统，要通过有效的工具和反复的演练确保没有遗漏。
CSDN：多系统演练一向是双十一技术预案的重点（去年双11，阿里准备500多套技术预案，前年是2000多套）。今年的多活演练已经完成？
毕玄：多活搭建远早双十一，基本在双活完成以后我们就开始做多活的规划了。刚才介绍，延时最大的问题在于一个页面展现的过程中有多少次在跨出数据中心去访问，需要强大的系统而不是靠人解决，所以我们不仅靠预案，更要靠精密的雷达系统，这套系统实时告诉我们那些调用跨机房了。然后再由经验非常丰富的工程师介入分析，为什么会出现跨机房调用，怎么解决。简单的情况只需要做一下部署，复杂的情况就需要认真分析怎么处理数据。
对于异地多活架构，在双十一当天不会因为延时去启动预案，必须在双十一之前就要把这些问题全部解掉。在阿里，我们现在已经不太谈灾备的概念了，而是通过多活的架构保障高可用性，原因是灾备主要靠冷备，真的出现问题的时候，基本没人敢做切换的决策，因为不知道切换一次要多久，也不知道切过去能不能用，一旦切换也不能恢复业务，那就悲剧了。但异地多活架构不一样，因为每个数据中心都一直在提供服务的，我们现在每天都可以根据业务需要，在多个数据中心之间调度淘宝的流量，我今天中午来之前就刚刚做过一次切流。但我们的动作，用户是不会有任何感受的。所以对多活架构来说，我们能做到如果一个数据中心出问题，就敢把流量直接全部迁走。
实际上，双活2014年8月就完成了，也成功了支撑了去年的双11，三活其实也跑了很久了，基本没有什么问题。我们很早就启动了今年的双11技术准备，包括数据中心布局、软件重构等，都已经落地并作了多次演练，现在主要是打磨细节。
CSDN：具体技术细节举例分析下？
毕玄：保证数据一致性，多点同时写就必须把数据库做切片，确保这个用户在这个时间必须写入这个数据中心，保证逻辑正确不变。但要确保这件事的发生，我们在技术上做了多层保护。首先，一个用户的流量进来后会有很多应用层，每一层都有可能进来之后可能进到不同数据中心，我们在每一层都做好拦截保护，每一层都看看你是不是应该在这一层，如果不在的话我们就把你引到正确的一边，即使你进来的时候访问错了，比如你应该在B数据中心，但是你进到A的数据中心去了，但当你访问一个页面，你进来我们会发现你不在这个数据中心，就会把你跳过去。其次，容易引发数据错乱的另一个原因是多活的情况下如果要做到可以切流量，就意味着我的每个数据中心一定会有数据的冗余，那在一定冗余的情况下怎么来保证。为什么双活的情况下问题会更加简单，是因为双活两边数据中心是对等的，就不会循环复制。但在三活的情况下则要注意避免这个问题，保证数据复制的方向正确、路径正确，我们会层层保护用户数据写入正确的数据中心。
第三，切流量的过程也需要注意，避免数据错乱。如果没有控制好这个过程，你认为在那个数据中心还继续写，事实上那个数据中心已经不用了，这个时候永远看不到你的数据。怎么保证这个过程一定不会出问题？分布式系统的整个切换过程是非常复杂的，意味着层层都要感应到这一次切换，如果没感应到可能出问题，也可能不会出问题，我们为了做到数据保护在背后做了很多的事情。我们会检查每个点的数据是不是符合我们想要的规则，假如我希望这个数据中心有一定百分比的数据，还有可能是特定用户的数据，那我们都会去检查，如果你合适的话，那我们会立刻知道是有问题的。除了数据检测之外还会做业务层面的检查，如果发现你在A数据中心和在B数据中心买的两个东西的价格是不一样的，同等的两个身份的人，如果两个点看到的价格是不一样的，显然是有问题的。我们从业务层面以及本身数据层面都会做这些处理。
CSDN：雷达系统和监控监测系统是基于什么开发的？
毕玄：雷达系统和监控监测系统不基于任何平台，没有任何外部的系统，就我们纯粹自研的系统。雷达系统是阿里自研的eagleeye。eagleeye和监控监测系统都是基于Java自研的。为什么对阿里而言，双活和多活都是大的技术挑战。就是因为淘宝之前的架构改造是有一定参考对象的。但在双活和三活改造中，我们碰到的所有的问题都是没有参考对象的，只能靠自研的，在自研的过程中碰到问题知能自己解决，开源软件都不涉足这个领域。
CSDN：从体量和规模来说，谷歌、Facebook是否有相关经验？
毕玄：谷歌、Facebook在多活架构上面临和我们一样的挑战。但阿里的业务类型要比社交和搜索都复杂。对社交而言，一个用户的数据其实都是你用户之间相关的数据，但是一个电商网站数据的特征是除了你自己的数据以外，比如我访问淘宝除了我自己的数据以外，我需要知道商品的数据，知道卖家的数据，而社交并不需要如此，所以他们可以采用异步，而延时对异步是没有影响的，但是对同步就是很大的挑战。但交易网站，整个过程必须同步的，因为只要不同步，这个用户就丧失购买兴趣了。比如你拍一个东西，点了购买，告诉你要稍等一下让我后面确认一下，然后我再给你展示，你再来买，用户立刻就不买了。
CSDN：要实现双活或者多活的技术朋友们分享下你的经验？
毕玄：做这件事情我们用了三年，从单机房到多单元，到同城双机房，到异地双活，再到今年异地多活，整个投入非常巨大，而且要有很好的节奏控制。毕竟，这对于我们来讲，是为一个飞行的飞机换引擎的过程，在做这么大规模的架构改造的同时，不能对业务有任何影响。异地多活，确实会影响数据中心的布局，所以随着变化要控制好节奏。技术经验方面，要有强大的分析系统来控制延时问题，如果连跨出去多少都不知道，是无法处理的。此外，业务方面，如果要做到在本地的数据中心完成动作，一定意味着除了访问之外，怎么让依赖的数据尽可能在本地。
CSDN：可以再详细展开下？
毕玄：也许我们前一轮的架构改造对更多企业有更多的意义。异地双活除了数据中心、网络层，软件层面的技术投入也是巨大的。因为其不是一个通用方案，而是结合业务所做的动作，这就需要原有的基础软件都要改造才能支持。所以人力和投入都是很大的技术改造。对很多规模略小的企业而言，在业务没有迫切需求的时候，异地双活只是需要关注的方向。而同城双活比较现实，意义也更大。因为很多创业公司最害怕的是服务不可用，比如之前滴滴快的打仗的时候就很明显，一旦一家出现服务问题，用户量很快就会飘移到另一家。好多情况为了打这一仗前期已经投入了很多市场的费用，钱已经花出去了，结果“军火”（技术平台能力）不够。在同城双活的时候，地址访问是要特别重视的问题。两个机房之间的交互，以前的简单方案是我要访问什么系统，就用一个地址去访问的，但在双活的架构架构，地址访问绝对不能出现，因为一旦出现就意味着我切不了，所以这些地方全部都要改造，把跟地址相关的部分被收拢到系统里，这个切换系统是可以全部操作的。像这种项目中最大的其实不是一个技术难度问题，而是一个复杂度的问题，因为当要做这个事情的时候，通常意味着这家公司有一定的规模了，肯定不是一开始就做了。当你有了一定的规模的时候，意味着各种现象都已经出现了，怎么把所有的现象全部解决掉，这是一个最复杂的问题。我们以前做同城双活也花了很长的时间，是经常演练的，我们是靠演练证明我们是可以的，演练了非常多次才成功。
阿里云上的持续交付平台（CRP，Continuous Release Platform)
CSDN：未来会不会将这些开发的系统和经验能够变成标准化产品在云平台上输出？
毕玄：云栖大会上会看到持续交付平台（CRP，Continuous Release Platform)，供软件生命周期全环节服务。包括项目管理，需求管理，缺陷管理，代码托管，开发环境管理，全量构件库管理，持续交付流水线，构建管理，依赖管理，测试管理，一键部署，监控管理，团队协作等功能，就是从开发一直到上线整个过程的云产品。我们的思路不是对外输出一份文档或者讲一个PPT，而是将所有的变成云产品去对外输出，持续交付是其中的一个。而异地多活中，为了保证多点数据同步以及解决时延的自研产品，已经变成阿里云的商业产品——DTS数据传输。我们会慢慢将这些内部已经经过大规模验证过的技术逐步变成云产品对外部的用户开放。实际上，在我们从同城双活走向异地多活中，基本将所有软件都全部改造了一轮，其中也添加了很多基础产品，如DTS，还有内部服务、系统交互、消息服务，都已经在云上。所以对用户而言，不用向我们一样自己摸索在改造，而是直接可以选择这些能够达到异地多活的产品，难度会降低很多。
马上就是双十一，期待阿里巴巴技术保障及其他技术部门更多的精彩分享，也期待更多电商企业的技术实战分享。
【讯】翘首企盼的2015中国大数据技术大会（Big Data Technology Conference 2015，BDTC 2015）将于2015年12月10-12日在北京新云南皇冠假日酒店举办。会期3天，拟邀100多位大数据顶尖专家，共设置16个分论坛。其中包含“数据库”、“深度学习”、“推荐系统”、“大数据安全”、“大数据基础设施”、“大数据生态系统”等6大技术论坛，“金融大数据”、“工业与制造业大数据”、“交通与旅游大数据”、“互联网大数据”、“医疗健康与生物大数据”“教育大数据”、“网络与通讯大数据”等7大应用案例论坛，“政策法规和标准化”、“数据市场及交易”、“社会治理大数据”等3大热点议题论坛。欢迎报名。
本文为CSDN原创文章，未经允许不得转载，如需转载请联系market#csdn.net(#换成@)