互联网架构的三板斧

正文

【作者简介】 本文来自蚂蚁金服技术经理于君泽的分享。于君泽是蚂蚁金服高级技术专家、支付核算技术部负责人、成都研发中心技术团队创建者之一，先后负责或参与过转账类业务、账单类业务、社区支付、开放平台、支付平台、资金核算平台、类营销类支付工具的建设；之前有数年电信业务研发经验，涉及BSS|OSS|针对性营销等平台。推荐一下本文作者的公众号，一个认真、有内涵、但更新不太频繁的技术公众号：TheoryPractice。作者同时也是中生代技术（微信公众号：freshmantechnology）发起人。

本文普及一下传说中的互联网架构三板斧，以便有些场没赶上滴，有些会没参加滴，听完没有来得及消化滴，也能get到技能（学习也是棒棒的）！ 有人问了为啥是三板斧，是[三]，不是[四]，这也是习惯的力量！比如为啥是煎饼果子让西乔姐苦恼了一样。

可多层包裹的煎饼

可无限扩展的单元化豆腐 Ps：关于[三]的流行参考，百度可得

• 宅男有三好；Dota、基友、破电脑。
• 萝莉有三好；柔体、轻音、易推倒。
• 屌丝有三废；在吗、忙不、早点睡。
• 女神有三宝；干嘛、呵呵、去洗澡。

“ 与传统意义上的红包相比，近两年火起来的互联网“红包”，似乎才是如今春节的一大重头戏。春晚直播期间讨论春晚的微博达到5191万条，网友互动量达到1.15亿，网友抢微博红包的总次数超过8亿次。看得见的数据背后，隐藏的是什么看不见的技术呢？”
按照各家公布的数据，除夕全天微信用户红包总发送量达到10.1亿次，摇一摇互动量达到110亿次，红包峰值发送量为8.1亿次/分钟。而支付宝的红包收发总量达到2.4亿次，参与人数达到6.83亿人次，红包总金额40亿元，峰值为8.83亿次/分钟。春晚直播期间讨论春晚的微博达到5191万条，网友互动量达到1.15亿，网友抢微博红包的总次数超过8亿次。”

本文会以一些公开的内容聊聊万变不离其中的所谓绝招，为了吸引要求，素材主要参考淘宝大秒系统和各家红包系统的情况。

第一板斧

第一板斧：活下来 [Stability]
俗话说身体是革命的本钱，首先要活着。大凡架构还没有舍身成仁的死法，都是好死不如赖活着。关于如何活着，其实是有模式可循的，活着这事在技术界也有一个蛮好听的名字--稳定性（花名 Stability）。 稳定性实践笔者印象比较深的有2篇内容，一是由淘宝小邪在2011年分享的[淘宝稳定性实践]。

该材料经墙内搜索百度查询，基本没有别的存档了，唯有百度文库硕果仅存，地址就不贴了。这个slide主要讲了4招： 容量规划、集群容灾、依赖降级、运行监控。

就容灾可以区分为同机房内、同城异机房、异地机房几个层次考虑。

上图机房1种C系统故障切换机房2的情况。

保护自己是很重要的，如下图所示，C挂了，则A调用C超时，如何保障A不被拖累呢？

阿淘也给出解法，就是stable switch。如下图所示：

随着淘宝、天猫的业务发展，本着更优雅运维的思路，阿淘在稳定性方面的建设肯定有更多精细化，更好、更优雅的做法，但是其本质原则：活着胜过一切！

多个备份、无缝切换、超限限流、断尾求生又称优雅降级等是指导同类互联网应用的常见招数。另外，特别安利一下服务治理，随着微服务兴起，大有不微不能出来见人的姿势。但服务治理是在服务管理中一块重要内容，亘古弥新。如果有上千应用，服务接口不计其数。做一次功能升级，我得知道谁调用了我，我调用了谁；做性能和容量改进，我得知道那条链路是瓶颈；做链路优化，我得通过工具来看那些强依赖可以调整为弱依赖等等。

一片信手普及的基础文也写得这么干，江湖也不禁为自己点赞了。(话说龙姑娘的红包,啥时候发一下…)

第二篇高大上的ppt是来自国外的一个ppt。

作者把可用性和稳定性，做了一些区分。可用性偏大局，比如FO，MM模式等。而稳定性强调单区域应用中的手段比如开关，降级等。

第二板斧

第二板斧：简单可扩展（scalability）
啥叫可扩展，就是可以不断加资源以达成更大容量，支撑更高的并发、迎接更多用户 。这里的资源可以是应用服务器，也可以是数据库服务器，或者是缓存服务器。

[可扩展Web架构探讨]这个材料中也有对可扩展有所定义。

这里也提及scalability是系统适应不断增长用户数量的能力。特别提及扩展容易（所有组件都应当简单扩展）、无共享架构（shared arch）。
负载均衡是的作用有几个，一是接入接入保护、失效检测；二是提供在用户和服务器之间做中介，让增减服务器对用户不可见；三是通过负载均衡算法让流量相对均衡的分布。负载均衡有硬件设备也有纯软件比如LVS，负载均衡对于页面请求以及rpc调用都能较均衡的分配，是一个重要的考量因素。
（关于负载均衡的具体内容，此文不赘述）

有一个很古老的文档，叫LiveJournal's Backend - A history of scaling 叙述了网站的发展历程。

一台server有啥坏处，自不必说了。然后…

某一天发展到5台了，3个web server；2台db。使用mysql replication来做复制。

随着用户数的增加，用户需要cluster

后来因为性能的原因，需要使用cache，包括Mogile Storage等。详情可参见

一个网站的发展后来成了很多架构文章的标配。上更多webserver、上更多dbserver、读写分离、分库分表、上搜索引擎等等。架构之道在合适的时间做合适的决定(tradeoff),运用之道，存乎一心。

第三板斧

第三板斧：拦河大坝、去并发
由于营销活动（创造营销节点、扩大影响力的需要），总有很多产品策划、运营乐此不疲的玩着一个game---在足够集中的时间内比如秒级处理足够多的用户请求，让世界为此狂欢，同时也是彰显技术实力的一次大考。

小米卖着抢号的手机、天猫发明了双11光棍节、微信和支付宝连续2年做着新春红包。营销活动的时候要使用前2板斧，保证可用性和简单可扩展性，同时还要祭出第三板绝杀—拦河大坝、缓存为王、去热点资源的并发。

请到「今天看啥」查看全文