1.微服务演进策略
从单体应用向微服务演进策略: 绞杀者策略，修缮者策略的另起炉灶策略；
绞杀者策赂
绞杀者策略是一种逐步剥离业务能力，用微服务逐步替代原有单体应用的策略。它对单体应用进行领域建模，根据领域边界，在单体应用之外，将新功能和部分业务能力独立出来，建设独立的微服务。新微服务与单体应用之间保持松耦合关系，两者只通过服务或异步化的数据进行业务关联。随着时间的推移，大部分单体应用的功能就会被独立为微服务，这样就慢慢“绞杀”了原来的单体应用；
修缮者策路
修缮者策略是一种维持原有系统整体能力不变，通过优化局部以提升系统整体能力的策略。它是在现有系统的基础上，剥离影响整体业务的部分功能，独立为微服务；
另起炉灶策赂
另起炉灶策略，顾名思义就是将原有的系统推倒重做；
2.微服务拆分和设计原则
微服务设计原则
- 第一条，要领域驱动设计，而不是数据驱动设计，也不是界面驱动设计。
微服务设计应先建立领域模型，在确定了逻辑和物理边界，提取了领域对象，并建立了领域对象之间的依赖关系后，才开始微服务的拆分和设计。不是先定义数据模型和库表结构，也不是前端界面需要什么，就去调整核心领域逻辑代码。在设计时，应将外部需求变化从用户接口层到应用层和领域层逐级消化，尽量降低前端需求对领域层核心领域逻辑的影响； - 第二条，要边界清晰的微服务，而不是分布式小单体；
- 第三条，微服务分层要职能清晰，而不是依赖混乱的小泥球；
在服务演进时，应尽量将可复用的能力向下层沉淀； - 第四条，要做自己能掌控的微服务，而不是过度拆分的微服务；
微服务拆分原则
- 1.基于领域模型
基于领域模型，也就是按照限界上下文边界进行拆分，围绕业务领域边界按职责单一性、功能完整性进行微服务拆分； - 2.基于业务需求变化频率的不同
根据业务变更频率与相关度，将业务需求变动较高和功能相对稳定的业务进行分离； - 3.基于应用性能的要求不同
可以将对性能方面有较高要求的业务与对性能要求不高的业务进行拆分； - 4.基于组织架构和团队规模
微服务的拆分应尽量避免对团队和组织架构的调整，避免由于功能的重新划分，而增加大量且不必要的团队之间的沟通成本； - 5.基于安全边界的不同
对于有特殊安全要求的业务，应从领域模型中拆分、独立出来。避免因为不同的安全要求带来不必要的成本，或带来泄密的风险； - 6.墓于技术异构等因素
对于存在技术异构的功能，可以考虑按照技术栈的边界进行拆分； - 注意: 拆分都是以领域模型的聚合为单位拆分的。在DDD里，聚合是可以拆分为微服务的最小单位；