如何进行有效的系统拆分？

条件：用户数是否大  交易数是否大  系统性能是否遇到瓶颈 
对于目前来说大而全的系统已经是存在各种问题了。
比如用户数和交易数的剧增，会带来多线程和高并发的业务问题甚至代码问题。
再比如：系统性能在面对小用户数并发时依然低下的问题。

因此我们就需要对我们的架构或者业务进行拆分。
拆分是立马着手的吗？no,不是的。这需要我们在一些中小型企业或者一些更复杂的一些大平台比如像银行的一些系统
中需要有一个循序渐进的处理方式。
那么怎么做系统拆分前的准备工作呢？
1. 指定维度划分
   A. 应用系统维度  最顶层的应用架构设计和拆分  
   将一个电商拆分：
   SSO系统 权限系统 买家系统 卖家系统 商品系统 价格系统 购物车系统 促销系统  订单系统 
   库存系统  支付系统 发票系统 店铺系统 分账系统 合同系统
   评价系统  采购系统  物流系统  售后系统  采购系统  财务系统等等
   
   B. 业务功能维度  
   a.将一个优惠券系统拆分：
   后台制券系统 发券系统 领券系统 用券系统 核券-失效系统
   
   b.将一个商品系统拆分：
   商品详情系统  CDN渲染详情页系统等
   
   C. IO流向维度
   读大于写：商品读服务(缓存) 商品写服务(mycat分库分表) 
   聚合读取：抽取聚合进行异构存储

   D. 日志审计维度
   将通用日志拆分：用户操作日志 终端操作日志 资源操作日志 违规接入日志 等等   
   
   E. 模块层级维度 
   按照层级划分：数据库分库分表 数据库连接池管理 DAO层 dubbo接口软负载服务
   Service层：业务服务  web层：控制层服务
   
2. 根据指定的维度-梳理业务闭环-成立预演推进
    A. 梳理需要拆分系统的业务闭环
    B. 根据业务闭环拆分出核心业务和非核心业务
    C. 根据核心业务进行并拢，非核心业务进行边缘化站角
    D. 专项成立预演推进小组 m组预演推进  n组进行原业务处理。
3. 开始出方案：
    保证当前问题 有方案
    系统拆分     有预案

笔者日前在一家公司担任架构师岗位，进入公司发现公司的优惠券系统
很杂乱无章，还好公司的用户数规模很小。
因此在极短的时间内对其做了系统拆分。

原优惠券系统：系统优惠券用户优惠券订单优惠券 制券 发券 领券 使用 核销 失效的业务都在一个服务中。
在维护和成本上比较复杂。

因此笔者开始着手进行处理，好在后面的业务推进只是用到了订单优惠券
因此笔者开启了拆分：原先类型的划分 不作处理。不采用横向拆分。
将优惠券划分为：(由于用户数小，未进行系统拆分，只是做了现有系统和优惠券系统的分离 +接口服务拆分)
A. 将优惠券系统拆分出去
B. 将优惠券系统的核心接口服务抽取封装如下：
    制券服务 -提供统一的接口对外服务
    发券服务 -提供统一的接口对外服务
    领券服务 -提供统一的接口对外服务
    用券服务 -提供统一的接口对外服务 
    核券服务 -提供统一的接口对外服务
C. 后续开发预演推进在新的优惠券系统上进行。
D. 删除原有的优惠券服务相关代码和业务逻辑。
E. 配置中心添加更改响应的地址。