从电商系统出发，设计一个最简单的后端系统 一

电商系统设计

需求分析

对于最简单的电商系统的需求分析，主要需要考虑两件事。
第一是系统面向的客户，第二是这些用户需要这个系统做什么。

顾客

系统首先是给顾户使用的。参照我们在淘宝网站中最常做的事，我们可以得出这个系统需要给我们提供的功能。
在网站中挑选商品，然后将想要的商品丢进购物车中，点击购买，生成一个订单，支付订单，等待购买的商品送到自己手中。
.有一天，突然发现自己钱包不够了，才发现自己已经买了太多不需要的东西。默默地来到了订单的页面，查看以前的订单还有自己最近花的钱，并决定自己以后再也不会购买某些不需要的商品了。

商家

另外，提供给顾客商品的是那些商家，所以系统也要能给商家使用。
商家应该可以用这个系统上架物品，给物品定价，管理物品的库存，若库存为0则下架商品等。

老板

最后，我们电商网站还需要能够给老板使用。
老板能利用能够统计顾客和商家的一些信息,比如统计最近几天的流水，统计有多少用户，多少商家，哪些商家有潜力等，从而来针对性的制定策略。

需要的子系统

综合之后来看，我们电商系统应该有如下子系统
商品子系统
购物车子系统
订单子系统
用户信息子系统
支付子系统
商家子系统
库存子系统
网站信息统计子系统

概要设计

电商系统的实体关系图

并没有严格遵守数据库的三范式

这是一个最简单的电商系统图。（ps 只是表意，并没有按照ER图的规范）
每个商户都有其对应的库存，能将库存中的商品上架供顾客浏览。每个商户都有修改其库存的权限。当库存中商品变为0时则将商品下架。
每个顾客都有其对应的购物车，浏览上架商品时可以将想要的商品加入购物车内，以便一起支付买下商品。当想要购买购物车内的商品时，则会生成一笔订单，订单有待支付，已支付，待发货，待收货，已收获多种状态，会随着业务流程不断改变。

数据库设计

知道了一些已有的实体之后，我们可以来设计数据库。
数据库设计的原则为
1.每个数据实体设计实体表
2.一对多的关系用来构建外键约束
3.多对多的关系用来构建关系表
先来设计商户表
商户表只包括基本的商户信息
商户ID为主键

库存表
库存表包括库存基本信息和库存所属商家
库存ID为主键，库存所属商家为外键

购物车表
购物车表包括购物车基本信息，购物车所属顾客等

订单表
订单表包括订单基本信息，订单状态，订单所属客户，订单包含的商品ID等

上架商品表
上架商品表包括已经上架的商品ID，商品上架时间，外键为商品所属仓库和商品所属商家

这是一个最简单的设计，实际的电商系统远比这要复杂的多，待用户量不断增加之后可能还要进行分库分表的操作。
这里简单说一下分表。
分表的操作一般分为水平分表，垂直分表。
水平分表：假设你的数据库中已经有1000000条数据了，这个时候查询已经变得比较慢了，水平分表就是将这1000000条数据拆分在几个数据表中，之后在每个数据表中找数据就变得简单了。
垂直分表：举个例子，假如一个数据表的属性字段特别多，我们就可以将这个表的属性分为常用的属性和不常用的属性，常用的属性放到一个表中，不常用的属性放到另一个表中，这样就完成了垂直分表。
关于分库和分表的学问其实很多，由于本篇文章重点讲简单电商系统的设计，故再过多叙述。

每个子系统的具体功能

做好了数据库之后，我们可以设计我们的子系统功能了。
首先是商品子系统：
1.我们用户登录网站之后需要能够看到上架商品的信息
2.可以将用户选中的商品放进购物车子系统中
3.用户购买商品之后对应的商品库存要减少，当库存减少为0之后将商品下架

购物车子系统
1.维护用户选中的商品信息
2.将购物车中的商品信息生成订单

订单子系统
1.维护生成的订单的状态
（初始订单状态为待支付，用户支付后订单状态变为已经支付，商家发货之后订单变为已发货，到货之后订单状态变为已收货）
2.管理生成的所有订单

用户信息子系统
1.用户信息管理子系统用来维护并展示用户所需的信息

支付子系统
1.支付子系统用于与用户的支付账户连接，并将用户账户的金额转移到商家之中，期间还有平台的抽成要计算

商家子系统
1.商家子系统用来保存商家的信息，如商家的账号，基本信息等，还用来维护商家最近的流水，商家的库存，商品等信息

库存子系统
库存子系统用来维护各个商家的库存信息，并实时监控库存数是否为0，若为0则要将对应的上架商品下架

网站信息统计子系统
网站信息统计子系统统计平台所有的订单信息，商户信息，顾客信息。并从此做一些数据分析的工作从而更好得指定策略

最终系统结构图

最终的系统架构为从客户端发出请求，在电商网站中经过一系列的业务处理以及和数据库中的数据交互，就形成了最初的系统架构

一个购物场景下子系统的相互协作关系

举个例子来说明电商网站系统内部的业务流程
1.用户购买商品并下单，支付，商家发货，到货

请求A为用户请求商家商品的信息，响应A为返回上架商品的信息
请求B为将商品加入购物车中，响应B为成功添加购物车的响应
请求C，D为将购物车中的商家加入订单，检查库存并锁定库存
请求E为支付，支付成功后返回响应，并将订单状态更改
请求F为提醒商家发货，商家发货后则向订单子系统发出请求，将订单状态修改为已发货（ps 图中应有一个商家向订单子系统发的请求）
请求G为订单子系统要求顾客子系统向该订单顾客发送短信通知，顾客子系统接收到请求之后则处理请求并返回响应
在这些过程中可能会用到异步和消息队列相结合的技术手段，后续的博客再记录

另外一些场景还有
2.商家有一批货卖完了，并且商家增加了新货
3.网站老板想要查看网站最近的流水及收益和卖货收益最大的商家
与场景1类似,都是子系统相互协作的结果，不再展开叙述。

结尾

由于电商系统十分复杂，本文章节有限，可能不能叙述清楚，但是本篇博客的主要目的是为了之后探讨后端系统用到的各种技术，所以一个简单电商系统的设计就到这儿了。
（ps 若是后续有时间会再次完善本次设计）