阿里SRE体系如何支撑24小时峰值压力、220+个国家“剁手党”？
摘要： 淘宝点亮了全中国，Aliexpress点亮了全球，在近百个国家的购物类app排名第一。但AE国际只有1-2个物流，峰值压力一度导致多个国家的银行系统、物流系统瘫痪，可以想象，作为Aliexpress的SRE压力多大。
淘宝点亮了全中国，Aliexpress点亮了全球，在近百个国家的购物类app排名第一。但AE国际只有1-2个物流，峰值压力一度导致多个国家的银行系统、物流系统瘫痪，可以想象，作为Aliexpress的SRE压力多大。
究竟阿里工程师是如何解决这一难题？今天我们通过AliExpress SRE负责人周志伟的分享，揭开这个谜题。
阿里巴巴高级技术专家、AliExpress SRE负责人周志伟
Aliexpress是阿里巴巴集团跨境及国际消费业务，国内大家都知道淘宝，但是走出国门，知道Aliexpress的外国人非常多了。AE在Alexa全球排名前50，淘宝排名11，可以想象Aliexpress的流量当前已经非常庞大。此外，AE在近百个国家的购物类app排名第一。如果有去俄罗斯的旅游朋友可以问问当地出租车司机、餐馆服务员、或者当地路人Aliexpress，相信大多都有在上面购物的经历。
目前Aliexpress有过成交记录的国家覆盖220+，大家都知道双11，淘宝点亮了全中国，而Aliexpress点亮了全球。但AE国际只有1-2个物流，峰值压力一度导致多个国家的银行系统、物流系统瘫痪，爆仓已经不仅仅只有中国才会发生，可以想象，作为Aliexpress的SRE压力多大。
AliExpress（全球速卖通）是阿里巴巴旗下面向全球市场打造的在线交易平台，被广大卖家称为“国际版淘宝”
Aliexpress SRE
SRE在Aliexpress的定义仅仅指与可用性相关，当它指一种技术方面时，是指原来的稳定性的概念；当它用来指团队时，是指各技术团队负责稳定性的同学组成的虚拟团队。在Aliexpress，SRE是由横向的虚拟团队组成，每个业务团队一主一备保障整个Aliexpress的稳定性，只有这样才能最高效和最快速的发现问题根因和解决问题。稳定性是一切一切的基础，所以这个虚拟组织也是得到了众多的资源和KPI基础保障。
阿里国际化SRE的挑战
时差让每时每刻都是高峰期
在全球化的前提下，SRE的挑战是非常巨大的，它的难题和挑战并非淘宝所经历过的，在这些方面我们也并没有太多的参考和借鉴。首先，Aliexpress的用户群体分布来自全球238个国家，不同种族不同肤色。这不是最关键的，因为用户分布不同国家和不同时区，对于Aliexpress来说其实没有真正意义的低峰期，每个国家的高峰时间都不一样，一波接着一波，对我们的产品可用性提出了更高的要求所有国家*7*24。
网络复杂但容不得半点延迟
在中国，我们的网络在三大运营商的扶持下可以说是非常不错的，虽然偶尔有些抖动，起码我们很清楚也比较容易获得原因或者作出一些预案。但对于全球这么多国家来说，运营商非常复杂，带来的全球互联互通问题也非常复杂，这么多国家，花点精力知道每个国家哪家运营商好，应该不难，但是要把各个国家串起来，互联互动这个问题就复杂了。
比如东南亚国家访问中国服务器和美国服务器，哪个会更快？从物理距离看应该国内会更快对吧？但是实际并非如此，东南亚访问国内，大部分都是绕行美国再连国内，这是多么奇葩的网路链路，但事实如此，就因为运营商接入美国再到中国更加便宜比直接接入中国便宜。这给我们全球化增加很多困难，我们需要做更多的事情去解决这类难题。
也许大家会说绕就绕呗，就这么用，可中国到美国来回耗时在130ms左右，还是在网络非常好的情况下，接近光速的速度，这个延迟看起来不起眼，我们做个对比，一般服务请求数据库基本在5~10ms左右会得到返回，如果有类似缓存机制就更快了，有多少服务能扛得住因为距离带来的130ms延迟。这对网站稳定性又提出了技术的挑战。国际形势下想获得用户的信息反馈，并不像国内那么容易，需要我们采取更多的手段去主动获取。
Aliexpress SRE之路
在Aliexpress，我们要提升可用性，需要考虑成本以及研发效率，在刚开始组建SRE团队的时候，没有任何基础，又想提升可用性，我们需要分析从何下手。这个图有点像力学，一方使劲，会造成另一方的倒退，如何寻找平衡，获得最高的回报率。
我们可以看到，可用性的追求是会降低研发效率的，可用性的追求是会增加研发和技术成本的，通过流程规范的建设是可以提升可用性的，但是会极大降低研发效率，通过工具化和智能化实现可用性，对效率提升有帮助，也对成本节省有帮助。
制定规范 提高可用性
Aliexpress的SRE初期，我们希望能快速的提升可用性，选择了成本最低，也是最容易先拿到结果的方式，制定流程规范，但是他给研发效率会带来降低，规范会有很多的制约，发布需要review，核心应用改一行代码也需要多机房的观察监控，整个过程耗时比较久。
其实规范现行，虽然很土，不够酷，但非常见效，不得不说对于一线研发同学来说，规范不仅仅是对他的约束，通过稳定性规范的考试，让一线研发知道非常多的流程细则以及为什么需要这么做，以及其中风险是什么，更让一线工程师对生产环境有更多的了解。devops的角色也得到很多认知上的提升，我们对历史的故障也是做过分析的，会发现有很大比例的问题都是对于生产环境的陌生，不小心或者不知道该怎么做而产生了问题。我们全球化多机房有很多地方需要注意，对线上的陌生一定会带来问题，比如多机房数据同步，没有做好任务消费的幂等性处理，一定会造成数据的一致性的问题，这是架构规约的一部分，也是SRE稳定性的范畴。此外，我们坚持每个半年会进行一次稳定性考试，让大家对规约，线上环境有知识的迭代更新，对生产环境的操作时刻保持敬畏之心。
Aliexpress SRE基础治理
对于SRE来说，最想做到的就是线上发生的一切都在掌控之中，即使出现问题，我们能通过有效的手段快速恢复，这也是Aliexpress SRE的核心。我们的治理也是从这条核心思想出发的，首先要做到这点，不可或缺的是对整个站点有全面的监控，出现问题我们都能快速发现，那就是监控。监控建设是有成本投入的，需要业务系统追加日志输出，根据需要绘制出我们想要的核心大盘（交易、流量、登录等待），如果有下跌，可以进入下一级分级是由哪些渠道造成的，帮助快速发现问题，同时我们也会追加分机房的大盘，这个后面会描述为什么需要这样的分类，有何目的。
一开始做这个事情的时候并没有那么系统的来做，而是各个团队分别输出日志，然后手工配置监控大盘，去年年初我们开始推广微服务Springboot，结合Springboot定制一个starter专门做日志的标准输出，采集所需日志的同时提升研发效率，标准化的日志对于后续的大数据分析来说非常有利，这也是长远考虑的一步，为日后智能化做的铺垫。
前面提到，对于SRE来说，希望自己有掌控权，监控的完善只能做到可见，没有掌控能力，所以我们还有几件事情，让SRE有掌控能力。快速恢复能力，俗称“容灾”，在Aliexpress容灾是一个体系，分了很多层，应对不同问题而定，这也是全球化所需。
之所以这么做，是有背景的，在前面提到Aliexpress SRE面临的挑战，全球网络质量问题，对于Aliexpress来说是不会轻易去切换DNS，原因主要有2个:
1.全球化架构会针对用户归属进行路由，接入层的改变并不会使其在后续链路发生变化2.DNS的切换会带来性能损耗，更何况我们有很多cdn策略，切换回源带来的性能损耗大概在8~15%，这个损失太心疼了
打造全球化架构
全球化架构，可以简单的描述为我们通过管控全球的用户，通过大数据的计算，配合DNS就近最优解析，将用户分别归属到不同的区域IDC，让全球用户获得最优的购物体验。基于这套逻辑通过严格的版本控制利用ZK上报确保全球多个IDC的用户路由表保持一致，接入层、服务层、数据层包括数据同步加载用户路由表，进行区域的修正路由，确保归属用户的操作都在一个区域完成，以达到全球数据一致性。这是一套完整的全球化解决方案。
基于这套架构，SRE的容灾也变的更加丰富，当某个变更导致web层发生问题，比如英文站搜索页面出现问题也许是样式也许是页面处理逻辑，基于我们的规范严格按照分机房发布策略，至少有一个机房是可用的，可以通过容灾到没有污染的区域，而其他层的逻辑都不发生改变。
当服务层发生问题，同样可以将用户从A区域切换到B区域，而在网络接入层不发生任何变化。这一层的容灾更加细腻，支持分流观察，按比例分流。当然发生重大问题，可以将整个区域failover，切换到灾备区域这些容灾都是秒级生效，并且有数据保护停写机制。
建立保障机制GTR
前面说到的都是基于机房级别的快速恢复，在全球化背景下，应对全球互联互通问题，我们也做了一套保障机制，GTR（global traffic routing service）。
简单介绍下这个图的含义：红点代表我们在全球有多个POP点，也就是网络接入点，五角星代表我们全球的IDC，思路是我们采集全球用户访问我们机房的信息，比如某国用户通过访问不同的pop点然后到我们的IDC，POP点都会汇入阿里骨干网，可以认为更加稳定，类似动态加速技术。
通过国家对应pop点对应IDC的访问响应时间来判断，当一条线路发生问题时，我们可以将这个国家或者叫区域的用户访问切换到其他网络线路，这个是某个国家访问美国机房的数据，通过德国接入点进入美国机房和直接从美国接入美国机房的时间差不多。
以上是对SRE监控、容灾的介绍，在此之外，我还是要分享下我们应对重大问题时，确保能快速定位恢复，这套应战平台对于收集作战人员经验起了很好的作用。作战成员都是各个产品线的专家，他们的经验在平台得以沉淀也为我们国际SRE智能化有很大的帮助。
Aliexpress SRE成立以来成果也比较明显，故障数明显下降，一线研发对线上环境以及自己身为devops角色的转型都比较成功，在这过程中，成功恢复多次重大线上故障，这也证实了我们平时的演练非常有效和重要。同时也为阿里集团国际化构建基础技术。
在SRE的体系运作下，朝着一个良性的循环运作，稳定性规范-分区域变更-分区域监控-分区域容灾-常态化演练。持续的优化工具、沉淀数据、培养研发素养，为未来SRE智能化做好准备。在这个体系下，我们会持续优化和丰富我们的自动化工具，丰富我们数据，优化我们的基础治理，往智能化的方向发展。谢谢大家。
Aliexpress诚邀有国际化背景的技术人员加入，直达邮箱：zhiwei.zhouzw@alibaba-inc.com
来源：阿里技术
原文链接
