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

从100PV到1亿级PV网站架构演变一个网站就像一个人，存在一个从小到大的过程。养一个网站和养一个人一样，不同时期需要不同的方法，不同的方法下有共同的原则。本文结合我自已14年网站人的经历记录一些架构演变中的体会。　　1：积累是必不可少的架构师不是一天练成的。1999年，我作了一个个人主页，在学校内的虚拟空间，参加了一次主页大赛，几个DREAMWEAVER的页面，几个TABLE作布局，一个DB连接，几行PHP的代码嵌入在HTML中，再用FTP传到服务器上就可以给别人展示一个网站。2000年，个人主页已经不能满足好奇，在当时的网管中心管起几台机器，作起网线水晶头，用ALLPEOPLESEEMSTONEEDDATAPROCESS的理论开始认识了7层网络模块(面试技术员工时，经常会问这些网络基础知识的理解)。有了基础理论的武装，我也开始配置各种服务来玩LINUX，AIX和FREEBSD这些系统。面对各种原理不懂的系统，目的只是想尽办法去解决网站需要的各种基础服务。当时搭建了REALSERVER流媒体服务，各种开源FTP下载服务，BATTLENET游戏网关，APACHE(keepalive等配置，http报头相关的知识也是面试的老客户)，DNS，QMAIL等服务给学校的学生使用;网站有近10万PV的时候，开始考虑如何作扩展拆分，MYSQL的MASTERSLAVE作读写分离，MYSQL的索引优化是当时唯一会使用的DB性能优化方法。这个阶段基本上能解决需求，同时也遇到瓶颈，不知道访问量再大一个数量级，怎么办?明显感到技术能力不够。当时受限于网站的量一直没有新的数量级的突破，导致了几年内技术工作以维护为主，体验着网站日常运维的各种纠结，体力活。而这时期网站的2层架构方法也一再被重复应用到后续的N个网站的搭建过程中，2001年开始的JSP与PHP之争好像对我没什么感觉，因为我还是只会用那种很土的2层架构作着网站：页面中嵌入JSP，连接后端的MYSQL进行数据的CRUD，没有事务，没有考虑数据库读写错误，没有考虑两层系统不可用，因为有问题只需要重启，有报错只需要改JSP后刷新页面。作网站确实是体力活。2005年，在道富参与了FXCNG项目，用MULEESB，接触到MULE的前几个月还没有意识到这个系统在架构中的位置。直到半年后，在与第三方系统集成的应用中，才发现，这样的一个系统就是传说中的中间件，他可以专业的解决一部份系统的职能，比如当时的消息和远程调用代理。这时候我逐步有了一些架构观点，一个大型的应用系统中，是需要隔离一部份技术职能，让系统责任单一，方便技术维护和团队扩展，专人办专事。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的在线交易系统。遇到了很多问题，体会到一个小系统与大网站不同阶段架构的演变过程有不同的难处。下文从不同维度分享亿级PV网站架构下我的体会和观点。　　2：知识结构网站架构师有很多，有科班出身的，有美术专业的，有生物专业的，有学物理的，有派出所警察出身的，我觉得都是OK的。我也接触到了这些架构师，非常有特点，在很多技术领域有自已专深的。英雄不问出路，好汉不提当年勇。架构师知识背景可以不同，个人看法是不同领域的人作网站架构可以带入很多交叉的思路。就像种树的人再去种花，其实也是可以看到一些共性的总结抽象。网站架构师需要有编程的经验，从基本的算法，常用的设计模式，多线程开发，远程调用，不同类型数据源使用，这些是面试的时候看得基本功。我认为一个资深的测试专家一定是开发高手，一个架构师必须也是有长期的开发经验，很多性能优化是要从一行行代码优化起的。试想在一个被调用1000万次次每天的页面，一行代码如果每次都走到，每次少运算1ns,也可以节省不少的电力。我为环保作贡献，我骄傲。网站架构师需要对网络环境有很好的知识理解。架构问题是需要考虑网络部署。比如系统因不可用而发生切换的时候，从一个机房切到另一个机房，要考虑网站的服务对用户访问速度上会有多大影响。这时候的技术方案可能是切DNS，也可能是切前端的跳转机，或是底层部份服务调用到另一个机房。对于这类切换的方案，架构师需要计算网络时间的开销带来的QPS影响，和用户体验上的延迟，每个请求估算需要精确到ms级。如果是全球范围内DNS切换，需要知道DNS刷新的时间经验周期，比如：全球更新在1小时左右，而80%的地区用户会在20分钟内刷新，这样系统带来的业务影响会有多大。网站架构师需要对网络协议有深入的理解。HTTP协议是最基础的，无论是SESSION还是COOKIE在HTTP协议基础上怎么应用，COOKIE的大小，数量，浏览器是怎么处理HTTP协议的。这些基础有关键时候会影响业务的进行。比如，SAFRI浏览器对第三方COOKIE是禁用的，某功能跨域写COOKIE的时候每次都会重新生成COOKIE，直接导致系统统计用户UV的时候，数量增大，影响各种转化率的计算。HTTP协议还需要考虑本身的连接管理池大小和连接是否KEEPALIVE，这些细节很多时候成为架构上扩展能力的瓶颈。一个静态页面服务的HTTPMAXCLIENT设置为2500，机器只有10台，很可能在一次中小型活动中连接数到顶，用户部份请求无法满足。架构师需要考虑数据格式带来的性能影响。很多远程系统调用走的是HTTP协议为基础，数据格式为纯文本或JSON，或XML等，这类调用需要考虑数据的序列化和反序列化，这个工作是CPU开销型的，对性能优化上需要有针对性。QPS高的系统RT一定会短，但RT短的系统不一定比RT高的系统能表现更好的QPS。架构师需要有很好的数学能力，计算一个QPS里系统从网络请求发出，到网络的IO时间，DB的磁盘读写时间，CPU运算时间，再到数据库连接数，数据分库分表容量规划，都需要有精确的计算。因为容量计算不正确带来问题也是非常多的。比如一台小机上ORACLE的连接数开了2000个，而应用系统由于不断的扩展，小业务系统不断加入，大型促销活动前，临时机器的不断上线，很快就把DB连接数用完，引起业务部份不可用。架构师需要去合理估算每种应用的服务能力，以及他对DB等资源的合理连接数。加构师对JVM的内存分区及管理策略要有深入的了解，GC的频率可以发现很多系统容量的问题。一个OLD区不断加大的系统，伴随YGC高频发生，加上TCP机器连接数很可能高，可能是要是机器了。一个业务功能不断叠加的系统，很可能PERM区会需要加大设置，否则容易OUTOFMEMORY。加构师需要精读《数据库系统概念》这类书，对不同DB的索引原理和库表存储结构有了解，我们可以不是ORACLEACE，但一定要听得懂ACE的DB架构和性能优化方面的建议。并且在原则上，前端用户系统架构上不要出现直连DB的设计，这是亿级PV架构的基础设计保障，特别是一些营销类功能系统，短时并发大的页面不能有DB直连，一些小应用可例外对待。架构师需要很好的学习能力，技术是不断变化的，昨天用DUBBO，明天可能要换HSF;今天MEMCACHE，明天可能REDIS;今天刚刚把应用拆分，明天可能就要合并。公司外的技术社区还不断有一些好的开源中间件和框架出来，需要不断学习，关注。大网站的架构模式不一定合适小网站，新中间件和框架实施需要考虑运维成本和学习推广成本，架构上要选合适当前阶段的。架构师需要和不同类型的专业人才沟通，所以要能快速理解并学习不同专业的知识去补充自身的知识结构不足。架构师需要理解业务，在一些业务系统型的网站，业务架构师也显得异常关键，比如像交易型系统，支付型系统。业务架构师需要解决业务层次结构，业务边界划分，业务优先级与技术优先级的平衡。传统软件的系统分析师不知道是否也干这角色?但互联网的业务架构师要求更高，应该是建立在系统架构师的基础上再看高一层，通过业务和技术的综合影响力去帮助网站取得合理的架构，更好得拿到业务结果。网站架构师的知识结构是宽又深的。　　3：设计理念每个架构师都会有一些自已原设计理念和原则。我的基本思路是：架构要作到至少1年的预见性(半年不叫预见性，因为方案实施要半年)。设计的目标是尽量让系统可以水平扩展，并利于。当然，有些业务处在生存的边缘，可能架构方案只有几个月的生命力。但一些成本不高收益稳定的架构理念，不管什么时候都是值得优先考虑的。以下是架构设计的一些常用手段。　1：异步换同步：系统中的很多调用是可以异步化的，包括WEB界面上的AJAX异步，还有服务端的消息型异步;AJAX调用的应用要注意把这种类型的应用集中到一个隔离的服务系统中，以方便在必要的时候进行服务降级。AJAX调用一般都是界面上非同步非强依赖的功能点;服务端异步的系统可以让服务端的请求RT变短，提升服务器QPS，同时减少应用强依赖。一个小型系统(峰值万级消息persecond)的服务端异步消息可以借助RMDB的表实现，当网站规模变大时(峰值百万级消息每秒)，消息系统需要有一个中间件，负责消息持久化及数据CRUD管理;再大点的时候，消息中间件的分布式与可用性会有更高要求，需要综合使用多种架构设计理念;同步换异步对软件工程上的好处是，可以把一个子系统的不同模块分别由不同的人开发维护，调试期间，两个模块也不会有很强的依赖。提高开发并发性。　　2:集中变分布：一个网站小的时候，很多业务都会在一两个应用系统中实现。比如一