从零开始学架构——互联网架构的演进

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 总结

• 产品类业务：技术创新推动业务发展。
• “服务”类的业务：业务发展推动技术的发展。
• 架构师需要基于业务发展阶段判断出系统当前面临的主要复杂度。
• 互联网业务千差万别，但都具有“规模决定一切”的特点。
• 互联网业务发展一般分为几个时期：初创期、快速发展期、竞争期、成熟期。
• 互联网业务发展第一个主要方向就是“业务越来越复杂”。
• 互联网业务发展第二个主要方向就是“用户量越来越大”。
• 互联网业务发展带来复杂度的本质原因其实都是“量变带来质变”。