架构优化方案
文章目录
- 业务拆分
- 应用集群部署（分布式，集群，负载均衡）
- 多级缓存
- 单点登录（分布式Session）
- 数据库集群（读写分离，分库分表）
- 服务化
- 消息队列
业务拆分
1.业务拆分方法：根据业务属性进行垂直切分，划分为产品子系统，购物子系统，支付子系统，评论子系统，客服子系统，接口子系统等
产品子系统（核心）
线路
保险
签证
酒店
景区
供应商子系统（核心）
专门负责供应商对接
供应商合同签署
下单子系统（核心）
门店下单
官网下单
其他下单
支付子系统（核心）
负责所有的支付流程
评论子系统（非核心）
订单评论
导游评论
内部考核评价
接口子系统（非核心）
电子合同接口
江泰保险接口
客服子系统（非核心）
2.业务拆分作用
提升为子系统可以由专门的团队和部门负责，解决模块之间的耦合以及扩展性问题
每个子系统单独部署，避免集中部署导致一个应用挂了，全部应用不可用的问题
3.等级定义作用
在流量大的时候，对关键应用进行保护，实现优雅降级或者服务熔断，保护关键应用不受影响。
双十一的时候，淘宝的选择收货地址模块直接崩了，但是不会影响正常下单，这就是经典的拆分和服务熔断实现
• 每个应用单独部署
• 核心系统和非核心系统组合部署
应用集群部署（分布式，集群，负载均衡）
分布式部署：将业务拆分之后的应用单独部署，应用直接通过RPC进行远程通信
集群部署：电商网站的高可用要求，每个应用至少部署两台服务器进行集群部署
负载均衡：是 高可用系统必须的，一般应用通过负载均衡实现高可用，分布式系统通过内置的负载均衡实现高可用，关系型数据库通过主备方式实现高可用。
前端对于不同模块的请求应该分发到不同的负载均衡器上，这个应该是预先设置好的，如果为了统一期间，应该使用一个统一的后台接口，作为负载均衡器的分发器，但是单个集中网关会造成性能瓶颈。
多级缓存
缓存按照存放的位置分为本地缓存和分布式缓存。
一般设计为二级缓存
一级缓存为本地缓存
二级缓存为分布式缓存
一级缓存： 缓存数据字典，和常用热点数据等基本不可变/有规则变化的信息，
二级缓存： 缓存需要的所有缓存。当一级缓存过期或不可用时，访问二级缓存的数据。如果二级缓存也没有，则访问数据库。
根据业务特性可使用以下缓存过期策略：缓存自动过期；缓存触发过期；
单点登录（分布式Session）
系统分割为多个子系统，独立部署后，会遇到会话管理问题，一般可以采用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。