大型电商网站架构演进之路

写在开头

现在电商网站越来越多，除了阿里、京东、唯品会、聚美优品这种耳熟能详的巨头还有很多垂直领域的，比如找钢网、酒仙网、本来生活、Roseonly等，这些网站的主流功能基本类似，无非是完成整个交易流程，但是由于面向的用户量级不一样，所处的发展阶段不一样，背后的实现方式也是有很大的差别，下面来给大家聊聊大型电商的架构演变之路.

大型电商网站，已经不只是WEB

早些年提起电商网站，人们会说不就是一个web网站吗，跟BBS基本类似，网上还有很多开源的版本，最出名的应该就是EShop和Shopex了，十几兆的源码拿过来，分分钟就自己可以搭建一个电商网站。但是我想说现在的大型电商网站已经不止是 HTML、Apache、IIS、Lighttpd、JAVA、C/C++、PHP、MySQL、Mssql、Oracle。。。还有跨进程通信、数据缓存、磁盘ＩＯ优化、大容量存储、分布式计算、负载均衡、网络安排、IDC建设。。。

架构演变之一:物理分离webserver与数据库

上文提到最简单的电商网站一台机器就可以搞定，类似ecshop，webserver与数据库放在一台机器上一样可以搭起个电商网站，从外观看还是挺像模像样的，笔者曾用ecshop给朋友搭建过电商网站，效果如下从外观看绝对想不到这是一台机器搭建起来的.

上面的这个网站尽管样式很漂亮、该有的功能也都有了，但是实践中你会发现，自己玩玩还行，真的投入生产恐怕噩梦就来了，随便搞个活动，当同时有几十人或者上百人来下单的时候，你就会发现有人开始抱怨网站打开不，或者响应很慢了。这个时候你能做的就是重启机器，然后起来后没几分钟网站再挂掉，然后你再重启机器。。。

因为一台机器的CPU、内存、硬盘IO读取都是有上限的，而且很容易就达到这种上限，当CPU或者内存或者硬盘任何一个达到上限的时候就是用户崩溃你要重启机器的时候了，那面对这种情况应该如何优化呢？下面来介绍演变的第一步，webserver与数据库分离，既然一台机器有瓶颈那我们就想办法部署在多台机器上，最常用的方法就是把webserver与数据库进行分离，分别部署在不同的机器上，进行物理的分离。通常将webserver部署在一台机器，数据库部署在另外一台机器上，这种演进方式比最初的单台机器扩展性稍微好些，性能至少可以翻一倍。

架构演变之二：增加页面缓存

按照上面的方法将webserver与数据库分离后，你的网站性能会提升些，但还不足以让你高枕无忧淘宝网页结构是什么，用户稍微再多一点，估计PV在万级的时候，你将面临的挑战是数据库压力大，连接数多，响应比较慢。这个时候可以优化的方案是增加页面缓存，因为电商上有些页面相对比较静态，例如一些活动页，这些页面如果也请求到webserver，再到底层数据库就是比较浪费资源了，这种页面是可以进行缓存起来的，不需要耗费后面网站的资源，前端页面缓存的方式有很多，比较常用的是squid反向代理。

squid反向代理的好处是可以降低web服务器的负载，加速客户端浏览。代理可以缓存一些web的页面，降低web服务器的访问量，所以可以降低web服务器的负载,web服务器同时处理的请求数少了，响应时间自然就快了；同时代理也缓存了一些页面，可以直接返给客户端。

演变之三：页面片段缓存，小数据量异步请求

有了squid的反向代理，性能可以有一定幅度的提升，但是电商的纯静态页面还是比较少的，单纯通过squid缓存技术并不能解决问题，电商中请求量最大的是活动页和商详，这两个地方都不是纯静态页面，商品的价格、促销、库存都要实时或者准实时展示，如果整个页面缓存下来会存在用户看到的价格跟实际的价格不一致，针对这种情况，我们需要把一个页面再分解下，例如商详，主图、文描这种都是基本固定的，价格、促销、库存是实时在变化的，所有比较好的方案是将主图、文描这种基本不变化的缓存下来，价格、促销、库存通过ajax异步读取。

架构演变之四：数据缓存

页面缓存，异步读取后，网站下一步遇到的瓶颈会是在哪里呢？DB、DB还是DB，每一次的异步请求，基本都要把请求打到DB这一层，商品的最新价格要从DB读取，商品的最新库存数量要从DB读取，这时候DB的读取速度就是整个网站的瓶颈所在，那么如何解决这个问题呢？ 缓存、缓存、还是缓存。将不是经常变动的数据进行缓存，常用的缓存方式redis或者memcache都可以，如何使用缓存，看似简单其实有很多学问在里面，这里只提几个关键的点，大家可以自己思考下，使用缓存的时候需要考虑的因素有：什么样的数据适合缓存？是不是DB所有的数据都有必要缓存？如何保持缓存与DB的数据一致性？采用本机缓存还是网络缓存？本机缓存又分进程级缓存还是共享内存？如何提高缓存的命中率？缓存需不需要持久化？缓存的淘汰机制怎样选择？关于缓存的使用后面找时间单独开篇介绍下。增加了数据缓存后，这种方式性能可以有比较大的提升，支持个几十万至百万左右的PV应该是不成问题的。目前市面上的中小型的电商网站应该大部分采用这种架构，这种架构基本已经可以支持中小型电商的性能要求

下面介绍国内中大型电商网站架构

类似唯品会、聚美优品，京东、淘宝

架构演变之五：webserver集群

