一、微服务拆分原则:

  • 以业务模型切入,比如:订单管理、商品管理等。
  • 单一职责、高内聚:单个微服务的职责尽量单一。但是粒度要适中,不能过度拆分,过度拆分是微服务架构的灾难!
  • 充分考虑团队结构:微服务的拆分要充分的考虑团队的结构,与微服务开发运维之间的关系。
  • 演进式拆分:如果各方面资源不允许,可以考虑演进式拆分。
  • 避免环形依赖与双向依赖:避免微服务之间的环形依赖或者双向依赖。

二、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服务的的提供者

在实际的工程项目中,一个微服务可能既是服务消费者,又是服务的提供者。