服务介绍

本文按「代码怎么分层 → 服务有哪些 → 要启动哪些进程」三段展开。想先了解单体/微服务双形态的整体设计，请看架构介绍。

服务分层介绍

三个业务域（md-workbench 工作台、md-console 控制台、md-open 开发者平台）采用完全相同的 6 层结构，逐层单向依赖：

md-console/
├── console-server     # 启动层：启动类、全局配置、配置文件
├── console-web        # 请求处理层：Controller、参数校验
├── console-service    # 业务层：业务逻辑
├── console-dao        # 持久层：MyBatis-Flex Mapper，与数据库交互
├── console-pojo       # 实体层：实体、dto、vo、query、枚举
└── console-facade     # 接口适配层：跨服务调用接口（又拆 3 个子模块，见下文）
    ├── console-api
    ├── console-boot-impl
    └── console-cloud-impl

所以一个业务域实际是 8 个 Maven 模块（6 层中的 facade 再拆 3 个），facade 这层单独拆出来就是为了支撑双架构，机制见架构介绍第 1 节。

六层职责：

层	命名	职责
启动层	`xxx-server`	存放启动类、全局配置、配置文件
请求处理层	`xxx-web`	访问控制转发、基本参数校验、不复用的简单业务处理
业务层	`xxx-service`	具体的业务逻辑
持久层	`xxx-dao`	数据访问，基于 MyBatis-Flex 与底层数据库交互
实体层	`xxx-pojo`	实体类、dto、vo、query、枚举类
接口适配层	`xxx-facade`	跨服务调用的接口定义与双架构实现

不是所有模块都按这套分层。md-api（4 模块：api-server / api-web / api-service / api-pojo，无 dao、无 facade）、md-server（2 模块：boot-server / worker-server）、md-gateway（3 模块：inner-gateway-server / sop-gateway-server / zookeeper-server）本身就是启动层或纯服务，没有 facade 这层。

这套分层结构只是约定，不是限制。分层架构不是定死的，你完全可以按自己的想法和理念进行合并和拆分。

依赖关系

单个服务的依赖关系如下：

从图中可以看出，单体版的 boot-server 就相当于微服务版的 inner-gateway-server + workbench-server + console-server + open-server。

微服务

单体

跨服务调用时，依赖关系如下：

对于 api 层的同一个接口，需要为单体版和微服务版提供 2 个不同的实现类，并将不同的实现类依赖加入单体版或微服务版的启动层。

微服务

单体

facade 层的两个实现

子模块	实现方式	调用链
`xxx-api`	只放接口，如 `AppFacade`	调用方 `@Autowired AppFacade`，两种架构下这行代码完全相同
`xxx-boot-impl`	注入本域 `xxx-service`，进程内直调	A服务 Controller/Service → B-api → B-boot-impl → B-service
`xxx-cloud-impl`	注入 `@FeignClient`，HTTP 调远程 web 层	A服务 Controller/Service → B-api → B-cloud-impl → HTTP → B-web → B-service

以开发者平台域为例，AppFacadeImpl 在两个实现模块里同名不同体：

mdp-apps/md-open/open-facade/open-boot-impl/.../AppFacadeImpl.java:22 → private final AppService appService;
mdp-apps/md-open/open-facade/open-cloud-impl/.../AppFacadeImpl.java:22 → private final AppApi appApi;，而 AppApi 上是 @FeignClient(name = AppConstants.OPEN_SERVER, path = "/admin/app")，落点是 open-web/.../controller/admin/AppController.java

两套远程调用机制别混

facade 跨域调用用 OpenFeign（HTTP），目标是对端服务的 web 层；@EnableFeignClients 只出现在 api / workbench / console / open / inner-gateway 这 5 个微服务启动类上。
Dubbo（RPC）只服务于开发者平台链路：sop-gateway-server 泛化调用 api-service 里 4 个 @DubboService 实现类。

两者互不相干，读代码时不要因为看到 Dubbo 依赖就以为 facade 走的是 RPC。

新增一个跨服务接口的步骤

当 A 服务需要调用 B 服务的接口时：

在 B-api 层定义接口；
写实现类：单体架构写在 B-boot-impl，微服务架构写在 B-cloud-impl；
A 服务在调用它的那一层（A-service 或 A-web）加入 B-api 依赖，然后调用接口；
引实现依赖：单体在 boot-server/pom.xml 引 B-boot-impl，微服务在 A-server/pom.xml 引 B-cloud-impl。

架构定了可以删掉另一套实现

实际业务项目通常只部署一种架构。前期定了架构之后，可以直接删掉非目标架构的实现模块（单体删 xxx-cloud-impl，微服务删 xxx-boot-impl），减少冗余代码、降低编译部署成本。

服务一览

