从淘宝到云端的高可用架构演进
|
副标题[/!--empirenews.page--]
《从淘宝到云端的高可用架构演进》要点： 近日在Qcon开发者大会北京站上,来自阿里巴巴商家事业部技术专家沐剑在专场分享了题为《高可用实践：从淘宝到上云的差异》的演讲,主要介绍了其近几年在阿里电商平台及阿里云上的高可用设计的经验,分为两个部分：第一部分主要包括传统的淘宝店铺稳定性体系的建设及相关的基础链路设计、缓存和容灾方案的设计及部署；第二部分主要包括目前公有云高可用设计的主要思路、经典故障及应对措施等. 演讲全文： 沐剑 大家好,我今天分享的题目是《高可用实践：从淘宝到上云的差异》,取这个标题是因为会涉及到两个方面内容,一方面以淘宝为例子,传统的IDC的时候,我们稳定性是怎么做的,另外在云计算背景下,有很多创业公司是基于阿里云这样的公有云基础设施做研发,在公有云的环境下怎么做好我们系统的高可用. 长期做稳定性的人会有一些职业病,记得去年冬天有个周末,我要寄快递,穿着睡衣在门口填快递单,那时候我家里养了一只猫,因为怕猫跑出去,就把门关上了.寄完快递口袋一掏发现自己没带钥匙,冷静了3秒钟,打车到公司刚巧碰到同事,看我穿着睡衣来公司了问我什么情况,我说家里钥匙忘带被锁在门外面了,不过没事,我还有一把backup钥匙放在公司.生活中很多时候都需要有一个backup. 我的花名叫沐剑,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,也是做类似的事情.另外这里我放了一个Github的链接,这个agent能够让你在perf界面里直接看Java Method的开销. 谈到缓存,Cache里有一些小技巧,在做双十一备战时发现一个店铺的基础服务平时日常就每天有100亿的调用量,当时是几十台机器估了一下可能要成倍增长,成本是非常高的,怎么解决这个问题,当时写了个富客户端,让业务方先去查我们分布式Cache,如果命中就直接返回来,如果不命中再走我们的服务端查.这种情况下,只要你能够保证命中率足够高,比如98%的命中率,就意味着只有2%是需要后端服务器承担剩下的请求,用非常少的服务器去承担非常大的流量,这是成本和性能间的权衡. 在缓存方面,我们很少会关心缓存的高可用是怎么部署的,它是一个偏运维的内容,我把缓存的部署简化成一个双机房的模型,因为它在高可用里是最简单的场景.对于缓存来说有两种经典部署模式,第一种叫共享集群部署,在IDC里我的应用是分机房部署的,Cache集群也是分机房部署,对于应用服务器来说,两边的Cache对他来说逻辑上是一个集群,会往IDC 1的Cache写一半过去,往IDC 2也写一半过去,这种部署的好处在于,机房间网络断掉的时候,有一半的数据是在缓存的,保证一半的数据能够命中,不会直接死掉,另外对成本上相对比较友好,没有浪费任何一个Cache的节点,这个Cache本身是复用的.但是也正如刚才说的问题,如果中间断掉了,有一半的命中率是有损的,所以就诞生了另外的一个部署模式,就是独立部署,不管你哪个机房挂掉,命中率是基本不变的,两边同时保持了98%的命中率,但是它是成本不友好的,两边要同时部署,同时承担副本的作用,并且失效时,要同时失效另外一个IDC 2,这样才保证一致性. （编辑：厦门网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
