微服务项目到底如何分模块？( 二 ) _微服务

文章插图

最外层是一个总的项目（称为总控pom），这个项目只有一个pom而没有src等，仅用来管理依赖，并联系起所有的模块。
模块项目指的是在项目目录下的项目。可以是任何项目。
总控pom与子模块怎么确认呢？

总控pom里通过和确认子模块
子模块通过确定总控pom

模块与模块之间通过来建立起联系。
如下图示意，蓝色方框表示总控pom ，浅蓝色方框表示模块：

文章插图
理论上，模块可以有任意多个，也可以是任何名称。这个问题跟技术无关，理论上你可以叫dog,cat,miaomiaomiao ，但是显然不够专业和实用。这就是公司内部要确定的规范了。

那么具体有哪些模块呢？
这里举例如下， woniu科技确定的统一的项目结构及解释如下：

common 项目工具模块
facade 给外部用的AP接口，打包后发布给其他服务调用方作为接口来使用
service 服务
dao 数据库访问层
model 数据模型层
domain 领域层，用来聚合复杂的领域模型
integration 集成层，集成外部的服务，例如云服务
web 提供web服务，目前这层基本没有了
assembly 打包层，将所有内容打包

下图展示了最少模块数量的一个多模块项目，除了common和facade以外的内容都放在assembly中

文章插图
? 统一配置

多个开发组之间可能会共用一些资源，比如用同一个redis集群， mq集群。那么这些配置是一致的，能够不重复配置是最理想的。万一redis集群地址更改也不需要每个项目改动。
还有一个可能是存在通用配置，比如日期格式在全公司是统一的，日志配置都是统一的， actuator暴露的端点也是一致的。
这类配置管理需求在spring-boot出现之前是非常难实现的。spring-boot的特性之一是外化配置，加上nacos的配置管理客户端，将配置完全交给nacos来管理。
nacos支持共享配置，那么就可以将一个share.properties加入到每个项目中，管理公共配置。一旦配置变更就可以自动在所有项目中启用。
spring: Application: name: user cloud: nacos: config: server-addr: localhost:8848 shared-configs[0]: data-id: share.properties group: DEFAULT_GROUP refresh: true
比如， woniu科技的公共配置内容包括：