电商的架构和痛点

网站应用架构 : PC、App、H5,表现层、业务逻辑层和数据访问层等

业务扩展后,业务、代码、数据、并发多了后,如果技术能力支持不到业务体量的增长,支持不了那么高的并发量的话,网站很容易就挂了

按业务扩展

表现层,详情页、搜索页、团购区分,域名分开

业务多了之后,普通购物、团购、虚拟业务等剥离开来

数据库层,产品、用户、订单及其他一些业务数据等都进行分拆,主要是从物理上隔离开来

总体架构本身变化不大,只是简单的切分一下

产品、用户、订单等这个层面的划分要有一定的规则和边界

演进之路

小网站变成大网站是一个架构演进的过程

乡村老师,一二三年级都在同一个教室,先给一年级讲课,二三年级复习做功课,再给二年级的讲课,一三年级复习做功课,在前期还能忙过来

但到了一定的时候,学生开始多了,教室坐不下了

当业务也多了,不光教语文、数学,还要教体育、音乐、美术,这时学校的规模大了,相关的配套设施就要跟着上去

要有校长、主任、班主任、音乐英语老师…有后勤的,甚至是保洁阿姨,甚至还有食堂了,和大学一样了

可以类比架构变化

  • 业务变化,相当于课程的变化

  • 架构变化,相当于学校的规模大了之后,相关的配套设施都要跟上

人员扩大,就是开发维护人员多了,不可能还像以前那样,几百号人在那里弄一个工程,必须要进行分割剥离


敏捷,两个星期做一个迭代,以前是一个项目做好几个月,分成N个两个星期的,在两个星期的迭代当中,该做的还是逃不了,还是要做需求分析,设计,开发,测试,上线。过程没有变,只是说把任务给拆分小了

准备工作

架构层面的规划

  • Service化(业务逻辑层的拆分-SOA服务化)
  • 水平拆库

工作思路

拆分:垂直/水平、解耦、异步、读写分离

拆分后,理论上具有无限的扩展能力,比如说订单库,可以把它按照一定的维度,去拆成很多的订单库

拆分和解耦是分不开的,一方面是代码和业务的解耦,另一方面对人员和工作来说也是一种解耦

同样还要做一些异步工作,以前业务特别重,下单流程非常长,操作步骤非常多,但是很多东西并不是用户都要马上关注的

比如下单送积分,可以稍微延迟几秒甚至是几分钟,它不应该影响下单业务。但是如果因为积分出现问题,导致下单出现问题那就是本末倒置了。因此异步,它挂了,可以做补偿

不能做异步的,比如积分兑换商品的订单,下单时要去扣积分,因为积分就是钱,还有礼品卡支付

用积分可以充话费,结果话费充成功了,积分没扣,就变成了可以无限的充。互联网时代,信息散布的很快,据说一两个小时就是几个亿的损失

读写分离,为保证下单的流畅,在不同的库里进行读和写,可以很大地减轻下单压力

service 规划

电商核心要素 产品,用户&支付,订单 三大块

产品、价格服务相对较简单,主要是查;但订单,库存放到订单这个层面来,而不是放到产品上,是因为库存和订单是息息相关的,生成订单的时候要扣库存的,库存不足的话,订单是无法完成的

订单读写得区分:写,生成订单。读,订单写了之后,用户要来读、后端的客服商家也在读

读不是简单的仅仅读订单表,还有很多其他的关联表。比如说抽奖有抽奖系统有自己的很多表,抽完奖给用户发一个奖品,就生成一个订单,但抽奖系统要知道哪一个用户是通过什么样的方式获得这个订单、订单里有什么东西,必然要关联查询。所以订单查询是非常复杂的,有无数的点可以查,而且这个查询一定是有无数张表可以关联查的,甚至是跨表、跨库的

Service化一定要有一个边界。抽奖的信息我关不关心呢?关心,抽奖业务就纳入进来了,这就是一个边界,所以只关心我的订单,这就是订单的边界

Service既要很短,又要很长

订单的生成,有很多的业务,要给客户积分,生成订单表数据,抵用券扣掉,还有相关的支付信息,这些业务是不能剥离开来,必须要融合在一起,这当中要包含所有的能想到的业务场景,因此在订单生成业务上,要做到足够长,把所有的业务都包含进来,有一些是需要同步的,有一些是需要异步的,但是无论是同步还是异步的,都要纳入进来

但查询,业务是可以分开的,商品详情页,可能先是调商品的基本信息Service,然后再去调价格信息Service,然后再调用库存服务Service,生成一个页面需要很多的服务,这些服务可以是各自独立的,所以在查询Service上,可以做的很短。价格、库存等都可以做成独立的业务Service单元

独立并不一定是最简单,也要有自己完整的业务逻辑。比如库存并不是简单地看库存表里的数字是大于0还是小于0的问题,某一个地方销售不销售,或者说尽管有库存,现在是不卖它的,这些都是库存,库存不是一个简单的数字,如果说这个商品暂时不卖,就显示说无库存,但是我的仓库里是有实物库存的

service 不是拆的越多越好,服务调用七八次,网络交互也七八次,单个service性能再好也没用,长和短的粒度要划分好,关键词 边界和粒度

订单水平拆库

oracle再厉害,不可能放几百亿,几千亿的数据

mysql水平拆分,单点故障概率小点,扩展能力强

水平拆分影响因素

  • 用户
  • 存储
  • 数据增量
  • 读&写
  • 事务一致性
  • 缓存
  • 热点数据

  • 用户

前端用户、商家、客服

  • 储量

订单几何级增长,但商品和库存有一定范围,大超市SKU几万,小门店几百,不会无限扩展

  • 数据增量

超市 SKU几万,电商平台百万或千万级,不是无限增长,取决商家体量

  • 读写

商品、价格 读高 改价格,商品信息几率低

  • 事务一致性

订单和库存要一致性、商品信息写较少,事务一致性稍弱

  • 缓存

库存,前端显示有,下单时没有,因下单是实时库存

商品和价格,缓存可长些,减少压力

中间件

SOA、DB、CACHE、MQ、JOB、分布式配置

日志,监控,灰度发布

Service化和水平拆库的同时,进行的技术架构拆分,需要中间件配套跟进

学校没有保安,要上体育课没有操场是不行的,没有相应的中间件没有是不行的