五一期间终于读完了李智慧的《大型网站技术架构》。虽然是一本 2013 年的老书，但很多思想非常有启发性，即便 10 年之后读来仍然醍醐灌顶。

技术方面自然学到了很多东西，但更多的是收获了一些思想。

挑个重点说吧：书中反复出现的一个观点是，大部分情况下，是业务推动技术，而不是反过来。技术最终是为业务服务，是业务需求的增加推动了技术进步，而不是为了技术而改进技术。

我十分认同这个观点。

书里还举了一个特别好的例子：淘宝技术架构的演进。之前读过《淘宝技术这十年》这本书，熟悉这段历史，但作者的几句点评，又让我醍醐灌顶：

  • 最初（2003 年），淘宝花 3000 美元买了一个 PHP 网上拍卖系统的源码，稍作修改之后投入使用。这十分明智，因为初期业务最需要的就是尽快上线，买系统比自己从头研发要快很多，且PHP 很好上手；
  • 后来（2004 年），业务迅速扩张，淘宝迁到了基于 Java 的架构，数据库从 MySQL 换成了昂贵的 Oracle 数据库（部署在昂贵的 IBM 小型机和同样昂贵的 EMC 存储设备上），服务器换成了付费的WebLogic。这同样十分合理，因为在业务快速扩张期，保证服务稳定是第一位的，虽然需要支付高昂的费用，但最大程度避免了因为服务不稳定导致了用户流失；
  • 又过了几年，业务量增长到难以置信的规模，淘宝舍弃 Oracle、IBM 和 EMC，重新回归到开源的 MySQL 和 NoSQL 系统，并自研了许多基础架构产品（后来大多开源）。这仍然十分合理，因为业务到了这样的规模，问题是别人没有遇到过的，用最适合自己的方法最可靠。

总之，淘宝技术架构的演进完全是为业务服务，每个阶段的改变都是合理的。从技术的角度来看，如果一开始就使用开源 + 自研的架构岂不是更好？但实际不是这样，因为每个阶段的业务情况不同，就需要不同的技术解决方案。

技术归根结底是为业务服务的。

（由此延伸，只要能解决问题，用什么手段其实无所谓。比如 12306 抢票把服务器压垮的问题，换个更强大的技术架构当然可以，但另一方面，如果在业务上能换个策略，避免这种瞬时高流量，同样能解决问题。）

书里还有一些精彩洞见，推荐看一下原书。