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