服务	单体版	微服务版	端口	职责
boot-server	✅	—	23455	核心业务全部功能（= 下面 4 个微服务的等价物）
inner-gateway-server	—	✅	23450	Web 端 / 移动端接口鉴权与路由
workbench-server	—	✅	23453	工作台，同时是 SSO 认证中心
console-server	—	✅	23451	控制台
open-server	—	✅	23452	开发者平台管理端
api-server	—	✅	23454	对外开放接口实现
worker-server	✅	✅	23457	定时任务执行器（+ 单体版兼任开放接口实现）
sop-gateway-server	✅	✅	23456	开放平台网关，对第三方提供统一入口
zookeeper-server	✅（仅 dev）	—	2181	内置注册中心，dev 环境替代 Nacos 做 Dubbo 服务发现
PowerJob	✅	✅	17700	分布式定时任务调度中心（开源项目，直接使用发行包）。17700 是 worker 连它的地址（`powerjob.worker.server-address`，HTTP 协议）

端口来源不同：inner-gateway / workbench / console / open / api 这 5 个微服务的端口配在 Nacos 配置中心；boot / worker / sop-gateway 的端口配在各自 jar 内的 application.yml。worker-server 不接 Nacos 配置中心，原因见架构介绍第 4 节。

工作台服务

项目名：md-workbench（微服务版进程为 workbench-server）。主要提供以下功能接口：

登录、退出、注册
SSO、OAuth2 等单点登录对接接口——MDP 的 SSO 认证中心就在本服务（微服务版 workbench-server，单体版即 boot-server），console/open 作为 sso-client 接入，配置见单点登录客户端配置
应用列表、应用免密跳转
登录日志
消息中心
个人中心

控制台服务

项目名：md-console。主要提供以下功能接口：

组织、岗位、用户
资源（菜单、按钮、接口）、数据权限、角色
系统配置、字典、文件、操作日志
消息任务、消息管理、消息模板、接口配置、接口日志

开发者平台服务

项目名：md-open。主要提供以下功能接口：

应用管理、应用申请、应用审核
开放接口、接口文档、帮助文档、OAuth2 权限、接口调用日志、接口回调记录
应用-接口权限
事件管理、事件触发、事件推送记录

对外接口服务

项目名：md-api（进程为 api-server），微服务架构时使用。主要提供以下功能接口：

对外提供的消息发送、短信发送、邮件发送接口
组织增删改查接口
用户增删改查接口

定时执行器服务

项目名：worker-server。单体架构和微服务架构都要启动（PowerJob 执行器只集成在本服务，api-server 不承担定时任务）。主要提供以下功能：

定时任务执行
对外开放接口（仅单体版启用，微服务版靠 dubbo.enabled: false 关掉）

单体版的 worker-server 是一身二职

单体架构：worker-server 同时负责「定时任务执行」和「对外接口调用」；
微服务架构：职责拆开——api-server 只负责对外接口调用，worker-server 只负责定时任务执行。

两种能力各有一个独立开关（dubbo.enabled、powerjob.worker.enabled），不用改 pom 就能裁剪，四种组合对应的角色、以及各环境出厂值见架构介绍 3.3 节。

内部网关服务

项目名：inner-gateway-server。仅微服务架构使用，面向 Web 端、移动端。主要提供以下功能：

接口鉴权（基于 sa-token reactive）
接口路由

单体版不引入本服务的代码：boot-server/pom.xml 只聚合 workbench-web、console-web、open-web 和三域 *-boot-impl，鉴权由进程内的 sa-token 拦截配置承担，路由则是同一进程内的 Spring MVC 映射。功能上等价，代码上不复用。

接口网关服务

项目名：sop-gateway-server。单体和微服务架构都使用，面向第三方。主要提供以下功能：

接口鉴权、验签、限流
对接口服务负载（通过 Dubbo 泛化调用打到 worker-server / api-server）

配置见开放平台网关配置。

单体服务

项目名：boot-server。仅单体架构使用，作为单体架构的启动层。主要提供以下功能：

工作台服务全部功能（含 SSO 认证中心）
控制台服务全部功能
开发者平台全部功能
Web 端 / 移动端的接口鉴权（能力对应内部网关服务）

注册中心服务

微服务版必须用 Nacos；单体版可以按环境二选一：

环境	注册中心	说明
开发（dev）	内置 `zookeeper-server`（端口 2181）	运行 `ZookeeperRegistryServer` 的 main 方法即可，无需额外部署。仅供本地开发演示，生产禁用
测试 / 生产	Nacos	由 pom 的 Maven profile 自动切换 Dubbo 的 Nacos starter，地址通过 `@config.nacos.*@` 编译期注入，见编译期配置（filters）

只有用到「对外开放接口」时才需要注册中心；只跑核心业务的 boot-server 完全不依赖注册中心。

