架构第四周总结

淘宝业务发展及技术架构的学习心得

粗略的说, 淘宝技术发展主要经历了“个人网站”→“Oracle”→“Java 时代”→“分布式时代”。

为什么会这样发展? 每个阶段驱动力是什么?

1. 个人网站 (通过买解决“方案”)

最初的淘宝是买来的

决策的依据：当时对项目来说压力最大的就是时间，怎么在最短的时间内把一个从来就没有的网站从零开始建立起来？

淘宝在初创时，没有过多考虑技术是否优越、性能是否海量以及稳定性如何，主要的考虑因素就是：快！因为此时业务要求快速上线，时间不等人，等花几个月甚至十几个月搞出一个强大的系统出来，可能市场机会就没有了，黄花菜都凉了。

1. Oracle (通过买解决“性能”)

淘宝网推出后，由于正好碰到“非典”，网购很火爆，加上采取了成功的市场运作，流量和交易量迅速上涨，业务发展很快，MySQL 已经撑不住了。

决策的依据: 此时离刚上线才半年不到，业务飞速发展，最快的方式支撑业务的发展还是去买。

技术的替代方案非常简单，就是换成 Oracle。换 Oracle 的原因除了它容量大、稳定、安全、性能高，还有人才方面的原因。如果用分布式Mysql技术解决高并发问题，可能会引入更多的技术问题，导致错过高速增长期。如果可以接受成本，通过垂直伸缩, 不更改代码快速解决问题的方案依然是买。

1. Java时代 (通过技术解决问题, 分几个阶段)

PHP 迁移至 Java

决策的依据：在从别人买来的网站上快速开发功能对技术团队来说是很大的挑战。业务迅速发展，功能不断增加，开发跟不上响应以及PHP本身的问题。

Java 是当时最成熟的网站开发语言，它有比较良好的企业开发框架，被世界上主流的大规模网站普遍采用，另外有 Java 开发经验的人才也比较多，后续维护成本会比较低，放弃 PHP 使用 Java 奠定了淘宝的技术基础。

原有方案存在固有缺陷，随着业务的发展，随着规模的增大，纯粹靠买解决问题的思路已经不行了，其中一个重要原因就是成本，此时必须从整个架构上去进行调整和优化。

Java 时代，淘宝做了很多优化工作：数据分库、放弃 EJB、引入 Spring、加入缓存、加入 CDN、采用开源的 JBoss。这些工作都是围绕着提高容量、提高性能、节约成本来做的。

1. 分布式时代

各种技术爆炸，淘宝技术飞跃的开始。

此时淘宝已经确定技术方向和思路，到了这个阶段，自研技术已经自成一派，除了支撑本身的海量业务，也开始影响整个互联网的技术发展。



通过案例可以看出，即使是现在非常复杂、非常强大的架构，也并不是一开始就进行了复杂设计，而是首先采取了简单的方式（简单原则），满足了当时的业务需要（合适原则），随着业务的发展逐步演化而来的（演化原则）。架构也不是一开始就设计成完美的样子，然后可以一劳永逸一直用下去，架构需要面向业务需求，并在各种资源（人、财、物、时、事）约束条件下去做权衡、取舍。



合适原则

架构无优劣，但存合适性。架构一定要匹配企业所在的业务阶段，一定要匹配业务所处阶段，能够合理地将资源整合在一起并发挥出最大功效，并能够快速落地，高大上的架构不等于适用。



简单原则

简单比复杂更加困难。架构设计时如果简单的方案和复杂的方案都可以满足需求，最好选择简单的方案。当软件系统变得太复杂后，就会换一个思路进行重构、升级，将它重新变得简单，这是开发的大趋势。 简单原则是一个朴素且伟大的原则。



演化原则

业务在发展、技术在创新、外部环境在变化，这一切都是在告诫架构师不要贪大求全，或者盲目照搬大公司的做法。应该认真分析当前业务的特点，明确业务面临的主要问题，设计合理的架构，快速落地以满足业务需要，然后在运行过程中不断完善架构，不断随着业务演化架构。