1.业务拆分方法:根据业务属性进行垂直切分,划分为产品子系统,购物子系统,支付子系统,评论子系统,客服子系统,接口子系统等
产品子系统(核心)
线路
保险
签证
酒店
景区
供应商子系统(核心)
专门负责供应商对接
供应商合同签署
下单子系统(核心)
门店下单
官网下单
其他下单
支付子系统(核心)
负责所有的支付流程
评论子系统(非核心)
订单评论
导游评论
内部考核评价
接口子系统(非核心)
电子合同接口
江泰保险接口
客服子系统(非核心)
2.业务拆分作用
提升为子系统可以由专门的团队和部门负责,解决模块之间的耦合以及扩展性问题
每个子系统单独部署,避免集中部署导致一个应用挂了,全部应用不可用的问题
3.等级定义作用
在流量大的时候,对关键应用进行保护,实现优雅降级或者服务熔断,保护关键应用不受影响。
双十一的时候,淘宝的选择收货地址模块直接崩了,但是不会影响正常下单,这就是经典的拆分和服务熔断实现
• 每个应用单独部署
• 核心系统和非核心系统组合部署
分布式部署:将业务拆分之后的应用单独部署,应用直接通过RPC进行远程通信
集群部署:电商网站的高可用要求,每个应用至少部署两台服务器进行集群部署
负载均衡:是 高可用系统必须的,一般应用通过负载均衡实现高可用,分布式系统通过内置的负载均衡实现高可用,关系型数据库通过主备方式实现高可用。
前端对于不同模块的请求应该分发到不同的负载均衡器上,这个应该是预先设置好的,如果为了统一期间,应该使用一个统一的后台接口,作为负载均衡器的分发器,但是单个集中网关会造成性能瓶颈。
缓存按照存放的位置分为本地缓存和分布式缓存。
一般设计为二级缓存
一级缓存为本地缓存
二级缓存为分布式缓存
一级缓存: 缓存数据字典,和常用热点数据等基本不可变/有规则变化的信息,
二级缓存: 缓存需要的所有缓存。当一级缓存过期或不可用时,访问二级缓存的数据。如果二级缓存也没有,则访问数据库。
根据业务特性可使用以下缓存过期策略:缓存自动过期;缓存触发过期;
系统分割为多个子系统,独立部署后,会遇到会话管理问题,一般可以采用Session同步,Cookie,分布式Session方式。电商一般使用的是分布式Session。
流程说明
1.用户第一次登录的时候,将会话信息写入分布式Session
2.用户再次登录的时候,获取分布式Session,是否有会话信息,如果没有就跳转到登陆页面
3.一般采用Cache中间件,建议使用Redis,因为有持久化功能,方便分布式Session宕机后,可以从持久化存储中加载会话信息。(Redis一般使用的是主从的模式,主和从之间通过写入日志来同步,主服务器宕机,从会通过选举机制来选出新Master)
4.存入会话时,可以设置会话保持的时间,比如15分钟,超过后自动超时。
为了存储海量数据,高可用和高性能一般采用冗余的方式进行系统设计。
一般有两种方式:
1.读写分离:适用于读大于写比例的场景,可采用一主一备,一主多备或者多主多备
2.分库分表
业务拆分后,每个子系统需要单独的库
单独库太大的话,可以再次细化,为商品分类库产品库等
分库之后要分表,垂直划分或者水平划分,可以按照id时间等水平切割,高级用法是采用一致性hash算法。
在分库分表的基础上进行读写分离
将多个子系统公用的功能/模块,进行抽取,作为公用服务使用。比如本案例的会员子系统就可以抽取为公用的服务。
所谓将系统分开,也就是Controller分开,不同的Controller形成一个子系统,专门处理相关的业务,Service可以做成微服务,尤其是公共的服务(这就要用到dubbo)
消息队列可以解决子系统/模块之间的耦合,实现异步,高可用,高性能的系统。是分布式系统的标准配置。本系统中消息队列主要应用在购物,配送环节。
目前使用较多的MQ有Active MQ,Rabbit MQ,Zero MQ,MS MQ等,需要根据具体的业务场景进行选择。建议可以研究下Rabbit MQ和kafka。