微服务设计拆分原则
微服务设计拆分原则
一、微服务拆分原则:
- 以业务模型切入,比如:订单管理、商品管理等。
- 单一职责、高内聚:单个微服务的职责尽量单一。但是粒度要适中,不能过度拆分,过度拆分是微服务架构的灾难!
- 充分考虑团队结构:微服务的拆分要充分的考虑团队的结构,与微服务开发运维之间的关系。
- 演进式拆分:如果各方面资源不允许,可以考虑演进式拆分。
- 避免环形依赖与双向依赖:避免微服务之间的环形依赖或者双向依赖。
二、dongbb单体应用项目介绍
在我们开始新建微服务项目dongbb-cloud之前,先给大家介绍我的另外一个项目:dongbb。该项目提供了一个前后端分离的RBAC权限管理系统,其中后端服务server-jwt是一个单体应用。
所以,server-jwt中主要包含两部分服务(截止2020年3月29日)。
- 第一部分:JWT令牌服务(登录及接口鉴权)及过滤器。为了方便集成与复用,已经拆分成zimug-jwt-spring-boot-starter模块。
- 第二部分:RBAC权限管理的接口服务,角色管理、菜单管理、用户管理等服务。
关于这个项目的更多介绍可以参考:DongBB项目文档,项目文档部分的内容是免费的。dongbb项目源码地址:https://gitee.com/hanxt/dongbb
三、dong-cloud(1.0)服务拆分规则
dong-cloud是基于dongbb单体项目的基础上进行服务架构拆分的、基于Spring Cloud的微服务项目脚手架。将dongbb的server-jwt单体应用拆分为微服务。
- 第一个服务是service-rbac,用作于:接口服务,角色管理、菜单管理、用户管理等服务。统称系统管理微服务。
- 第二个服务是service-oauth,使用Spring Cloud OAuth替换掉单体应用中我们自己实现的JWT认证服务。(这部分我们后续章节结合Spring Cloud Gateway讲解)
- 第三个服务是service-sms。用于发送短信、邮件等的微服务,是新增的服务。
四、微服务调用场景
为了方便讲解微服务调用关系,我们来设定一个微服务调用需求的场景,方便我们后面课程内容的讲解。
- service-rbac新增用户成功之后,通过service-sms接口向用户发送一条短信
- service-rbac新增角色成功之后,通过service-sms接口向管理员发送一条短信
- 等等
在我们后面的章节中大家可以尝试去理解一个概念
- service-rbac是服务的消费者
- service-sms服务的的提供者
在实际的工程项目中,一个微服务可能既是服务消费者,又是服务的提供者。
【推荐】编程新体验,更懂你的AI,立即体验豆包MarsCode编程助手
【推荐】抖音旗下AI助手豆包,你的智能百科全书,全免费不限次数
【推荐】轻量又高性能的 SSH 工具 IShell:AI 加持,快人一步
· 百万级群聊的设计实践
· WPF到Web的无缝过渡:英雄联盟客户端的OpenSilver迁移实战
· 永远不要相信用户的输入:从 SQL 注入攻防看输入验证的重要性
· 全网最简单!3分钟用满血DeepSeek R1开发一款AI智能客服,零代码轻松接入微信、公众号、小程
· .NET 10 首个预览版发布,跨平台开发与性能全面提升