微服务拆分原则以及实践
2021-09-14 21:16
483 查看
拆分原则
1.明确服务边界。狗就好好的啃骨头,猫就老实拿耗子。 2.服务之间单向无环依赖。分析服务之间的依赖关系,可以是代码包级别的,也可以是业务逻辑级别的,保证无环才可拆解。 3.交互方式遵循上下游关系,下游叶子节点服务可以调用上游接口(HTTP协议),上游节点服务通过事件(事件总线,消息总线)影响下游系统。 4.最小数据共享,遵循DDD的限界上下文的分析原则。 5.接口不同时操作上下文数据,写操作只能在当前上下文中,读同理。不同上下文的读取操作需要放在BFF中 注释:BFF, 所谓BFF其实是Backend for Frontend的简称,中文翻译是为前端而开发的后端,它主要由前端团队开发(后端微服务一般由后端团队开发)。BFF可以认为是一种适配服务,将后端的微服务进行适配(主要包括聚合裁剪和格式适配等逻辑),向无线端设备暴露友好和统一的API,方便无线设备接入访问后端服务。实施步骤(ITTO)
1.调整代码结构,分析模块间依赖
INPUT: 需要拆分的项目代码 TOOL&TECH: MCV,MVVM等通用设计架构范式 应用功能代码层面CDA(http://www.dependency-analyzer.org/) SQL语句层面使用DDD分析,每个服务只提供对应领域的表的操作入口 OUTPUT: 项目内部应用包之间的关系结构图2.架构重构,测试保护
INPUT: 单元测试,组件测试,端到端测试 TOOL&TECH: 自动化契约测试Selenium(https://www.selenium.dev/) 接口级别组件测试,保证组件重构过程中没有改动接口输入输出结构 OUTPUT: 红绿灯测试结果3.消除业务代码依赖
INPUT: 需要拆分的项目代码 TOOL&TECH: 枚举,工具类,通用类-抽象通用jar 调用跨越当前上下文的接口,数据,命令-通过接口调用,迁移到对应上下文服务中 调用多个上下文的数据-确定原子能力后迁移到BFF层 OUTPUT: 业务代码依赖拆分4.数据库拆分
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/相关文章推荐
- 微服务实战(四):服务发现的可行方案以及实践案例
- Spring Cloud与微服务构建学习笔记之微服务和SOA的关系以及微服务设计原则(三)
- redis服务启动关闭以及其他命令实践
- 后端服务部署拆分原则
- 微观SOA:服务设计原则及其实践方式
- 微服务架构的4大设计原则和一个平台实践
- 后台服务部署拆分原则 后台服务优化原则
- 微服务实战(四):服务发现的可行方案以及实践案例
- 微服务实战(四):服务发现的可行方案以及实践案例
- 微服务实战(四):服务发现的可行方案以及实践案例
- 云原生架构下微服务最佳实践-如何拆分微服务架构
- [转载]微服务实战(四):服务发现的可行方案以及实践案例
- 微服务实战(四):服务发现的可行方案以及实践案例
- 微服务实战(四):服务发现的可行方案以及实践案例
- 微服务实战(四):服务发现的可行方案以及实践案例
- 微服务拆分需要考虑的必要因素与坚持原则
- 微观SOA:服务设计原则及其实践方式(下篇)
- 微观SOA:服务设计原则及其实践方式(上篇)
- 服务发现的可行方案以及实践案例
- 转 -什么是SOA-微观SOA:服务设计原则及其实践方式