微服务模块划分原则和接口定义原则

微服务模块划分原则:

原则1:传统的一个大业务系统划分微服务模块的时候,尽量是划分到6到8个模块比较合适,当你本身的IT成熟度达到一定水平后你可以划分的更加细点。同时在微服务模块划分的时候一定要考虑数据库本身的划分,即底层的数据库也是划分开的。

原则2:要分析单个业务系统内部的流程,然后分解到具体的业务组件或功能,再按照高内聚的原则进行聚合,尽量确保各个微服务模块之间的交互最少。同时对于大家都要用到的基础数据模块,仍然采用共性下沉的策略和思路进行。

微服务接口定义原则(服务发现)

原则1:接口一定要保证粗粒度特性,实现业务规则和逻辑的高度内聚。接口面对的应该是核心的业务对象,领域对象或业务规则能力暴露,而不是微服务模块内部的数据库表的CRUD操作的暴露。如果将数据库表CRUD操作暴露为Rest API接口并在微服务模块间相互调用。一个是耦合性增加,一个是完全没有实现高内聚的基本要求。

 

posted @   Mr.peter  阅读(2565)  评论(0编辑  收藏  举报
编辑推荐:
· 开发者必知的日志记录最佳实践
· SQL Server 2025 AI相关能力初探
· Linux系列:如何用 C#调用 C方法造成内存泄露
· AI与.NET技术实操系列(二):开始使用ML.NET
· 记一次.NET内存居高不下排查解决与启示
阅读排行:
· Manus重磅发布:全球首款通用AI代理技术深度解析与实战指南
· 被坑几百块钱后,我竟然真的恢复了删除的微信聊天记录!
· 没有Manus邀请码?试试免邀请码的MGX或者开源的OpenManus吧
· 园子的第一款AI主题卫衣上架——"HELLO! HOW CAN I ASSIST YOU TODAY
· 【自荐】一款简洁、开源的在线白板工具 Drawnix
点击右上角即可分享
微信分享提示