上一篇讲了如何搭建一个中型的电商网站以及背后的架构是什么样的，今天我们一起来聊下大型电商网站的架构是什么样子的。
架构演变之五：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采用大量的廉价机器来支撑着巨大的访问量和数据量
这里面提到的每一点都有着巨大的挑战，在京东、阿里这种级别的企业里面有成百上千人在一起协助努力解决上面的问题。这是需要团队的力量，大公司的技术总监们做的基本就是根据公司目前所处的不同阶段，为公司选取合适的架构，并不是所有的公司都需要搭建出一个大型分布式系统出来，这要根据公司当前的发展阶段来判断什么样的架构是最适合的。当一个公司处于初创阶段，每天只有几百单，这个时候技术需要做的是能够满足当前业务的性能，并且还是能够帮助业务快速的试错，那么这个阶段就不需要考虑什么分库分表，这样会增加技术实现的复杂度，势必就会对业务响应变慢。
写在最后，没有最好的架构，只有最适合的架构！
