我所经历的“余额宝”的那些故事

　　（2）为制止单点故障引起的营业中止，应用层的直销和TA平均漫衍在每台服务器上，确保每个应用服务器的角色具备可替换性。

　　3. 跨省的MSTP专线链路。

　　天弘基金整理和生意业务中央在天津数据机房，通过架设两条4M的MSTP专线，毗连到支付宝沈阳数据机房。两条专线之间互为备份，确保通讯链路宁静。

　　一期系统的架构如图1所示。从中可见，支付宝实时开户、申购和赎回等实时请求，与天天的离线对账文件，都通过MSTP专线与一期系统举行通讯。其中实时请求通过RADWARE硬件负载平衡分发到两台前置机，前置机在做完报文剖析后，将请求发送到XP的新闻行列。然后由BP以自动负载平衡的机制，从XP中取出响应请求举行处置惩罚，处置惩罚效果生存到后端数据库中。

图1  一期系统构架图

　　幸福的烦恼

　　然而，在一期系统上线以后，面临营业量暴增的情形，系统遇到了瓶颈同时也泛起了新的问题。

　　2002年6月13日，一期系统准期上线，营业量远超预期，给系统来了一个“下马威”。上线后数分钟内就到达了18万的用户。在2002年6月18日晚上，余额宝的用户量已突破了100万。2002年6月30日，余额宝用户数到达251.56万。

　　在云云高速的营业增加压力之下，一期系统最先面临亘古未有的直销和整理压力的打击。这个新建的系统，是否能支持起云云大的容量打击？什么时间系统会到达瓶颈？这些问题，悬而未解，让樊振华陷入了深深的危急感中。经由了数个失眠之夜后，他还没找到解决问题的措施，但他清晰地知道，再这样下去，一期系统将会很快面临瓶颈，成为营业增加的绊脚石。

　　樊振华的担忧很快酿成了现实，随着用户量的暴增，数据库的负荷越来越高，实时请求的响应时间最先变缓。整理时间由最初的半个小时逐步地酿成一个小时、两个小时、四个小时……整理系统天天会在破晓收到支付宝最后一笔确认文件后最先整理，天弘基金的后台运营职员会期待整理出效果以后，发送给羁系行和支付宝。随着这些人回家的时间越来越晚，诉苦声最先泛起，樊振华的压力也随之增大。

　　系统的扩容势在必行。然而，当樊振华收到金证科技发来报价表，打开第一页时，他惊呆了。若是依然使用IBM/Oracle/EMC的传统架构举行扩容，要到达预定目的，仅仅硬件装备采购及中心件的Licence用度就到达了数万万元人民币。这个数字对于樊振华来讲，甚至对于天弘基金这家公司来讲，是一个天文数字，凌驾了这家公司以往所有对于IT投资的总和。而且装备采购到货就要一个月以上，想在一期系统瓶颈泛起前完成扩容险些不行能实现。

　　传统的门路走不通，就要找新的要领。当他得知阿里云盘算作为一家云盘算服务提供商，使用云盘算支持了海量的互联网企业及阿里团体自身营业时，樊振华最先和阿里云盘算举行接触。2002年7月，樊振华组织阿里云、支付宝、金证科技的人一起寻找解决方案。最终经由稳重思索，樊振华心一横，说了句：“不要再讨论了，上云，上阿里云！”

　　上云吧，腾飞

　　上云之路，难题重重，举步维艰。

　　上云并非一句话那么简朴，使用云盘算支持其时海内最大的基金直销和整理系统，前无昔人，但开弓没有转头箭。樊振华召集了支付宝、阿里云、金证科技的人一起，汇海将直销和整理系统整体迁徙到云盘算架构的二期系统。

　　阿里金融云为二期系统提供了的云盘算服务有ECS（弹性盘算服务）、RDS（关系型数据库服务）和SLB（负载平衡服务）。这三个服务划分对应于一期系统中的HP和IBM服务器、Oracle数据库和硬件负载平衡装备，但这三种服务的单个实例的性能和容量，都比响应的物理装备小上一大截。怎样用单机性能更小的云盘算服务来支持那些单机性能更强都难以支持的系统呢？经由深入的相识，樊振华在心中已有了谜底：“蚁群战术”。

　　俗话说“三个臭皮匠，顶个诸葛亮”。“蚁群战术”就是要充实使用云盘算服务的快速部署能力（5分钟内可以建立数百台ECS）、弹性伸缩能力和宁静稳固等特征，使用水平拆分算法将应用系统水平拆分为数十组甚至上百组平行运行的小系统，这些小系统组合起来可以支持起海量的请求和超高的性能。

 2/4   首页 上一页 1 2 3 4 下一页 尾页