微服务-单块系统的分解

系统转向微服务之前，我们后台是一个巨大的单块服务，其中包括了在线金融销售所需要的所有行为。一开始我们按业务系统进行上下文划分。

• 会员中心
  　 系统登录认证（客户、理财师）、积分的元数据。

• 订单系统
  客户订单、处理第三方商户订单(基金、第三方金融平台)、 处理退单、订单链路跟踪的数据。

• 商品模块
  正在销售与正准备销售商品的相关元数据。

• 支付中心
  第三方支付管理（与多家支付公司对接）、支付路由（根据手续费与支付额度）、支付日志处理、同步基金和第三方金融平台支付数据与核算等。

• 活动中心
  活动上下架、产品活动限定、新手活动推荐算法等。

首先创建相关业务包结构来表示这些上下文，然后把相关的代码移动到相应的位置。因为同步开发与人员问题 ，我们新功能就在新创建的包上进行，在这个过程中，我们会先把代码相关的包依赖引入，共用的提取到共用的comm模块然后引入；所以相关的业务都会与之交互。

在这个过程中业务依赖分解是相当需要时间的，我们一个会员与支付中心因为前期迭代开发赶进度等原因耦合很严重，分解起来相当费时团体花了将近二个多月才分离完成，测试同学花了半个月时间的黑+白盒测试才算有一个阶段性成果，这个过程是新的业务在工发，旧的业务在分割，慢慢的往上面移，因为线上金融平台天天在销售，所以过程也不是一次性完，是团体一天天、一点点的进行的有。

分解原因

• 团体
  我们团体后台差不多每一个都负责一个主要业务点并对应不同的终端进行同步开发，在一个单系统的情况，代码冲突、包依赖混乱、小白短路、老黑脑抽等一些原因，不同的模块提交或从分支合并后，经常性服务跑不起来，团体成员就开始加班加点找问题修复，测试验证、产品验证整人团体经过几次都崩溃了。一到后来听到技术团体说发布版本至预生产环境，测试与产品部六脸都白的。

• 安全
  因为是金融系统，很多敏感数据都做严密的保护与隔离。分离后这部分就交由相关的核心负责，并对这个服务做了监控、网络传输、数据域的保护。

• 开发速度
  按业务分解后，相负依赖与影响提升到服务层次，再也不会因为脑抽而引起服务问题，团体后期的开发速度大的加快了。

• 关键的--数据库
  单系统的情况下，我们数据库是集成一个的，无法做多数据安全的隔离（总有人喜欢直接操作数据库，防不胜防。。），分解后我们把相关的业务数据干净的分离出去。

• 业务梳理
  频繁的迭代（2个星期一版）与新增团体成员的磨合使得业务代码层次混乱，有时候找一个订单相关的BUG，居然会找到产品模块去等各种问题都暴露出来。