jurassic_1 2016-06-11 10722浏览量
【作者简介】本文来自蚂蚁金服技术经理于君泽的分享。于君泽是蚂蚁金服高级技术专家、支付核算技术部负责人、成都研发中心技术团队创建者之一,先后负责或参与过转账类业务、账单类业务、社区支付、开放平台、支付平台、资金核算平台、类营销类支付工具的建设;之前有数年电信业务研发经验,涉及BSS|OSS|针对性营销等平台。推荐一下本文作者的公众号,一个认真、有内涵、但更新不太频繁的技术公众号:TheoryPractice。作者同时也是中生代技术(微信公众号:freshmantechnology)发起人。
本文普及一下传说中的互联网架构三板斧,以便有些场没赶上滴,有些会没参加滴,听完没有来得及消化滴,也能get到技能(学习也是棒棒的)! 有人问了为啥是三板斧,是[三],不是[四],这也是习惯的力量!比如为啥是煎饼果子让西乔姐苦恼了一样。
可多层包裹的煎饼
本文会以一些公开的内容聊聊万变不离其中的所谓绝招,为了吸引要求,素材主要参考淘宝大秒系统和各家红包系统的情况。
该材料经墙内搜索百度查询,基本没有别的存档了,唯有百度文库硕果仅存,地址就不贴了。这个slide主要讲了4招:容量规划、集群容灾、依赖降级、运行监控。
就容灾可以区分为同机房内、同城异机房、异地机房几个层次考虑。
保护自己是很重要的,如下图所示,C挂了,则A调用C超时,如何保障A不被拖累呢?
阿淘也给出解法,就是stable switch。如下图所示:
随着淘宝、天猫的业务发展,本着更优雅运维的思路,阿淘在稳定性方面的建设肯定有更多精细化,更好、更优雅的做法,但是其本质原则:活着胜过一切!
多个备份、无缝切换、超限限流、断尾求生又称优雅降级等是指导同类互联网应用的常见招数。另外,特别安利一下服务治理,随着微服务兴起,大有不微不能出来见人的姿势。但服务治理是在服务管理中一块重要内容,亘古弥新。如果有上千应用,服务接口不计其数。做一次功能升级,我得知道谁调用了我,我调用了谁;做性能和容量改进,我得知道那条链路是瓶颈;做链路优化,我得通过工具来看那些强依赖可以调整为弱依赖等等。
作者把可用性和稳定性,做了一些区分。可用性偏大局,比如FO,MM模式等。而稳定性强调单区域应用中的手段比如开关,降级等。
[可扩展Web架构探讨]这个材料中也有对可扩展有所定义。
有一个很古老的文档,叫LiveJournal's Backend - A history of scaling 叙述了网站的发展历程。
一台server有啥坏处,自不必说了。然后…
随着用户数的增加,用户需要cluster
后来因为性能的原因,需要使用cache,包括Mogile Storage等。详情可参见
为啥要拦?很简单,用户很热情(感性),但系统必须得理性!就3个苹果手机,凭啥让几十万人都涌入柜台!在大秒系统一文中许同学就娓娓道来(省得少画个图)……
对大流量系统的数据做分层校验也是最重要的设计原则,所谓分层校验就是对大量的请求做成“漏斗”式设计,如上图所示:在不同层次尽可能把无效的请求过滤,“漏斗”的最末端才是有效的请求,要达到这个效果必须对数据做分层的校验,下面是一些原则:
将90%的数据缓存在客户端浏览器,将动态请求的读数据cache在web端,还是不够的。在大秒的过程中,存在极端情况,就是请求超过单key所在server的QPS能力。
数据访问热点,比如Detail中对某些热点商品的访问度非常高,即使是Tair缓存这种Cache本身也有瓶颈问题,一旦请求量达到单机极限也会存在热点保护问题。有时看起来好像很容易解决,比如说做好限流就行,但你想想一旦某个热点触发了一台机器的限流阀值,那么这台机器Cache的数据都将无效,进而间接导致Cache被击穿,请求落地应用层数据库出现雪崩现象。这类问题需要与具体Cache产品结合才能有比较好的解决方案,这里提供一个通用的解决思路,就是在Cache的client端做本地Localcache,当发现热点数据时直接Cache在client里,而不要请求到Cache的Server。
数据更新热点,更新问题除了前面介绍的热点隔离和排队处理之外,还有些场景,如对商品的lastmodifytime字段更新会非常频繁,在某些场景下这些多条SQL是可以合并的,一定时间内只执行最后一条SQL就行了,可以减少对数据库的update操作。另外热点商品的自动迁移,理论上也可以在数据路由层来完成,利用前面介绍的热点实时发现自动将热点从普通库里迁移出来放到单独的热点库中。
则解决之道是:
在红包应用中,如果还依赖一个共同的基础数据,也可以把这个基础数据拆成多个cell。
“在这次春晚活动中,涉及到大量的资源,包括图片、拜年视频等。图片和视频都比较大,十几b到几百kb不等。当在高峰期时,如果瞬间有海量的请求到CDN上,这么大的请求带宽根本扛不住。我们当时预估了大约有几T的带宽需求。
为了能有效地扛住瞬间峰值对CDN的压力,我们对资源进行了有效的管理和控制。首先在客户端预埋了几个缺省资源,万一真不行了,这几个资源可以用。其次尽量提前打开入口,当用户浏览过后,就将资源下载到本地。再次浏览时不再需要远程访问CDN。最后,做了应急预案,高峰期一旦发现流量告警,紧急从视频切换到图片,降低带宽压力,确保不出现带宽不够而发生限流导致的黑屏等体验不好的问题。
在除夕,用户通过摇一摇参与活动,可以摇到红包或其他活动页,这些页面需要用到很多图片、视频或 H5 页面等资源。在活动期间,参与用户多,对资源的请求量很大,如果都通过实时在线访问,服务器的网络带宽会面临巨大压力,基本无法支撑;另外,资源的尺寸比较大,下载到手机需要较长时间,用户体验也会很差。因此,我们采用预先下载的方式,在活动开始前几天把资源推送给客户端,客户端在需要使用时直接从本地加载。”
写这么个长篇,我也是醉醉的了,权当为那些没时间学习、没仔细学习的朋友尽心了。
【引用内容 出处】
《互动1808亿次,16倍的超越!谈支付宝红包的高并发挑战》- QCon公众号
《10亿红包从天而降,揭秘微信摇一摇背后的技术细节》 - InfoQ网站《淘宝大秒系统设计详解》- CSDN《解密微博红包:架构、防刷、监控和资源调度》 - InfoQ网站http://www.slideshare.net/jboner/scalability-availability-stability-patterns
LiveJournal's Backend - A history of scaling
中生代技术群微信公众号
版权声明:本文内容由阿里云实名注册用户自发贡献,版权归原作者所有,阿里云开发者社区不拥有其著作权,亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容,填写侵权投诉表单进行举报,一经查实,本社区将立刻删除涉嫌侵权内容。