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

在看到图(一)这样的图,我们是否有一种探究系统的冲动?这样一个花花绿绿的界面,背后隐藏着什么样的奥秘!用户输入某个域名的时候,比如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

原文地址:https://www.cnblogs.com/chunguang/p/5892242.html