电商系统架构——系统鸟瞰图

在看到图（一）这样的图，我们是否有一种探究系统的冲动？这样一个花花绿绿的界面，背后隐藏着什么样的奥秘！用户输入某个域名的时候，比如www.taobao.com的时候，页面是如何展示的，用户在搜索框搜宝贝的时候，系统又是如何处理的，用户在参加秒杀活动的时候，系统又是如何处理的。经过两年多的互联网从业经验，以及自己的思考，在这里我就抛砖引玉对电商系统架构进行探究，探究系统是如何设计的，以及设计这个系统的各种权衡。

             

                                                                                                 图（一）

           隐藏在花花绿绿的界面之后，是一个庞大复杂的系统，图（二）是这个系统的鸟瞰图。我只描绘了一些枝干子系统，省略掉其他辅助子系统。

          

          在这个复杂的系统中，各个子系统是如何工作的？

         1：User 是如何访问到类似www.taobao.com 的页面呢？User 在浏览器输入www.taobao.com 的域名，浏览器通过DNS服务器解析该域名指向的IP地址。IP地址可能不只一个，有可能是多个。那该选择哪一个，一般由DNS基于一定的策略返回。

         2：假如浏览器选择了一个IP地址，那么通过该IP地址访问到了页面服务器，即WebServer。从可靠性、性能来讲，WebServer 不只部署一台机器，而是多台。这样部署既要负载均衡，又要在某个子节点崩溃后，能够正常服务。我们的做法可以采用额外的负载均衡器方法，也可以通过LVS来实现。

        3：WebServer 加载页面详情的时候，通过详情系统来加载。详细系统通过聚合多个子系统的信息：商品子系统、图片子系统（CDN）、活动子系统。

        4：用户登录账号的时候，是通过用户账号子系统，该子系统要支持统一账号模式：通过邮箱登录、QQ账号登录、微信账号登录。

        5：用户在搜索框输入宝贝名称的时候，搜索请求是通过搜索子系统来完成的。搜索子系统定时从备DB增量建索引，这种方式容忍搜索有一定的延迟。

       其实也可以采用一些实时搜索系统，比如solr，或者采用大系统聚合小系统的方式，新增数据通过消息队列的方式进入搜索系统的内存中，或者实时系统中，然后在用户搜索的时候采用聚合的方式返回结果。

6：用户购买商品的时候，先将物品加入购物车，这需要购物车系统，购物系统要访问库存系统，判断当前是否有货，如果有货才允许用户添加到购物车，并计算总价钱。添加购物车的时候，是否允许用户减库存，取决于用户体验和恶意用户之间的矛盾：如果不允许减库存，则有时用户要下单的时候，会出现没货。如果允许减库存，则存在恶意用户占着库存，影响其他用户购买。

7：库存系统记录了商品的价格、库存等轻量信息，为了性能的考虑，个人觉得库存子系统是采用内存的方式，其数据来源商品系统（或者直接访问数据库）。

8：订单系统：在活动期间，订单系统会遇到峰值，所以订单系统宜采用异步方式。

9：商品系统：吐商品信息的系统。

10：DB采用主备方式，现在常见的模式：写主、查备。这种模式有主备数据一致性问题。备数据的实时性取决于同步，比较简单的方式，采用数据库本身的备份功能；或者在商品系统中通过异步写。那写主查备是基于什么考虑的呢？只要是读写分离，提高性能。

11：跨区域容灾，采用异步的方式，这种影响性能比较小，但是数据一致性不敢保障。这里只能具体业务采取不同的策略，对一致性要求高的子系统，则采用异地同时双写。

12：子系统基于SOA的方式进行交付，现在一般采用某个RPC框架。个人觉得开源的ICE是不错的选择。

13：各个子系统，在本区域内采用主备模式。底层数据都挂了，则在底层系统跨地区访问数据。所以需要一个跨区域的数据访问代理，同时降级提供业务。

        或者将访问切向另外的一个区域，这里要考虑另外一个区域的负载情况。

  这里，概略地介绍了电商系统的架构原理，接着后继将对各个子系统的设计进行探讨！

 

http://blog.csdn.net/antisoul/article/details/42783489