编者按：本文来自微信公众号“阿里技术”（ID：ali_tech），内容整理自阿里技术专家沐剑在 QCon 北京 2017 上的演讲；36氪经授权发布。

　　本文主要介绍近几年在阿里电商平台及阿里云上的高可用设计经验，分为两个部分：第一部分主要包括传统的淘宝店铺稳定性体系的建设及相关的基础链路设计、缓存和容灾方案的设计及部署；第二部分主要包括目前公有云高可用设计的主要思路、经典故障及应对措施等。

　　写在前面

　　大家好，我今天分享的题目是《高可用实践：从淘宝到上云的差异》，取这个标题是因为会涉及到两个方面内容，一方面以淘宝为例子，传统的 IDC 的时候，我们稳定性是怎么做的，另外在云计算背景下，有很多创业公司是基于阿里云这样的公有云基础设施做研发，在公有云的环境下怎么做好我们系统的高可用。

　　我的花名叫沐剑，2011 年加入淘宝做评价系统，2012-2015 年在店铺平台，负责店铺的前台浏览系统和后台的 RPC 服务，以及一些性能优化、双 11 保障的事情。到了 2015 年开始到了 TAE 团队，开始负责云端架构及整体高可用方案，TAE 的升级版 EWS 现在也在聚石塔上面帮大量 ISV 和创业公司解决运维部署、自动化监控和性能分析等等问题。

　　去年我是作为阿里商家事业部双 11 作战项目研发的 PM。2017 年我开始接手商家营销团队。在阿里五六年的经验，其实就做了几件事，比如连续五年参加了双十一的核心备战，然后像去 IOE、异地多活，全链路压测、安全混合云、容器服务等项目参与设计和实施。

　　首先我会从淘宝店铺角度分享，以前在店铺是怎么样做双 11 保障的，后面是一些公有云相关的内容。

　　淘宝店铺稳定性体系建设

　　这是一个淘宝的店铺系统，这套系统是一个非常典型的高并发的浏览系统，在前几年的双 11 峰值有 20 万次的 Web 页面请求，平均一个页面对应了 20 次的 RPC 调用，这个时候对于整个系统的集合来说每秒的 QPS 是 400 万次，这中间就会涉及到缓存、数据库以及其它二方的 RPC 调用，对于这样的系统来说，在性能、稳定性和体验间要做一个平衡，既不能纯用太多的机器死扛这个访问量，又要保障用户的体验。

　　基础链路设计

　　从请求链路来说，首先 DNS 把 CDN 的 VIP 解析出来，分布在全球不同的区域，CDN 回源到接入层分别经过 4 层和 7 层的负载均衡，近几年会发现 CDN 这个行业早已不仅仅局限做 CSS/JS 等静态资源的缓存，也承担了一些动态加速和收敛的特性，所以我们是通过 CDN 做域名收敛，收敛后会把这个流量发到统一接入层，然后到应用集群，后面再经过应用存储、Cache 这些服务。

　　当我们在做稳定性的时候，会考虑性能和稳定性之间是什么关系，很多人认为这两者是冲突的，比如我要保障一个东西的性能非常高的时候，要牺牲掉很多别的东西，可能你要引入一个非常新的框架或者基础设施来提升性能，但它的稳定性可能是不那么成熟的，但是从容量规划的角度看，只有这套系统性能足够好，才能承担像双 11 那样的大访问量。

　　店铺也是一套经历了很多年的系统，在应用层上的优化基本上已经做到极致了，我们就转变思路，在操作系统层能不能做一些优化，这里借助了一个比较好的工具 perf，在操作系统层面告诉你系统调用的开销是集中在哪里，从 perf 上就可以定位到有一个百分比，可以看到是比如数组分配还是 GC 产生了大量的开销。

　　最初我们发现是异常带来的开销，就会看为什么这个系统的异常会导致 20% 以上的 CPU 开销，最后用 BTrace 跟了一下异常的构造函数，发现是我们依赖的开源的三方包里通过异常做控制流，每一次它处理结束的时候，就抛一个 EOFException 出来，这个就导致了非常大的开销，我们就把开源包替换掉了。

　　当你依赖一些底层的东西的时候，如果对原理不太了解会给你带来一些意料之外的事情。JVM 里是有一个常量池存储字符串常量的地方，就是一个哈希表，如果说这个表的大小不足够大，就会从哈希查询变成链表查询，性能就会特别低。

　　再谈一个 warm up 的问题，当我们应用刚刚启动的时候，还没有把字节码编译成 native code，延迟非常高，用户就得到一个有损的服务。我们现在在内部的 JVM 做一个功能，会采集线上系统的调用，把热点方法收集下来做分析，在应用把真实流量挂上去之前，已经预先把所有的热点方法编译成 native code 保证这个性能。开源界也有其他的方案，比如 Azul 的 Zing 有个 ReadyNow，IBM 的 J9 有个 AOT，也是做类似的事情。

　　缓存设计

　　谈到缓存，Cache 里有一些小技巧，在做双十一备战时发现一个店铺的基础服务平时每天日常就有 100 亿的调用量，当时是几十台机器估了一下可能要成倍增长，成本是非常高的，怎么解决这个问题，当时写了个富客户端，让业务方先去查我们分布式 Cache，如果命中就直接返回来，如果不命中再走我们的服务端查。这种情况下，只要你能够保证命中率足够高，比如 98% 的命中率，就意味着只有 2% 是需要后端服务器承担剩下的请求，用非常少的服务器去承担非常大的流量，这是成本和性能间的权衡。

　　在缓存方面，我们很少会关心缓存的高可用是怎么部署的，它是一个偏运维的内容，我把缓存的部署简化成一个双机房的模型，因为它在高可用里是最简单的场景。

　　对于缓存来说有两种经典部署模式，第一种叫共享集群部署，在 IDC 里我的应用是分机房部署的，Cache 集群也是分机房部署，对于应用服务器来说，两边的 Cache 对他来说逻辑上是一个集群，会往 IDC 1 的 Cache 写一半过去，往 IDC 2 也写一半过去，这种部署的好处在于，机房间网络断掉的时候，有一半的数据是在缓存的，保证一半的数据能够命中，不会直接死掉，另外对成本上相对比较友好，没有浪费任何一个 Cache 的节点，这个 Cache 本身是复用的。

　　但是也正如刚才说的问题，如果中间断掉了，有一半的命中率是有损的，所以就诞生了另外的一个部署模式，就是独立部署，不管你哪个机房挂掉，命中率是基本不变的，两边同时保持了 98% 的命中率，但是它是成本不友好的，两边要同时部署，同时承担副本的作用，并且失效时，要同时失效另外一个 IDC 2，这样才保证一致性。

转载请注明出处。