电商项目01

---

一、电商项目整体架构

按交易主体

按运营模式

按运营方向
传统电商 淘宝天猫、京东、唯品会、聚美优品、当当…
社交电商 拼多多、京东、国美、苏宁
网红电商 抖音、快手
内容电商 头条三农领域

常见术语
PV： Page view，即网站被浏览的总次数
UV： Unique Vister的缩写，独立访客
CR： ConversionRate的缩写，是指访问某一网站访客中，转化的访客占全访客的比例 （订单转化率=有效订单数/访客数）
SPU： Standard Product Unit （标准化产品单元）,SPU是商品信息聚合的最小单位，是一组可复用、易检索的标准化信息的集合，该集合描述了一个产品的特性。
SKU： Stock keeping unit(库存量单位) SKU即库存进出计量的单位（买家购买、商家进货、供应商备货、工厂生产都是依据SKU进行的），在服装、鞋类商品中使用最多最普遍。 例如纺织品中一个SKU通常表示：规格、颜色、款式。SKU是物理上不可分割的最小存货单元。

程序 = 算法 +数据结构
系统 =？+ ？（服务 + 数据存储）

二、我们的思考

容量规划、架构设计、数据库设计、缓存设计、框架选型、数据迁移 方案、性能压测、监控报警、领域模型、回滚方案、高并发、分库分表

后端架构

项目架构图、技术选型、数据库介绍
数据库开头对应：
cms 后台模块
oms 订单模块
pms 商品模块
sms 营销模块
ums 用户模块
那大家看到的是一个已经相对来说比较完整的一个分布式电商网站。那他从最初的时候是怎么样的？

三、电商发展与技术演变

最早的时候：大部分程序员做的

这种架构会产生很多问题，比如高可用问题，服务器挂掉或者访问量人多会出问题。

加入nigix分担服务器压力

一个人登录的时候在前100以内发送到A服务器，在下单的时候请求打在了B服务器，用户需要重新登录。
可以使用分布式session解决问题：

方案一：用ip进行负载均衡，使用ip进行hash，自定义规则，ip不变请求的服务器不会改变。问题：资源浪费，单点故障，（一个服务器挂了还是不能下单），服务器满了，再次请求也无法访问
方案二：基于session复制的方式实现，用户登录把数据保存在session，将两个服务器数据同步，让用户请求不同服务器都可以有session数据，TomCat通过网络通信。问题：耗内存、耗宽带。一个用户登录，要广播所有TomCat，开销非常大，以太坊 区块链的实现机制就是这样。
方案三：用户登录到服务器后再把数据存储到redis中，有没有登录在redis一查询就知道。普遍的解决方案，需要增加的额外技术（维护redis的高可用，如果redis挂掉了，也有问题）。

系统分为服务+存储，多个服务器同时请求一个数据库，会使数据库压力很大，需要优化。
用户服务器是无状态的，状态存储在redis上。

解决方案：
用的最多的：换数据库，分库分表（读写分离、对数据库本身的优化）

个人 网站：内部调用（JVM）完成 数据库项目都同一台服务
下单》登录》session 》http
应用程序优化：
数据库优化：
1、换数据库 mysql》redis 》oracle》tidb 关系型性能
读多写少（访问商品）》redis 搜索 es内存搜索（全量、增量）
2、分库分表（读写分离）
jdbc应用层：shardingsphere（shardingjdbc）、tddl
proxy代理层：mycat、mysql-proxy


jdbc应用层分片性能高一点，少了一次代理，Proxy代理分片对程序0侵入，可以使用别的语言编程，更灵活

跨部门的问题：
垂直： 会员部门、商品部门 周四（开发》测试》预演》生产）
会员部门：成功（kpi） 失败（回滚）
性能解耦、开发的问题
带来很多问题：1个N个服务，服务之间调用依赖也会增多。
rpc调用：dubbo、fegin、http
1、异步调用 2、分布式事务（数据库事务A B 两个数据库、A服务、B、C）
rocketmq、shardingsphere（mq）、异步下单 （异步、削峰、解耦）
带来一些问题：消息重复、消息丢失、消息积压、幂等性问题

拆分服务，微服务架构，垂直拆分，数据汇总

淘宝架构升级

什么是4.0 时代？

云原生：

微服务、容器化部署、DevOps
微服务：
为什么这两个系统会相互影响？
微服务的本质是把一块大饼分成若干块低耦合的小饼，比如一块小饼专门负责接收外部的数据，一块小饼专门负责响应前台的操作，小饼可以进一步拆分，比如负责接收外部数据的小饼可以继续分成多块负责接收不同类型数据的小饼，这样每个小饼出问题了，其它小饼还能正常对外提供服务。
微服务解决的是我们软件开发中一直追求的低耦合+高内聚、单一原则
DevOps：
DevOps的意思就是开发和运维不再是分开的两个团队，而是你中有我，我中有你的一个团队。我们现在开发和运维已经是一个团队了，但是运维方面的知识和经验还需要持续提高。
持续交付：
持续交付的意思就是在不影响用户使用服务的前提下频繁把新功能发布给用户使用，要做到这点非常非常难。我们现在两周一个版本，每次上线之后都会给不同的用户造成不同程度的影响。
容器化：
容器化的好处在于运维的时候不需要再关心每个服务所使用的技术栈了，每个服务都被无差别地封装在容器里，可以被无差别地管理和维护，现在比较流行的工具是docker和k8s。
所以你也可以简单地把云原生理解为：云原生 = 微服务 + DevOps + 持续交付 + 容器化

总结

电商项目的整体架构，以及不断变化改进的解决方案。