1.明确服务边界。狗就好好的啃骨头，猫就老实拿耗子。

2.服务之间单向无环依赖。分析服务之间的依赖关系，可以是代码包级别的，也可以是业务逻辑级别的，保证无环才可拆解。

3.交互方式遵循上下游关系，下游叶子节点服务可以调用上游接口（HTTP协议），上游节点服务通过事件（事件总线，消息总线）影响下游系统。

4.最小数据共享，遵循DDD的限界上下文的分析原则。

5.接口不同时操作上下文数据，写操作只能在当前上下文中，读同理。不同上下文的读取操作需要放在BFF中

 

注释：BFF， 所谓BFF其实是Backend for Frontend的简称，中文翻译是为前端而开发的后端，它主要由前端团队开发（后端微服务一般由后端团队开发）。BFF可以认为是一种适配服务，将后端的微服务进行适配（主要包括聚合裁剪和格式适配等逻辑），向无线端设备暴露友好和统一的API，方便无线设备接入访问后端服务。

 

INPUT:

    需要拆分的项目代码

TOOL&TECH:

    MCV，MVVM等通用设计架构范式    

    应用功能代码层面CDA（http://www.dependency-analyzer.org/）

    SQL语句层面使用DDD分析，每个服务只提供对应领域的表的操作入口

OUTPUT:

    项目内部应用包之间的关系结构图

INPUT:

    单元测试，组件测试，端到端测试

TOOL&TECH:

    自动化契约测试Selenium（https://www.selenium.dev/）

    接口级别组件测试，保证组件重构过程中没有改动接口输入输出结构

OUTPUT:

    红绿灯测试结果

INPUT:

    需要拆分的项目代码

TOOL&TECH:

    枚举，工具类，通用类-抽象通用jar

    调用跨越当前上下文的接口，数据，命令-通过接口调用，迁移到对应上下文服务中

    调用多个上下文的数据-确定原子能力后迁移到BFF层

OUTPUT:

    业务代码依赖拆分

INPUT:

    主库以及备库

TOOL&TECH:

    实时同步备库数据，切割时服务各自保留自己的数据表，一个用主库，一个用备库。

OUTPUT:

    完成数据库的物理拆分

 

 

参考文献：

【1】BFF架构https://segmentfault.com/a/1190000020623009

【2】微服务拆分1-必要性和时机选择https://insights.thoughtworks.cn/microservices-splitting/

【3】微服务拆分2-原则和实践过程https://insights.thoughtworks.cn/microservices-splitting/