从0开始学架构_40_39_互联网技术演进的模式
你好，我是华仔。
今天我和你分享的主题是互联网技术演进的模式。
由于各行业的业务发展轨迹并不完全相同，无法给出一个统一的模板，让所有的架构师拿来就套用。
因此呢，我以互联网的业务发展为案例，其他行业可以参考分析方法，对自己的行业进行分析，互联网业务千差万别。
但由于他们具有规模决定一切的相同点，其发展路径也基本上是一致的。
互联网业务发展一般分为几个时期，初创期、发展期、竞争期、成熟期。
不同时期的差别主要体现在两个方面，复杂性用户规模。
首先来看业务复杂性，互联网业务发展第一个主要方向就是业务越来越复杂。
我们来看看不同时期业务的复杂性的表现。
一、初创期互联网业务刚开始一般都是一个创新的业务点。
这个业务点的重点不在于完善，而在于创新。
只有创新才能吸引用户。
而且因为其新的特点，其实一开始是不可能很完善的。
只有随着越来越多的用户的使用，通过快速迭代试错、用户的反馈等手段不断的在实践中去完善，才能继续创新。
初创期的业务。
对技术就一个要求快。
但这个时候却又是创业团队最弱小的时期，可能就几个技术人员。
所以这个时候十八般武艺都需要用上能买就买，有开源的就用开源的。
二、发展期。
当业务推出后，经过市场验证，如果是可行的，则吸引的用户就会越来越多。
此时，原来不完善的业务就进入了一个快速发展的时期。
业务快速发展时期的主要目的是将原来不完善的业务逐渐完善，因此会有越来越多的新功能不断的加入到系统中。
对于绝大部分技术团队来说，这个阶段技术的核心工作是快速的实现各种需求，只有这样才能满足业务发展的需要。
如何做到快？一般会经历下面几个阶段，分别为堆功能期、优化期、架构期业务进入快速发展期的初期。
此时团队规模也不大，业务需求又很紧，最快实现业务需求的方式是继续在原有的系统里面不断的增加新的功能，重构、优化架构等方面的工作，即使想做也会受制于人力和业务发展的压力，而放在一边堆功能的方式在刚开始的时候好用，因为系统还比较简单。
但随着功能越来越，多系统开始变得越来越复杂，后面继续堆功能会感到越来越吃力，速度越来越慢。
一种典型的场景是做一个需求要改，好多地方一不小心就改出了问题。
直到有一天，技术团队或者产品人员再也受不了这种慢速的方式，终于下定决定要解决这个问题了。
如何解决这个问题？一般会分为两派，一派是优化派，一派是架构派。
优化派的核心思想是将现有的系统优化，例如采用重构分层优化某个mysql查询语句，将机械硬盘换成SSD,将数据库从mysql换成oracle,增加mam cash缓存等。
优化派的优势是对系统改动较小，优化，可以比较快速的实施。
缺点，就是可能过不了多久，系统又撑不住了。
架构派的核心思想是调整系统架构，主要是将原来的大系统拆分为多个互相配合的小系统。
例如，将购物系统拆分为登录、认证子系统、订单系统、查询、系统分析系统等。
架构派的优势是一次调整，可以支撑比较长期的业务发展。
缺点是动作较大，耗时较长，对业务的发展影响也比较大。
相信在很多公司都遇到这种情况，大部分情况下都是优化派会赢，主要的原因还是因为此时优化是最快的方式。
至于说优化派支撑不了多久这个问题呢，其实也不用考虑太多，因为业务能否发展到那个阶段，还是个未知数，保证当下的竞争力是最主要的问题。
经过优化期后，如果业务能够继续发展，慢慢就会发现优化也顶不住了。
毕竟再怎么优化系统的能力总是有极限的。
Oracle再强大，也不可能一台oracle顶住一亿的交易量。
小星期再好，也不可能一台机器支持一百万在线人数，此时已经没有别的选择，只能进行架构调整。
在优化期被压制的架构派开始扬眉吐气了，甚至会骄傲的说看看吧，早就说要进行架构调整，你们偏要优化，现在还是顶不住了吧。
哼。
架构期可以用的手段很多，但归根结底可以总结为一个字，拆什么地方都可以拆拆功能。
例如，将购物系统拆分为登录、认证、子系统、订单系统、查询系统分析系统等。
拆数据库、mysql一台变两台、两台变四台、增加DB、 proxy、分库分表等。
拆服务器服务器一台变两台、两台变四台，增加负载均衡的系统，如enginex、 HA、 proxy等。
三、竞争期，当业务继续发展已经形成一定规模后，一定会有竞争对手开始加入行业来竞争。
毕竟谁都想分一块蛋糕，甚至有可能一不小心还会成为下一个BAT.当竞争对手加入后，大家互相学习和模仿业务更加完善，也不断有新的业务创新出来。
而且由于竞争的压力，对技术的要求是更上一层楼了。
新业务的创新给技术带来的典型压力就是新的系统会更多，同时原有的系统也会拆的越来越多。
两者合力的一个典型后果就是系统数量在原来的基础上又增加了很多架构，拆分后带来的美好时光又开始慢慢消失，技术工作又开始进入了慢的状态，这又是怎么回事呢？原来系统数量越来越多，到了一个临界点后，就产生了质变及系统数量的变量，带来了技术工作的质变，主要体现在下面几个方面。
第一，重复造轮子系统越来越多，各系统相似的工作越来越多。
例如，每个系统都有存储，都要用缓存，都要用数据库新建一个系统，这些工作又要多做一遍，即使其他系统已经做过了一遍，这样怎么能快得起来？第二，系统交互一团乱麻，系统越来越多。
各系统的交互关系变成了网状系统间的交互数量和系统的数量、成平方比的关系。
例如四个系统的交互路径。
十六个十个系统的交互路径是四十五个，每实现一个业务需求都需要几个甚至十几个系统一起改，然后互相调用来调用去。
联调成了研发人员的灾难。
联测成了测试人员的灾难，部署成了运维的灾难。
针对这个时期业务变化带来的问题，技术工作主要的解决手段有平台化和服务化。
平台化，目的在于解决重复造轮子的问题。
比如存储平台化，有淘宝的TFS、京东JFS数据库平台化，有百度的DB proxy、淘宝TDDL缓存平台化，有twitter的two m proxy、豆瓣的bs DB、腾讯TTC服务化，目的在于解决系统交互的问题。
常见的做法是通过消息队列来完成系统间的异步通知，通过服务框架来完成系统间的同步调用。
比如消息队列有淘宝的notify、 meter、 q开源的kafka、 active、 MQ等。
服务框架有facebook的thrift、当当网的double x淘宝的HSF等。
四、成熟期。
当企业熬过竞争期成为了行业的领头羊，或者整个行业整体上已经处于比较成熟的阶段，市场地位已经比较牢固后，业务创新的机会已经不大，竞争压力也没有那么激烈。
此时，球快球新已经没有很大空间，业务上开始转向为求精。
我们的响应时间是否比竞争对手快？我们的用户体验是否比竞争对手好？我们的成本是否比竞争对手低？此时技术上其实也基本进入了成熟期，该拆的也拆了，该平台化的也平台化了，技术上能做的大动作其实也不多了，更多的是进行优化。
但有时候也会为了满足某个优化系统做很大的改变。
例如，为了将用户响应时间从两百毫秒降低到五十毫秒，可能就需要从很多方面进行优化。
Cdn数据库、网络等。
这个时候的技术优化，没有固定的套路，只能按照竞争的要求找出自己的弱项，然后逐项优化。
在逐项优化时，可以采取之前各个时期采用的手段。
接下来我们来看用户规模互联网业务的发展。
第二个，主要方向就是用户量越来越大。
互联网业务的发展会经历初创期、发展期、竞争期、成熟期几个阶段、不同阶段，典型的差别就是用户量的差别。
用户量随着业务的发展而越来越大，用户量增大对技术的影响主要体现在两个方面，性能要求越来越高可用性要求越来越高一。
性能用户量增大给技术带来的第一个挑战就是性能要求越来越高。
以互联网企业最常用的mysql为例，在简单的查询再高的硬件配置单台，mysql机器支撑的TPS和QPS最高，也就是万级低的，可能是几千高的，也不过几万。
当用户量增长后，必然要考虑使用多台mysql,从一台mysql到多台mysql不是简单的数量的增加，而是本质上的改变，即原来集中式的存储变为了分布式的存储。
稍微有经验的工程师都会知道，分布式将会带来复杂度的大幅上升。
以mysql为例，分布式mysql要考虑分库分表、读写分离、复制同步等很多问题。
二、可用性用户量增大对技术带来的第二个挑战就是可用性要求越来越高。
当你有一万个用户的时候，宕机一小时可能也没有很大的影响。
但当你有了一百万用户的时候，宕机十分钟投诉电话估计都被打爆了。
这些用户再到朋友圈抱怨一下，你的系统有多烂，很可能你就不会再有机会发展下一个一百万用户了。
除了口碑的影响，可用性对收入的影响也会随着用户量增大而增大。
一万用户宕机一小时，你可能才损失了几千元一百万用户宕机十分钟损失啊可能就是几十万元了。
通过前面的分析，我们可以看到，互联网业务驱动技术发展的两大主要因素是复杂性和用户规模。
而这两个因素的本质，其实都是量变带来质变。
究竟用户规模发展到什么阶段，才会有量变带来质变？虽然不同的业务有所差别，但基本上可以按照文稿中这个模型去衡量应对业务质变带来的技术压力。
不同时期有不同的处理方式，但不管什么样的方式，其核心目标都是为了满足业务快的要求。
当发现你的业务快不起来的时候，其实就是技术的水平已经跟不上业务发展的需要了。
技术变革和发展的时候就到了更好的做法，是在问题还没有真正暴露出来，就能够根据趋势预测下一个转折点，提前做好技术上的准备，这对技术人员的要求是非常高的。
今天我为你讲了互联网技术演进的基本模式，希望对你有所帮助。
这就是今天的全部内容，留一道思考题给你吧。
参考今天文章的方法，简单分析一下你所在行业，看看是否存在典型的技术演进模式。
欢迎你把答案写到留言区，和我一起讨论。
相信经过深度思考的回答，也会让你对知识的理解更加深刻。