定时调度器服务

项目名：PowerJob。分布式调度器，直接使用开源项目：https://gitee.com/KFCFans/PowerJob。主要提供以下功能：

定时调度（调度结果下发给 worker-server 执行）

关于 worker-server 与 api-server

这一节的详细论证（依赖对比、分工图、开关矩阵）在架构介绍第 3 节，此处只保留启动视角的结论：

两者的开放接口来自同一批代码（都依赖 api-web + sop-spring-boot-starter），定时任务只有 worker-server 能执行。
单体版让 worker-server 兼任接口实现，是为了少起一个进程；微服务版把它拆成两个进程，是为了职责单一。
所以「按需启动」时，接口用 api-server（微服务）或 worker-server（单体），定时任务必须用 worker-server——具体清单见下一节。

项目启动项

单体架构启动

开发环境

中间件
- mysql
- redis
- zookeeper（内置 zookeeper-server，启动 main 方法即可）
- 文件本地存储
后端服务
- boot-server
- worker-server（dev 出厂 powerjob.worker.enabled: false，见下方说明）
- sop-gateway-server
- PowerJob（本地不做定时任务时可不装）
前端项目
- web-workbench（7700）
- web-console（7710）
- web-open（7720）

测试环境

中间件
- mysql
- redis
- nacos
- RustFS/MinIO/云存储等任意一个外部OSS
后端服务
- boot-server
- worker-server
- sop-gateway-server
- PowerJob
前端项目
- web-workbench
- web-console
- web-open

生产环境

中间件
- mysql
- redis
- nacos
- RustFS/MinIO/云存储等任意一个外部OSS
后端服务
- boot-server
- worker-server
- sop-gateway-server
- PowerJob
前端项目
- web-workbench
- web-console
- web-open

按需启动

需要系统功能时
- 后端服务仅需启动 boot-server
- 前端项目按需启动 web-workbench、web-console、web-open
- 中间件仅需 mysql、redis，无需 nacos/zookeeper
需要对外提供接口时
- 后端服务仅需启动 worker-server、sop-gateway-server
- 前端项目无需启动
- 中间件需 mysql、redis，nacos/zookeeper（2选1）
需要执行定时任务时
- 后端服务仅需启动 PowerJob、worker-server
- 前端项目无需启动
- 中间件需 mysql、redis；worker-server 的开放接口能力用 dubbo.enabled: false 关掉，可不用 nacos/zookeeper

上述组合不必靠改依赖实现：worker-server 同时具备开放接口、定时任务执行两种能力，只用其一时用开关裁剪另一个——只要开放接口就配 powerjob.worker.enabled: false，只要定时任务就配 dubbo.enabled: false。dev 环境出厂为 dubbo.enabled=true、powerjob.worker.enabled=false（即本地默认不连 PowerJob），详见架构介绍 3.3 节。

微服务架构启动

开发环境

中间件
- mysql
- redis
- nacos
- 文件本地存储
后端服务
- inner-gateway-server
- workbench-server
- console-server
- open-server
- api-server
- worker-server
- sop-gateway-server
- PowerJob
前端项目
- web-workbench（7700）
- web-console（7710）
- web-open（7720）

测试环境

中间件
- mysql
- redis
- nacos
- RustFS/MinIO/云存储等任意一个外部OSS
后端服务
- inner-gateway-server
- workbench-server
- console-server
- open-server
- api-server
- worker-server
- sop-gateway-server
- PowerJob
前端项目
- web-workbench
- web-console
- web-open

生产环境

中间件
- mysql
- redis
- nacos
- RustFS/MinIO/云存储等任意一个外部OSS
后端服务
- inner-gateway-server
- workbench-server
- console-server
- open-server
- api-server
- worker-server
- sop-gateway-server
- PowerJob
前端项目
- web-workbench
- web-console
- web-open

按需启动

需要系统功能时
- 后端服务需启动 inner-gateway-server、workbench-server、console-server、open-server
- 前端项目按需启动 web-workbench、web-console、web-open
- 中间件需 mysql、redis，nacos
需要对外提供接口时
- 后端服务仅需启动 api-server、sop-gateway-server
- 前端项目无需启动
- 中间件需 mysql、redis，nacos
需要执行定时任务时
- 后端服务仅需启动 PowerJob、worker-server（执行器只在 worker-server，api-server 不承担定时任务）
- 前端项目无需启动
- 中间件需 mysql、redis；把 worker-server 配成纯执行器后可不用 nacos

微服务版把 worker-server 当纯执行器用时（上面第 3 种），务必显式配 dubbo.enabled: false：worker-server 的 test/prod 出厂值是两种能力全开，漏配会让它与 api-server 同时注册成同一批开放接口的 provider，被 sop-gateway-server 轮询到。详见架构介绍 3.3 节。