微服务项目到底如何分模块
企业级项目结构封装释义如果你刚毕业,作为Java新手程序员进入一家企业,拿到代码之后,你有什么感觉呢?如果你没有听过多模块,分布式这类的概念,那么多半你会傻眼了。为什么一个项目会有这么多个子项目,这个项目里为何没有版本,这个parent是指向啥?今天我们模拟真实企业场景,来让大家掌握一些项目架构方面的知识。前提假设我们是同一家公司woniu科技,这家公司有5个开发小组,其中3个小组负责开发运营电影
企业级项目结构封装释义
如果你刚毕业,作为Java新手程序员进入一家企业,拿到代码之后,你有什么感觉呢?如果你没有听过多模块,分布式这类的概念,那么多半你会傻眼了。为什么一个项目会有这么多个子项目,这个项目里为何没有版本,这个parent是指向啥?
今天我们模拟真实企业场景,来让大家掌握一些项目架构方面的知识。
前提假设
我们是同一家公司woniu科技,这家公司有5个开发小组,其中3个小组负责开发运营电影票务网站,另外2个小组开发运营外卖网站。
思考
那么从技术管理的角度,几个项目组之间需要有哪些层面上的相同呢?
一般而言,公司内部会考虑统一技术栈和框架的版本,也会提供统一的工具类。好处显而易见:
- 方便进行管理,比如,统一升级版本,统一加入某项功能等等
- 降低学习研究的成本,企业级开发框架种类繁多,版本众多,统一之后程序员要学习的技术是最小的;相关技术专家也可以深入的研究某项技术,彻底hold住
- 减少出问题的概率以及排错的成本,一旦出错所有人都可以加入解决问题
- 统一的技术框架之间是兼容的,方便项目间的互操作,互相调用,共享代码等等
- 降低人员调动、招聘及培训成本
- …
所以,一个公司会尽力统一能够统一的一切,除非特殊的业务或者技术的需求。
统一规范
技术选型
一般而言,技术选型是一早确定的。比如选用SpringBoot还是Play框架,选用单体还是分布式,选用MySQL还是Oracle。选型结束之后变动的成本巨大,一般不会大改。开发团队在需要使用某项技术之前,应当先向技术负责人确定是否有已经定好的框架,避免不同团队之前使用不同的技术。
统一版本
技术框架选定之后,还需要统一版本。这个怎么做呢?
一个流行的解决方案是通过全公司共享一个总父项目,各个子项目不加版本,由这个总父项目来控制版本,子项目会根据情况自动升级。
这种专门管理版本的项目,我们一般称为BOM(Bill Of Materials 物料清单)。已经成为非常成熟的模式。如果你沿着spring-boot的parent往上追溯也会找到spring-boot-dependencies,就是一个BOM。
这里需要了解下 <dependencyManagement>
这个标签,它会管理依赖的版本,包括依赖排除这些,但是不会为子项目加入这个依赖。这点跟 <dependency>
是不同的,这也是BOM的关键技术。
另外,子项目通过 <parent>
指定父项目。
比如woniu科技会创建一个woniu-parent项目,负责管理版本全局统一的父pom。
统一工具类
一般公司内部都有自己的工具类,会提供一些类似如日期格式化,ID生成等等的工具类。这类的工具类是非常通用的,每个项目的每个模块都会需要用上。所以会考虑直接在总父pom中加入依赖。一旦加入就是全局引入,所有项目就自动获得这个依赖。所以除了这个统一工具类的依赖以外,很少会再加入其他依赖。
比如woniu科技会创建一个woniu-commons项目(单纯的maven-quickstart项目)来统一提供工具类,具体功能如下:
- 提供各种基础工具
- 统一响应格式(统一结果,但是通过拦截器封装结果,https://www.jianshu.com/p/fa75acba5b07)
- 统一错误码
- 统一的异常父类
- 统一的ID生成工具
- …
统一项目结构
项目当然可以是单体项目。但是既然是为了解决可能面对的复杂问题,我们就来模拟一个复杂的项目结构。
这里涉及到maven多模块项目的概念。
maven多模块项目其实是指在一个项目中包含多个独立的模块项目,每个模块可以单独打包成jar或者war。如下图所示。
最外层是一个总的项目(称为总控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科技的公共配置内容包括:
- 环境配置
- nacos地址
- mq地址
- redis地址
- …
- spring-boot配置
- actuator配置
- 常用配置
- mvc和json的日期格式
- 日志配置
总结
用下图总结上文所述,希望大家有所收获
无论你在学习上有任何问题,重庆蜗牛学院欢迎你前来咨询,联系QQ:296799112
更多推荐
所有评论(0)