对于大型电商网站来说，随着用户数量的猛增上面提到的方法也已经不能够支撑起业务的发展，对于一个中型或大型的电商网站来说用户数量至少都是在千万级别，每天的订单量至少是在十万或者百万级别，而且电商的一大特点是大促期间的请求量一般是平时的10倍，甚至几十倍。像国内每年的双十一、618这种大促期间订单量至少都是要翻10倍以上，尤其是双十一的零点那一瞬间，并发的请求量可能是平时的百倍，针对这种业务场景，对于我们电商网站的架构提出了比较高的要求，性能上要能够支持高并发，稳定性上要求至少在99.9%，最重要的是要能够支持良好的扩展性，在每次大促之前不需要修改太多的代码，只是通过运维的部署加减机器就可以灵活的进行扩展。下面我们来介绍下如何设计web集群的架构。

之前我们介绍的架构中，webserver都是耦合的，这种高耦合的结构不适合做成集群，我们需要把webserver的架构设计成分布式的，这样才可以有比较好的扩展性，这对业务层的实现也提出了比较大的挑战，业务层的实现需要考虑怎么样进行解耦，业务模块之间可以独立开发，可以进行部署。例如，商详相关的业务逻辑作为一个独立的领域，下单相关的流程作为一个独立的领域，这样这两部分就是进行独立开发，调用方式以接口的方式进行，只要对外提供的接口不变，领域内的逻辑自己随时可以改变，相对比较灵活，并且部署的时候也可以不同领域进行独立的部署。这种方式webserver这一层就可以做成集群，当大促的时候，可以比较灵活的进行扩展。但是这里面有一些问题需要大家一起思考。

如何让访问分配在多机器上，这个时候通常会考虑的方案是Ngnix, Apache自带的负载均衡方案(mod_proxy)，或LVS这类的软件负载均衡方案；或者DNS轮询，硬件四层交换(交换机实现)等；

如何保持状态信息的同步，例如用户session等，这个时候会考虑的方案有写入数据库、写入存储(如cache)、cookie或同步session信息等机制等；

如何让上传文件这些类似的功能继续正常，这个时候通常会考虑的机制是使用共享文件系统或专用存储等。

架构演变之六：分库分表

进行了webserver的集群后，webserver这一层有着比较良好的扩展性，但是DB这一层还是单点，一台DB，如何提升DB这一层的性能？下面来给大家介绍一种常见的解决方案：分库分表。

一台DB的连接数与存储数量都是有上限的，对于中型或者大型电商应用来说势必要进行分库或者分表的选择。比如，电商的会员数据，对于稍微有些规模的电商网站来说都是在千万级甚至上亿，如果将这些数据只放在一张表里或者一个库里，那么查询和读写的性能一定会受到影响。Mysql单表的性能也是有上限的，笔者建议Mysql的单表不要超过千万级，不然查询性能会受到影响，也会遇到大量频繁读写一张表的情况，如果再有事务，这时候很可能面临锁表的问题。所以当存储数量到达一定级别，进行分库分表是比较好的选择。像上文提到的会员数据，可以按照一定的规则进行存储，比如按照用户的QQ号进行进行分库分表。每个数据库存储300万用户，每个数据库15个表，每个表20万用户淘宝网页结构是什么，后面可以随着数据量和访问量增加时，可以再分解。在数据访问层使用路由表对数据进行定位。

分库分表更多是业务上的划分，技术上涉及到的会有动态hash算法等，在实际场景中分库分表是通过框架来实现的，比如，通过增加一个通用的框架来实现分库分表的数据访问，这个在ebay的架构中对应的就是DAL（Data Access Layer），目前国内的大型或者中型电商公司也基本都有自己的这一层框架来实现。DAL涉及到比较多的复杂技术，例如数据库连接的管理（超时、异常）、数据库操作的控制（超时、异常）、分库分表规则的封装等

架构演变之七：进入大型分布式应用时代

当你的网站再上一个规模的时候，每天百万级订单，千万UV，PV上亿，就需要进入大型分布式应用的时代，也是目前大型电商所采用的架构。这时候你将面临更严峻的挑战。

l分布式应用的协作（网格计算，云计算）；

l分布式应用造成事务性实现难度几何级数增加；

l分布式应用的部署，维护，升级难度海量数据的维护甚至带宽，存储开销，电费都会成为巨大挑战。

解决的方案大家也基本殊途同归：

l一个高性能、高稳定，支持分布式事务的应用框架

l应用依赖管理、运行状况管理、错误追踪、调优、监控和报警,快速排错和硬件替换

l面向分布式应用和海量数据 MapReduce和BigTable

l采用大量的廉价机器来支撑着巨大的访问量和数据量

这里面提到的每一点都有着巨大的挑战，在京东、阿里这种级别的企业里面有成百上千人在一起协助努力解决上面的问题。这是需要团队的力量，大公司的技术总监们做的基本就是根据公司目前所处的不同阶段，为公司选取合适的架构，并不是所有的公司都需要搭建出一个大型分布式系统出来，这要根据公司当前的发展阶段来判断什么样的架构是最适合的。当一个公司处于初创阶段，每天只有几百单，这个时候技术需要做的是能够满足当前业务的性能，并且还是能够帮助业务快速的试错，那么这个阶段就不需要考虑什么分库分表，这样会增加技术实现的复杂度，势必就会对业务响应变慢。

写在最后

没有最好的架构 只有最适合的架构

--往期回顾--

回复【1】：CTO图书馆开馆 | 第一波CTO必读图书清单

回复【2】：关于技术选型 你需要知道这些。。。