《淘宝技术这十年》读后感

最近拜读了《淘宝技术这十年》，大致的了解了淘宝网在过去将近十年的某些技术的变化，其中深有体会的两点便是：

1. 优秀的架构不是一蹶而就的，它是随着业务的增长而不断进化与完善，并在不断的重构与技术创新中得到升华的；
2. 良好的架构设计与实现应该同时考虑到成本的控制，包括经济成本与时间成本；

之所以会对这几点有特别的感触，大概与两个项目有关。

一：初出茅庐

刚毕业那会儿，在相继看完《大型网站技术架构：核心原理与案例分析》、《大型分布式网站架构设计与实践》、《大型网站系统与Java中间件实践》三本书后，总感觉一个系统的架构应该一上来就按着分布式按着集群的架构来搞，这在之后着实影响了我一小段时间，最实际的一次是有一次公司需要做一个系统，它的背景及主要功能大概是：通过调用其它部门的API收集数据，然后将各种数据收集起来（可能会进行自定义的计算）并展示给用户，用户人数当前目测在一段时间后会有10万人以上（当时市场的会员人数好像远不止这么多），就是这么一个看似简单的业务（当然也会有其它功能），不过首页上展示的数据实在是很多，就当时设计的首页图片就下拉了很长时间，我觉得这个业务有个很重要的特点便是：
1) 读多写少（几乎不会写），所以不需要考虑数据一致性；
2) 同一页面需要展示大量的数据，不可能一次便读出所有数据，需要多次加载。

在第一次讨论架构设计的时候，我的想法是：
1) 不能过多依赖API，应在API与控制器调用之间加入缓存层（Redis），并将从API获取的数据同时保存在数据库（Orcale），后台由专门的任务抓取数据并存入数据库和缓存，那么控制器如果没有命中缓存，就去数据库中找，最后才是API性；
2) 首页数据量过多，应适当延迟加载（比如下拉下去再加载），于此同时，为了保证网站的可用性，应按业务区分模块，并将不同模块部署到不同的服务器（这样会涉及到分布式的开发），这样即使某一个业务数据除了问题，也不会让整个网站不可用；
3) 使用Nginx集群。

当时可能是讨论太激烈了，也就按着这几步说下去了，最后的初步讨论的结果也离这不远，但是有几点被我忽略了，也有我知识不足导致的：
1) 网站初期的用户量，不可能一下就达预期的目标；
2) 开发成本，即使公司有钱，但是时间不等人；
3) 我们能目测用户人数大概多少，但是这些人带给网站的指标（比如最高并发数、容量等）对系统的影响，没有一个确定的结果（比如一个Tomcat服务器能承受多少会员的同时使用、一万个会员会带来多少并发量、容量等）。

以上的几点最容易导致的便是过度设计，而事实也确实过度设计了（虽然不是我们小组做这个项目，后面项目实际怎么做的也不太清楚）。首先从开发时间上来说，如果一开始就按业务区分模块然后每个模块一个项目来开发，那么对于公共类的提取、修改必然是一个很繁琐的过程（底层jar包总不能改一个地方就得复制到多个项目中去吧），同时也可能会涉及到一些RPC调用，这部分开发也必然很耗时间，等等这些必然导致开发时间的增长，而很多互联网产品，是寸光寸金的，于此同时也增大了快速响应的难度。其次连承受譬如10万会员需要多少服务器才能保证实时性、稳定性最好，都不知道就说要分布式要集群式是很盲目的。

所以后来我觉得刚开始开发时就应在一个Project中开发，于此同时，保证各个业务之间尽量的相互独立性（低耦合，这样以后要分离也不会照成特别的干扰），等到公共类完善之后、用户人数也上去之后（刚开始上线能有千人左右就不错了），再根据实际情况做拆分，而缓存如果时间特别紧可以先等出版上线后再慢慢开发（因为当时团队会用的人很少），等等这些改善的项目最终的目的是：
1) 缩短正式上线的时间；
2) 方便提取共有的模块；
3) 后期可根据实际情况做拆分或其他变更；
4) …

这次的经历犯的最大错误便是：忽略了开发成本，与网站实际需要承受的压力，而导致了过度设计，一部分来源于我的经验不足，另一部分来源于我的知识不够细致，对性能把握不到位。虽然最开始的设计也能满足需求，但是无疑是增大了开发成本。

二：人手有限

这个项目主要是包括对大数据集群的监控，以及SQL自助运行平台（以前开发都是通过DBA来执行某些重要的SQL，现在就是希望通过这个平台来代替DBA的这部分工作）等，这个项目并不算大，但是开发人员也很少，由于台湾的同事去美国了，并且因为时差以及他有很多其它的事要忙，所以大部分开发已经落到了我的头上。一方面，DBA希望功能能快速上线，另一方面，开发人员又很少，所以，我的想法就是，能省就先省着，比如正开发着，发现一个页面的数据展示必须用到缓存（因为需要多次从接口获取数据，并进行计算，最后才能展示给用户，但是与接口的服务器有些不是同一个局域网内，速度会稍微有点慢，多次获取就延迟很明显了），如果这时候使用mongodb、redis之类的，可能需要申请机器、安装数据库（下载软件也需要申请权限）之类的，所以就干脆缓存到文件里好了，写的时候可能会照成读不到数据，就加一个类似于数据库行锁的设计，同时保证它以后能很方便的就替换成NoSql数据库，就算完成了，这样功能上线的时候加快了，也避免了过早的就使用太多机器。

后来在设计与开发SQL自助运行平台的时候，更是加剧了我的架构应该考虑成本，并尽量用最小的成本满足需求的这种思想，因为时间真的很紧急，并且人手有限，每加大一个功能的设计便是实打实的加大了开发时间，所以这时候最优的设计便是，尽量用最简单的架构满足业务需求，并保证架构的高度可扩展性，后期再根据实际情况不断的修复、完善与升级。

三：不忘初衷

再回到《淘宝技术这十年》，淘宝从最开始的买别人的系统到后期的自己研发，以及研发过程中的不断创造技术，一方面说明了，即使是淘宝这样业内顶尖优秀的系统也是从一个小系统发展而来的，它的架构变化以及技术创新是随着业务的发展而不断变化与升华的，另一方面也侧面反映了，任何架构的设计都应该结合业务，并针对业务的发展而考虑出它的扩展性。

之前听过业内一个大神说过，任何架构的设计都应该不忘初衷。