从100PV到1亿级PV网站架构演变

  一个网站就像一个人，存在一个从小到大的过程。养一个网站和养一个人一样，不同时期需要不同的方法，不同的方法下有共同的原则。本文结合我自已14年网站人的经历记录一些架构演变中的体会。

1：积累是必不可少的
架构师不是一天练成的。

1999年，我作了一个个人主页，在学校内的虚拟空间，参加了一次主页大赛，几个DREAMWEAVER的页面，几个TABLE作布局，一个DB连接，几行PHP的代码嵌入在HTML中，再用FTP传到服务器上就可以给别人展示一个网站。

2000年，个人主页已经不能满足好奇，在当时的网管中心管起几台机器，作起网线水晶头，用ALL PEOPLE SEEMS TO NEED DATA PROCESS的理论开始认识了7层网络模块（面试技术员工时，经常会问这些网络基础知识的理解）。有了基础理论的武装，我也开始配置各种服务来玩LINUX，AIX和FREEBSD这些系统。面对各种原理不懂的系统，目的只是想尽办法去解决网站需要的各种基础服务。当时搭建了REALSERVER流媒体服务，各种开源FTP下载服务，BATTLENET游戏网关，APACHE（keepalive等配置，http报头相关的知识 也是面试的老客户），DNS，QMAIL等服务给学校的学生使用；

网站有近10万PV的时候，开始考虑如何作扩展拆分，MYSQL的MASTER SLAVE作读写分离，MYSQL的索引优化是当时唯一会使用的DB性能优化方法。这个阶段基本上能解决需求，同时也遇到瓶颈，不知道访问量再大一个数量级，怎么办?明显感到技术能力不够。当时受限于网站的量一直没有新的数量级的突破，导致了几年内技术工作以维护为主，体验着网站日常运维的各种纠结，体力活。而这时期网站的2层架构方法也一再被重复应用到后续的N个网站的搭建过程中，2001年开始的JSP与PHP之争好像对我没什么感觉，因为我还是只会用那种很土的2层架构作着网站：页面中嵌入JSP，连接后端的MYSQL进行数据的CRUD，没有事务，没有考虑数据库读写错误，没有考虑两层系统不可用，因为有问题只需要重启，有报错只需要改JSP后刷新页面。作网站确实是体力活。

2005年，在道富参与了FXCNG项目，用MULE ESB，接触到MULE的前几个月还没有意识到这个系统在架构中的位置。直到半年后，在与第三方系统集成的应用中，才发现，这样的一个系统就是传说中的中间件，他可以专业的解决一部份系统的职能，比如当时的消息和 52 28936 52 15232 0 0 3892 0 0:00:07 0:00:03 0:00:04 3892程调用代理。这时候我逐步有了一些架构观点，一个大型的应用系统中，是需要隔离一部份技术职能，让系统责任单一，方便技术维护和团队扩展，专人办专事。

2006年，阿里软件，一个全新的开始。进入阿里软件的前三个月在马总的老家，淘宝的发源地：湖畔花园小区，2楼的4室两厅里进行了封闭式开发，很累，但很兴奋。这段时间，我参与了一个全新外贸ERP系统的搭建。虽然只作为一名普通的JAVA开发工程师，仅负责一个很小的模块开发，但还是正式体会到一个大型系统的初创过程。这段时间对MVC的架构理论有了深刻的理解。MVC三层架构比2层架构带来的更好的技术扩展与团队扩展能力让我映像深刻。M层负责DB逻辑的CRUD，架构师们开发出了大量的中间层JAR包，完成了DAO层，DO的封装，M层也完成了SERVICE层，完成了BO的封装，接口包的封装，系统使用了最常用的工厂、单例、FACACE等模式（直到现在，我面试人还是常常只会问这些基本的模式）。V层的模板隔离，前端开发可以在这一层和后端开发一起修改界面（之后，更大规模的团队连这一层都可以再分离）。C层完成输入输出的基本校验和检查然后调用后面的服务层功能或作转发。 简洁朴素的结构生命力是比较持久的。直到现在，MVC还是具有很强的生命力，在更种大型网站中承担重要架构骨架。

07年，我对应用层，服务中心层，持久层三层架构并没有多少的实践应用和理解。因为MVC对于初创系统或中小型网站，20人左右的团队规模来讲，已经适用。换个角度看，当时在3个月内作出一个完整的ERP系统也只用使用MVC，再选进的架构也需要考虑网站发展的阶段。用户一边使用，工程师一边迭代改进架构，这个方式是作网站，不是传统应用软件开发。ERP本身源自传统应用软件领域，我们在用互联网的方式作管理软件，最大的挑战应该是这种边作边改进架构的理念。07年，这个理念之争逐步在团队内达成了一致，架构师们小心的平衡着业务和架构，这个网站高峰时，也支撑到了日访问量近千万的级别，没有闪架。

08年，阿里软件开放平台，又是一个新系统。全新的系统架构总是可以得到足够的时间来考虑末来1到3年的增涨。实际上，互联网系统，我们感觉只能考虑到一年的架构。这一年，我参与架构设计，开始理解了三层架构的价值与扩展能理，服务中心开始搭建，因为这个系统将接受的几百万在线的旺旺用户访问，所以部份系统开始考虑服务中心，想把业务逻辑聚合到服务层，由统一的团队进行扩展维护。另外，随着两年下来小的业务系统越来越多，小机上的oracle连接数也吃紧了，服务中心的需求越来越大。首先进行的是用户中心，想法是集成整个集团队账号体系，基于『旺号』体系。这个用户中心项目有个响亮的名字：UDB，项目过程可以写一本书。这里不再展开。

《SAAS架构设计》这本书，针对的是软件平台的早期ISV用户。现在的眼光来看，这书写的过于简单，正如十年后再来看今天我的写的这个笔记一样。
09年，加盟了刚刚成立的aliexpress部门。经历了两三个应用的小系统到亿级PV的在线交易系统。遇到了很多问题，体会到一个小系统与大网站不同阶段架构的演变过程有不同的难处。

更多内容见下一篇。