从零开始学架构——互联网架构的演进
1 技术演进
1.1 技术演进的动力
- 对于新技术,我们应该站在行业的角度上思考,哪些技术我们要采取,哪些技术我们不能用,投入成本过大会不会导致满盘皆输?
- 市场、技术、管理三者组成的业务发展铁三角,任何一个不足都会导致企业的业务停滞不前,我们可以发现,其实三者都是服务于业务,业务有需求那么就应该尽量去满足,技术只不过是满足业务的一种手段
可以将企业的业务分为:产品类、服务类 - 产品类:开发出的产品,提供给用户使用,数据以及一些功能都可以定制化,且数据存储在用户本地
- 服务类:更像是给你提供服务,所以需要将数据留在服务端,以便于更好的服务于用户
- 服务的用户越多,价值也就越大
- 服务类的业务符合互联网的特征和本质:“互联”+“网”
对于产品类业务,技术的创新会推动业务发展,比如UC浏览器独创云端架构,很好解决了上网满的问题等。
对于服务类业务,业务发展推动技术发展,可以发现和产品类业务相反
为什么业务发展是推动技术发展
- 产品类更多的选择是个人喜好,因为产品一般提供的是功能,但是服务类的选择则是规模
- 比如微信和qq你用哪个,如果社畜所在的公司都用的微信来进行沟通,那么你的人际关系可能就会转移到微信沟通上,qq就会逐渐舍弃,但是当规模都一样时,这时候可能才会看中个人喜好去选择
当规模成为业务的决定因素后,服务模式的创新就会成为业务发展的核心驱动力,而产品只是完成服务提供给用户使用的一个载体,服务类的业务发展路径一般是:一种创新的服务模式—>吸引了一批用户->业务开发发展->吸引更多用户->服务模式不断完善和创新->吸引更多用户
综上所述,除非是开创性的技术,能够推动活创造易总新的业务,其他情况下,都是业务的发展促使了技术的发展创新
1.2 淘宝发展
由于距离较多,以淘宝为例,讲述其发展,淘宝主要经历了 个人网站->Oracle/支付宝/旺旺->java时代1.0->java时代2.0->java时代3.0->分布式时代
1.2.1 个人网站
在淘宝初创时,并未考虑技术是否优越,也没有考虑性能是否海量,以及稳定,主要的考虑因素是快,快速上线
- 当时的背景就是抢占先机,占领市场
- 买一个系统就是为了快速可用,而买一个轻量级的系统就是为了“快速开发”
- 业务决定技术,所以当时的架构也非常简单
1.2.1 Oracle/支付宝/旺旺
淘宝推出时,正好遇到非典,网购很火,且又采取了成功的市场运作,业务也发展起来,所以MySQL很快就撑不住了
- 直接采取替换为Oracle,原因是容量大,稳定,安全,性能高,且有人员储备
- 数据量变大后,本地存储又不够用,就买了NAS,加上Oracle RAC来实现负载均衡
- 这个阶段主要就是买“性能”
1.2.3 Java时代1.0——脱胎换骨
这个阶段并没有直接去买技术,而是通过sun公司来转换开发语言为java,主要是因为,技术影响了业务的发展,频繁死锁和重启对用户业务产生了严重音响。
- java时当时最成熟的网站开发语言,有良好的企业开发框架,被世界主流的大规模网站采用
- 且java开发经验的人也多,后续维护成本低
1.2.4 Java时代2.0——坚若磐石
这个时期,淘宝做了很多优化工作:数据分库,放弃EJB,引入Spring,加入缓存,加入CDN,采用开源的JBoss
- 这些操作都是围绕提高容量、提高性能、节约成本来做的,没有继续买技术来解决这些问题主要是买也解决不了问题,只能从架构上去优化
- 买技术的成本会更高
1.2.5 Java时代3.0和分布式时代
这个阶段淘宝技术从商用转为“自研”,去IOE化
- 这个阶段业务规模急剧上升后,复杂度高的IOE成本是这个阶段的主要原因
2 技术演进的模式
业务发展究竟是如何驱动技术发展的?
- 业务模式虽然千差万别,但是无论什么样的业务,都需要有一定的技术同步发展进行支撑,因为业务的复杂性导致了,不得不去驱动技术
- 因为面向的是服务,提供给用户的服务,就会有竞争,和安全保障
- 你的服务不好,我就换一个好一点的呗
- 你的服务导致我一个订单丢失几万几百,我难道还用你家服务啊
- 用的人越来越多肯定会导致性能下降,功能越来越多也会导致架构变得复杂
- 因为面向的是服务,提供给用户的服务,就会有竞争,和安全保障
- 所以业务的复杂性要么来源于功能的不断叠加,和规模的扩大,从而对性能和可用性有了更高的要求。
- 所以判断复杂性到底考虑功能复杂性,还是规模复杂性,还是都考虑
- 应该基于业务的发展阶段来进行判断,不同的行业业务发展路径、轨迹、模式不一样、所以需要根据自身所在行业的发展以及自身情况进行判断
假设是一个银行IT系统的架构师 - 90年代的业务复杂度肯能就是业务范围扩大,功能增多和复杂,导致内部系统的数量增多,单系统功能越来越复杂
- 2004年,转向网上银行,稳定性、安全性、易用性是主要复杂度,由IT系统自己解决
- 2009年复杂度又转为移动支付,要应对其他第三方调用的请求,比如双十一,支付宝,微信等,高性能、稳定性、安全性是主要复杂度
若假设你是淘宝的架构师:那么你会遇到的问题就会和银行IT遇到的问题不通,因为你们面向的业务不一样,所以复杂度出现的地方也可能不会相同,但是可能对于某一些相同的复杂度问题,也许有相似的解决方案
3 互联网业务发展
互联网业务千差万别,但由于其具有规模决定一切的相同点,发展路径也基本上是一致的
业务可以分为几个时期:初创期,快速发展期,竞争期,成熟期。
不同的时期的差别也主要体现在:复杂性、用户规模
3.1 业务复杂性
初创期
- 这个时期的业务点在于创新,不是完善
- 先创新吸引用户,所以要求就只有一个“快”
- 同时初创时期,技术人员少,所以能买就买,能用开源的就用开源的
发展期
- 当业务以及功能推出后,经过市场验证是可行的,那么吸引的用户就会越来越多
- 此时的功能要求也会增加,所以快速实现需求是此阶段的核心任务
- 如何做到快?
- 堆功能:这时候就是朴实无华的增加功能,即使是重构,代码优化等想做可能都没有时间去做
- 优化期:当发现新功能越来越难堆了,可能就是需要优化和重构代码的时候了,此时又会分为两派:优化派和架构派
- 优化派:核心思想是将现有系统优化,比如重构代码,分层,优化SQL查询,硬件优化,数据库选型等等,就是对系统尽量小的改动,可以快速实施,但是这样做,可能撑不了多久
- 架构派:调整系统架构,优化架构,将大系统拆分为多个相互配合的小系统,动作比较大,对业务的发展影响也很大
- 大多数情况下,都是优化派能胜出
架构期
- 很多情况下,业务量增长,即使进行了优化,慢慢也会发现扛不住,所以还是要进行架构优化
- 总结一个字“拆”
- 拆功能:将各个系统拆分为多个子系统
- 拆分数据库:进行分库分表
- 拆分服务器:根据子系统改成分布式或者集群,增加负载均衡系统
竞争期
- 这个时候,由于市场已经形成,肯定会有人来分蛋糕,所以这个阶段对于技术的要求是更快了,也要有新的业务创新
- 同时,架构优化后的美好时光就慢慢消逝,此时的问题体现如下
- 重复造轮子:系统越来越多,相似的工作重复,例如每个系统都有存储,缓存等
- 系统交互一团乱麻:各系统之间的交互变成了网状结构
- 解决办法如下:
- 平台化:用于解决重复造轮子的问题
- 存储平台化:淘宝的TFS,京东的JFS
- 数据库平台化:百度的DBProxy,淘宝的TDDL
- 缓存平台化:Twitter的Twemproxy,腾讯的TTC
- 服务化:系统之间交互混乱的问题,常见是通过MQ来完成系统间异步通知,或者使用服务框架
- 消息队列:淘宝的Notify,MetaQ,Kafka等
- 服务框架:Facebook的Thrift,淘宝的HSF等
- 平台化:用于解决重复造轮子的问题
成熟期
- 此时企业已经熬过了竞争期,成为了行业的领头羊,业务已经趋于稳定和成熟,业务创新机会不多,更多是优化用户体验和项目求精方面,比如响应时间,以及用户体验,还有结构优化降低成本
- 此时的优化可能就需要从各方面入手
- 架构上的调整
- 技术上的选型和采用可行成熟的新技术——需要测试
- CDN、数据库、缓存、网络等
- 机器硬件优化等等,没有规定死需要采用哪些优化
3.2 用户规模
用户量越来越大,导致对性能和可用性的要求越来越高
- 性能:性能确实会随着用户规模变大而降低,原因是对于计算机来说,计算资源是有限的,过多的人导致了每个人能使用的资源变少,所以我们很多时候都是把资源变多来解决问题
- 比如一台MySQL不够,我们可以多用几台,只不过就会设计到数据的同步等问题以及分库分表等问题
- 可用性:可用性的关注点是系统故障出现的几率和持续时间
- 如果系统宕机次数一天能达到2-3次,每次10分钟,肯定会影响用户操作,用户可能放弃产品的概率会很大
- 同时也会影响收入,如果初创时期,人不多,可能最多损失几千,但是用户多起来后,损失可能就更大了
3.3 量变到质变
前面提到了复杂性和用户的规模是导致技术的发展,且不同的阶段带来的影响也是不同的,究竟用户规模发展到什么地步才会量变产生质变
阶段 | 用户规模 | 业务阶段 | 技术影响 |
---|---|---|---|
婴儿期 | 0~1万 | 初创期 | 用户规模对性能和可用性都没有什么压力,技术人员可以安心睡好觉 |
幼儿期 | 1~10万 | 初创期 | 用户规模对性能和可用性已经有一点压力了,主要体现为单台机器(服务器、数据库)可能已经撑不住了,需要开始考虑拆分机器,但这个时候拆分还比较简单,因为机器数量不会太多 |
少年期 | 10~100万 | 发展期 | 用户规模对性能和可用性已经有较大压力了,除了拆分机器,已经开始需要将原来大一统的业务拆分为更多子业务了 |
青年期 | 100~1000万 | 竞争期 | 用户规模对性能和可用性已经有很大压力了,集群、多机房等手段开始用上了虽然如此,技术人员还是很高兴的,毕竟到了此时公司已经发展得非常不错了 |
壮年期 | 1000万~1亿 | 竞争期&成熟期 | 用户规模对性能和可用性已经有非常大压力了,可能原有的架构和方案已经难以继续扩展下去,需要推倒重来不过如果你真的身处这样一个公司,虽然可能有点辛苦,但肯定会充满干劲,因为这样的机会非常难得,也非常锻炼人 |
巨人气 | 1亿+ | 成熟期 | 和壮年期类似,不过如果你真的身处这样一个公司,虽然可能有点辛苦,但估计做梦都要笑醒了!因为还没有哪个互联网行业能够同时容纳两家1亿+用户的公司 |
不管什么样的方式,核心都是满足业务快的要求,当发现业务快不起来的时候,其实就是技术的水平跟不上业务的发展,技术的变革和发展的时候就到了 |
4 总结
- 产品类业务:技术创新推动业务发展。
- “服务”类的业务:业务发展推动技术的发展。
- 架构师需要基于业务发展阶段判断出系统当前面临的主要复杂度。
- 互联网业务千差万别,但都具有“规模决定一切”的特点。
- 互联网业务发展一般分为几个时期:初创期、快速发展期、竞争期、成熟期。
- 互联网业务发展第一个主要方向就是“业务越来越复杂”。
- 互联网业务发展第二个主要方向就是“用户量越来越大”。
- 互联网业务发展带来复杂度的本质原因其实都是“量变带来质变”。