因为各行业的业务发展轨迹并不彻底相同,没法给出一个统一的模板让全部的架构师拿来就套用,所以我以互联网的业务发展为案例,谈谈互联网技术演进的模式,其余行业能够参考分析方法对本身的行业进行分析。html
互联网业务千差万别,但因为它们具备“规模决定一切”的相同点,其发展路径也基本上是一致的。互联网业务发展通常分为几个时期:初创期、发展期、竞争期、成熟期。数据库
不一样时期的差异主要体如今两个方面:复杂性、用户规模。缓存
互联网业务发展第一个主要方向就是“业务愈来愈复杂”,咱们来看看不一样时期业务的复杂性的表现。服务器
1. 初创期网络
互联网业务刚开始通常都是一个创新的业务点,这个业务点的重点不在于“完善”,而在于“创新”,只有创新才能吸引用户;并且由于其“新”的特色,其实一开始是不可能很完善的。只有随着愈来愈多的用户的使用,经过快速迭代试错、用户的反馈等手段,不断地在实践中去完善,才能继续创新。架构
初创期的业务对技术就一个要求:“快”,但这个时候却又是创业团队最弱小的时期,可能就几个技术人员,因此这个时候十八般武艺都须要用上:能买就买,有开源的就用开源的。负载均衡
我还以淘宝和 QQ 为例。框架
初版的淘宝(blog.csdn.net/linlin_juej…):运维
初版的 QQ(www.yixieshi.com/20770.html):异步
能够看到最开始的淘宝和 QQ 与如今相比,几乎看不出是同一个业务了。
2. 发展期
当业务推出后通过市场验证若是是可行的,则吸引的用户就会愈来愈多,此时原来不完善的业务就进入了一个快速发展的时期。业务快速发展时期的主要目的是将原来不完善的业务逐渐完善,所以会有愈来愈多的新功能不断地加入到系统中。对于绝大部分技术团队来讲,这个阶段技术的核心工做是快速地实现各类需求,只有这样才能知足业务发展的须要。
如何作到“快”,通常会经历下面几个阶段。
业务进入快速发展期的初期,此时团队规模也不大,业务需求又很紧,最快实现业务需求的方式是继续在原有的系统里面不断地增长新的功能,重构、优化、架构等方面的工做即便想作,也会受制于人力和业务发展的压力而放在一边。
“堆功能”的方式在刚开始的时候好用,由于系统还比较简单,但随着功能愈来愈多,系统开始变得愈来愈复杂,后面继续堆功能会感到愈来愈吃力,速度愈来愈慢。一种典型的场景是作一个需求要改好多地方,一不当心就改出了问题。直到有一天,技术团队或者产品人员再也受不了这种慢速的方式,终于下定决定要解决这个问题了。
如何解决这个问题,通常会分为两派:一派是优化派,一派是架构派。
优化派的核心思想是将现有的系统优化。例如,采用重构、分层、优化某个 MySQL 查询语句,将机械硬盘换成 SSD,将数据库从 MySQL 换成 Oracle,增长 Memcache 缓存等。优化派的优点是对系统改动较小,优化能够比较快速地实施;缺点就是可能过不了多久,系统又撑不住了。
架构派的核心思想是调整系统架构,主要是将原来的大系统拆分为多个互相配合的小系统。例如,将购物系统拆分为登陆认证子系统、订单系统、查询系统、分析系统等。架构派的优点是一次调整能够支撑比较长期的业务发展,缺点是动做较大、耗时较长,对业务的发展影响也比较大。
相信在不少公司都遇到这种状况,大部分状况下都是“优化派”会赢,主要的缘由仍是由于此时“优化”是最快的方式。至于说“优化派”支撑不了多久这个问题,其实也不用考虑太多,由于业务可否发展到那个阶段仍是个未知数,保证当下的竞争力是最主要的问题。
通过优化期后,若是业务可以继续发展,慢慢就会发现优化也顶不住了,毕竟再怎么优化,系统的能力老是有极限的。Oracle 再强大,也不可能一台 Oracle 顶住 1 亿的交易量;小型机再好,也不可能一台机器支持 100 万在线人数。此时已经没有别的选择,只能进行架构调整,在优化期被压制的架构派开始扬眉吐气了,甚至会骄傲地说“看看吧,早就说要进行架构调整,大家偏要优化,如今仍是顶不住了吧,哼……”。
架构期能够用的手段不少,但归根结底能够总结为一个字“拆”,什么地方均可以拆。
拆功能:例如,将购物系统拆分为登陆认证子系统、订单系统、查询系统、分析系统等。
拆数据库:MySQL 一台变两台,2 台变 4 台,增长 DBProxy、分库分表等。
拆服务器:服务器一台变两台,2 台变 4 台,增长负载均衡的系统,如 Nginx、HAProxy 等。
3. 竞争期
当业务继续发展,已经造成必定规模后,必定会有竞争对手开始加入行业来竞争,毕竟谁都想分一块蛋糕,甚至有可能一不当心还会成为下一个 BAT。当竞争对手加入后,你们互相学习和模仿,业务更加完善,也不断有新的业务创新出来,并且因为竞争的压力,对技术的要求是更上一层楼了。
新业务的创新给技术带来的典型压力就是新的系统会更多,同时,原有的系统也会拆得愈来愈多。二者协力的一个典型后果就是系统数量在原来的基础上又增长了不少。架构拆分后带来的美好时光又开始慢慢消逝,技术工做又开始进入了“慢”的状态,这又是怎么回事呢?
原来系统数量愈来愈多,到了一个临界点后就产生了质变,即系统数量的量变带来了技术工做的质变。主要体如今下面几个方面:
系统愈来愈多,各系统类似的工做愈来愈多。例如,每一个系统都有存储,都要用缓存,都要用数据库。新建一个系统,这些工做又要都作一遍,即便其余系统已经作过了一遍,这样怎么能快得起来?
系统愈来愈多,各系统的交互关系变成了网状。系统间的交互数量和系统的数量成平方比的关系。例如,4 个系统的交互路径是 6 个,10 个系统的交互路径是 45 个。每实现一个业务需求,都须要几个甚至十几个系统一块儿改,而后互相调用来调用去,联调成了研发人员的灾难、联测成了测试人员的灾难、部署成了运维的灾难。
针对这个时期业务变化带来的问题,技术工做主要的解决手段有:
平台化
目的在于解决“重复造轮子”的问题。
存储平台化:淘宝的 TFS、京东 JFS。
数据库平台化:百度的 DBProxy、淘宝 TDDL。
缓存平台化:Twitter 的 Twemproxy,豆瓣的 BeansDB、腾讯 TTC。
服务化
目的在于解决“系统交互”的问题,常见的作法是经过消息队列来完成系统间的异步通知,经过服务框架来完成系统间的同步调用。
消息队列:淘宝的 Notify、MetaQ,开源的 Kafka、ActiveMQ 等。
服务框架:Facebook 的 thrift、当当网的 Dubbox、淘宝的 HSF 等。
4. 成熟期
当企业熬过竞争期,成为了行业的领头羊,或者整个行业总体上已经处于比较成熟的阶段,市场地位已经比较牢固后,业务创新的机会已经不大,竞争压力也没有那么激烈,此时求快求新已经没有很大空间,业务上开始转向为“求精”:咱们的响应时间是否比竞争对手快?咱们的用户体验是否比竞争对手好?咱们的成本是否比竞争对手低……
此时技术上其实也基本进入了成熟期,该拆的也拆了,该平台化的也平台化了,技术上能作的大动做其实也很少了,更多的是进行优化。但有时候也会为了知足某个优化,系统作很大的改变。例如,为了将用户响应时间从 200ms 下降到 50ms,可能就须要从不少方面进行优化:CDN、数据库、网络等。这个时候的技术优化没有固定的套路,只能按照竞争的要求,找出本身的弱项,而后逐项优化。在逐项优化时,能够采起以前各个时期采用的手段。
互联网业务的发展第二个主要方向就是“用户量愈来愈大”。互联网业务的发展会经历“初创期、发展期、竞争期、成熟期”几个阶段,不一样阶段典型的差异就是用户量的差异,用户量随着业务的发展而愈来愈大。
用户量增大对技术的影响主要体如今两个方面:性能要求愈来愈高、可用性要求愈来愈高。
1. 性能
用户量增大给技术带来的第一个挑战就是性能要求愈来愈高。以互联网企业最经常使用的 MySQL 为例,再简单的查询,再高的硬件配置,单台 MySQL 机器支撑的 TPS 和 QPS 最高也就是万级,低的多是几千,高的也不过几万。当用户量增加后,必然要考虑使用多台 MySQL,从一台 MySQL 到多台 MySQL 不是简单的数量的增长,而是本质上的改变,即原来集中式的存储变为了分布式的存储。
稍微有经验的工程师都会知道,分布式将会带来复杂度的大幅度上升。以 MySQL 为例,分布式 MySQL 要考虑分库分表、读写分离、复制、同步等不少问题。
2. 可用性
用户量增大对技术带来的第二个挑战就是可用性要求愈来愈高。当你有 1 万个用户的时候,宕机 1 小时可能也没有很大的影响;但当你有了 100 万用户的时候,宕机 10 分钟,投诉电话估计就被打爆了,这些用户再到朋友圈抱怨一下你的系统有多烂,极可能你就不会再有机会发展下一个 100 万用户了。
除了口碑的影响,可用性对收入的影响也会随着用户量增大而增大。1 万用户宕机 1 小时,你可能才损失了几千元;100 万用户宕机 10 分钟,损失可能就是几十万元了。
经过前面的分析,咱们能够看到互联网业务驱动技术发展的两大主要因素是复杂性和用户规模,而这两个因素的本质其实都是“量变带来质变”。
究竟用户规模发展到什么阶段才会由量变带来质变,虽然不一样的业务有所差异,但基本上能够按照下面这个模型去衡量。
应对业务质变带来的技术压力,不一样时期有不一样的处理方式,但无论什么样的方式,其核心目标都是为了知足业务“快”的要求,当发现你的业务快不起来的时候,其实就是技术的水平已经跟不上业务发展的须要了,技术变革和发展的时候就到了。更好的作法是在问题尚未真正暴露出来就可以根据趋势预测下一个转折点,提早作好技术上的准备,这对技术人员的要求是很是高的。
今天我为你讲了互联网技术演进的基本模式,但愿对你有所帮助。
这就是今天的所有内容,留一道思考题给你吧,参考今天文章的方法,简单分析一下你所在行业,看看是否存在典型的技术演进模式?
欢迎你把答案写到留言区,和我一块儿讨论。相信通过深度思考的回答,也会让你对知识的理解更加深入。(编辑乱入:精彩的留言有机会得到丰厚福利哦!)