先回顾一下common-frame中各个maven模块的依赖的层级关系。
业务应用在使用基础架构的时候也是按照这个层级思路进行搭建。
搭建过程主要分为以下几个步骤:
先通过idea提供的脚手架工程,将业务服务搭建成如下结构
springboot的多模块搭建的步骤如果有小伙伴不清楚的,由于不是本文重点,所以自行百度了
- <?xml version="1.0" encoding="UTF-8"?>
- <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
-
- <!-- 修改idea新的父pom依赖的spring boot的依赖,改为commmon-frame框架中的版本。这样业务服务所有依赖都可以被common-frame和common-dependency统一管理 -->
- <parent>
- <groupId>com.baiyan</groupId>
- <artifactId>baiyan-common</artifactId>
- <version>1.0.0-SNAPSHOT</version>
- </parent>
-
- <modelVersion>4.0.0</modelVersion>
- <artifactId>auth</artifactId>
- <version>0.0.1-SNAPSHOT</version>
- <packaging>pom</packaging>
- <name>auth</name>
- <description>鉴权中心</description>
-
- <!-- 业务模块定义 -->
- <modules>
- <module>auth-web</module>
- <module>auth-service</module>
- <module>auth-api</module>
- <module>auth-start</module>
- <module>auth-rpc</module>
- <module>auth-sdk</module>
- </modules>
-
- <!-- 工程内所有子模块都需要的依赖定义在此处 -->
- <dependencies>
- <dependency>
- <groupId>org.springframework.boot</groupId>
- <artifactId>spring-boot-starter-web</artifactId>
- </dependency>
- <dependency>
- <groupId>org.projectlombok</groupId>
- <artifactId>lombok</artifactId>
- <optional>true</optional>
- </dependency>
- <dependency>
- <groupId>org.springframework.boot</groupId>
- <artifactId>spring-boot-starter-test</artifactId>
- <scope>test</scope>
- </dependency>
- </dependencies>
-
- <!-- 统一定义业务模块版本。如果业务中使用的组件版本需要与common-frame中不一致,在此处统一定义组件的版本,方便全局管理 -->
- <dependencyManagement>
- <dependencies>
- <dependency>
- <groupId>com.baiyan</groupId>
- <artifactId>auth-api</artifactId>
- <version>${project.version}</version>
- </dependency>
- <dependency>
- <groupId>com.baiyan</groupId>
- <artifactId>auth-sdk</artifactId>
- <version>${project.version}</version>
- </dependency>
- <dependency>
- <groupId>com.baiyan</groupId>
- <artifactId>auth-service</artifactId>
- <version>${project.version}</version>
- </dependency>
- <dependency>
- <groupId>com.baiyan</groupId>
- <artifactId>auth-web</artifactId>
- <version>${project.version}</version>
- </dependency>
- <dependency>
- <groupId>com.baiyan</groupId>
- <artifactId>auth-rpc</artifactId>
- <version>${project.version}</version>
- </dependency>
- <dependency>
- <groupId>com.baiyan</groupId>
- <artifactId>auth-start</artifactId>
- <version>${project.version}</version>
- </dependency>
- </dependencies>
- </dependencyManagement>
-
- <build>
- <plugins>
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-compiler-plugin</artifactId>
- <version>3.5.1</version>
- <configuration>
- <source>1.8</source>
- <target>1.8</target>
- </configuration>
- </plugin>
- <plugin>
- <groupId>org.apache.maven.plugins</groupId>
- <artifactId>maven-source-plugin</artifactId>
- <version>3.2.1</version>
- <executions>
- <execution>
- <id>attach-sources</id>
- <goals>
- <goal>jar</goal>
- </goals>
- </execution>
- </executions>
- </plugin>
- </plugins>
- </build>
- </project>
- 复制代码
子模块的父级依赖定义为当前父级pom
- <project xmlns="http://maven.apache.org/POM/4.0.0"
- xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
- xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
- <parent>
- <groupId>com.baiyan</groupId>
- <artifactId>auth</artifactId>
- <version>0.0.1-SNAPSHOT</version>
- </parent>
- <modelVersion>4.0.0</modelVersion>
-
- <artifactId>auth-api</artifactId>
-
- <dependencies>
- <dependency>
- <groupId>com.baiyan</groupId>
- <artifactId>baiyan-common-api</artifactId>
- </dependency>
- </dependencies>
-
- </project>
- 复制代码
按照common-frame的结构构建业务结构
演示的auth服务中因为没有什么需要特殊定义与业务无关的一些工具类或者组件,所以我在演示服务里面暂时去掉了auth-base。
到这里看过工程内容的小伙伴是不是有点疑问?
auth-service中有一些util,为什么不把这些util抽出来放到auth-base中。这里我们需要注意一下,在service中定义的util、常量等一般是具有业务含义的,如果把它们放到auth-base中。那么按照规范我们的auth-api会依赖auth-base,那么这些业务util的逻辑就会暴露出去(比如这里用户密码的加解密逻辑),显然不合理。
因此,业务的base包存在的场景仅限于你的工具类、常量等定义具有业务开放性。比如外部服务需要知道你的加解密逻辑,外部服务直接调用你jar包中的方法来进行数据加解密。但是这种场景相对来说还是比较少的,如果有,这些工具定义也可以被定义在api包中。
那么如果有这种仅需要在service中使用,不需要开放给外部服务的业务无关的一些定义该如何定义呢?
两种方式:
我个人倾向于第二种方式,通过maven模块的形式进行工具类,通用定义隔离,让模块之间的职责更加清晰。但是第一种问题也不大,看大家自己抉择。
项目结构搭建完成之后,你只要进行一些简单的配置之后就能进行业务开发了。
我们通过spring所提供的多环境配置区分本地配置与线上配置。
线上配置我们统一走nacos,因为线上的一些配置都是比较隐私的。
- server:
- port: 8889
- ---
- spring:
- profiles: local
- datasource:
- type: com.alibaba.druid.pool.DruidDataSource
- username: root
- password: 123456
- url: jdbc:mysql://localhost:3306/user?autoReconnect=true&autoReconnectForPools=true&useUnicode=true&characterEncoding=utf8&useSSL=false&allowMultiQueries=true&allowPublicKeyRetrieval=true&serverTimezone=GMT%2B8&rewriteBatchedStatements=true
- driver-class-name: com.mysql.cj.jdbc.Driver
-
- logging:
- level:
- com:
- baiyan: debug
-
- mybatis:
- configuration:
- map-underscore-to-camel-case: true
- mapper-locations: classpath*:mapper/*.xml
-
- # login config
- auth:
- login:
- config:
- captcha: false
- password: true
- tokenTimeout: 86400
- resourceApi: /api/**
- exclude: /api/**/api-docs
-
- # swagger config ,服务启动后可以直接访问:http://localhost:8889/swagger-ui/index.html
- swagger:
- config:
- enable: true
- groupName: baiyan
- basePackage: com.baiyan.auth
- title: 柏炎鉴权中心
- description: 柏炎鉴权中心api
- version: 1.0.0-SNAPSHOT
-
- # web serializable config
- baiyan:
- config:
- jackson:
- enable: true
- ---
- spring:
- profiles: prod
- server:
- port: 8883
- 复制代码
在resource的根目录下增加message.properties.
演示的demo里面没有区分多语言,多语言配置只要在每个文件下增加固定的语言后缀即可。
启动类不用像在自己使用微服务时一样,定义很多的注解
- @SpringBootApplication
- @EnableDiscoveryClient
- @EnableCircuitBreaker
- 复制代码
直接使用common-frame提供的注解
- @BaiyanApplication
- 复制代码
来集成springcloud。
后续如果有一些通用的启动类上标注的注解也可以再扩展common-frame的注解,简化业务代码。
在rpc包中增加如下自动配置类
- @Configuration
- @Import(AuthFeignConfig.class)
- @AutoConfigureOrder(Ordered.HIGHEST_PRECEDENCE)
- @EnableFeignClients(basePackages = "com.baiyan.auth.rpc")
- public class AuthFeignClientAutoConfiguration {
-
- }
- 复制代码
就可以让你的rpc被其他服务开箱即用,不需要服务调用方在启动类上再增加
- @EnableFeignClients(value = {"com.baiyan.auth.rpc"})
- 复制代码
本文不涉及复杂的代码结构与思想,主要为大家介绍如何在日常的业务服务中使用common-frame。
至此,整个基础架构的介绍都已经结束了。
这个系列主要是想为大家介绍如何来构建起微服务的内部项目架构,抽离出通用的逻辑与配置来统一维护,让业务服务专注于业务开发。
文章开头的demo如果你们好好研究与打磨,我相信你会有不小的收获。
说的再多不如直接给你看代码,对吧。
有任何问题都可以加我微信或者在文章末尾留言哦~