架构优化方案

业务拆分

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）

消息队列

消息队列可以解决子系统/模块之间的耦合，实现异步，高可用，高性能的系统。是分布式系统的标准配置。本系统中消息队列主要应用在购物，配送环节。

1. 用户下单后，直接写入消息队列后返回客户端
2. 库存子系统：读取消息队列信息，完成减库工作
3. 配送子系统：读物消息队列信息，进行配送
   

目前使用较多的MQ有Active MQ,Rabbit MQ,Zero MQ，MS MQ等，需要根据具体的业务场景进行选择。建议可以研究下Rabbit MQ和kafka。