架构设计 12-架构实战之技术演进

导读：《架构设计》系列为极客时间李运华老师《从0开始学架构》课程笔记。本文为第十二部分。主要介绍了技术演进的动力和演进模式，如不同时期所面临的问题以及该如何处理。

关注公众号 回复 “架构设计” 获取架构设计笔记完整思维导图

技术演进动力

• 对于产品类业务：技术创新推动业务发展！
• 对于“服务”类的业务：业务发展推动技术的发展！

互联网技术演进模式

互联网业务千差万别，但由于它们具有“规模决定一切”的相同点，其发展路径也基本上是一致的。互联网业务发展一般分为几个时期：

• 初创期
• 发展期
• 竞争期
• 成熟期

不同时期的差别主要体现

业务复杂性

初创期

初创期的业务对技术就一个要求：“快”，但这个时候却又是创业团队最弱小的时期，可能就几个技术人员，所以这个时候十八般武艺都需要用上：能买就买，有开源的就用开源的。

发展期

堆功能期

业务进入快速发展期的初期，此时团队规模也不大，业务需求又很紧，最快实现业务需求的方式是继续在原有的系统里面不断地增加新的功能，重构、优化、架构等方面的工作即使想做，也会受制于人力和业务发展的压力而放在一边。

优化期

• 优化派 核心思想是将现有的系统优化
• 架构派 核心思想是调整系统架构，主要是将原来的大系统拆分为多个互相配合的小系统。

架构期

• 经过优化期后，如果业务能够继续发展，慢慢就会发现优化也顶不住了，毕竟再怎么优化，系统的能力总是有极限的。
• 架构期可以用的手段很多，但归根结底可以总结为一个字“拆”，什么地方都可以拆。

竞争期

• 重复造轮子
• 系统交互一团乱麻

解决方案

平台化：目的在于解决“重复造轮子”的问题。

• 存储平台化：淘宝的 TFS、京东 JFS。
• 数据库平台化：百度的 DBProxy、淘宝 TDDL。
• 缓存平台化：Twitter 的 Twemproxy，豆瓣的 BeansDB、腾讯 TTC。

服务化：目的在于解决“系统交互”的问题，常见的做法是通过消息队列来完成系统间的异步通知，通过服务框架来完成系统间的同步调用。

• 消息队列：淘宝的 Notify、MetaQ，开源的 Kafka、ActiveMQ 等。
• 服务框架：Facebook 的 thrift、当当网的 Dubbox、淘宝的 HSF 等。

成熟期

此时技术上其实也基本进入了成熟期，该拆的也拆了，该平台化的也平台化了，技术上能做的大动作其实也不多了，更多的是进行优化。这个时候的技术优化没有固定的套路，只能按照竞争的要求，找出自己的弱项，然后逐项优化。在逐项优化时，可以采取之前各个时期采用的手段。

用户规模

用户量增大对技术的影响主要体现

• 性能要求越来越高
• 可用性要求越来越高

量变到质变

• 互联网业务驱动技术发展的两大主要因素是复杂性和用户规模，而这两个因素的本质其实都是“量变带来质变”。
• 应对业务质变带来的技术压力，不同时期有不同的处理方式，但不管什么样的方式，其核心目标都是为了满足业务“快”的要求，当发现你的业务快不起来的时候，其实就是技术的水平已经跟不上业务发展的需要了，技术变革和发展的时候就到了。

reference

1. 《从 0 开始学架构》 https://time.geekbang.org/column/intro/100006601?tab=catalog