SpringCloud微服务包含多个SpringBoot可运行的应用程序,在单应用程序下,版本发布时的打包部署还相对简单,当有多个应用程序的微服务发布部署时,原先的单应用程序部署方式就会显得复杂且不可控。那么我们就会思考使用简单的部署方式,解决自动化发布、自动化部署、微服务监控等问题。

  我们使用目前行业通用的解决方案,Jenkins+GitLab+Maven+Docker+Kubernetes来实现可持续自动化部署微服务的功能。下面将从工程中Maven打包文件配置、Dockfile文件编写开始到Kubernetes配置来说明如何实现SpringCloud微服务可持续自动化部署功能。

1、bootstrap.yml文件不同环境加载配置

  在项目打包部署时,我们系统的配置文件需要根据不同的环境来区分开发、测试、生产环境的配置,在之前的SpringBoot工程中,我们用到spring.profiles.active配置属性,使用application.yml、application-dev.yml、application-test.yml、application-sit.yml、application-uat.yml、application-prod.yml来区分不同环境的配置文件。在SpringCloud中,我们用到了Nacos注册中心,Nacos的Config默认读取的是bootstrap.yml配置文件,如果将Nacos Config的配置写到application.yml里面,工程启动时就会一直报错。下面是SpringCloud加载配置文件的顺序:

  • bootstrap.yml(bootstrap.properties)先加载,用于应用程序上下文的引导阶段,可以用来配置application.yml中使用到的参数,由父Spring ApplicationContext加载。
  • application.yml(application.properties)后加载,用于配置各工程模块中使-用到的参数。

  所以在SpringCloud工程中我们通过使用bootstrap.yml、bootstrap-dev.yml...等不同的配置文件来区分不同的环境,有些框架是放到同一个yml配置文件中,然后不同的配置放到不同的spring.profiles.active下面,类似于下面这种:

spring:
profiles: dev
开发配置项: 开发配置项
spring:
profiles: test
测试配置项: 测试配置项

但是,在实际开发过程中,我们开发、测试的配置文件有时会经常修改,而生产部署环境确很少改动,当多人员开发时,难免会有部分人员不小心将配置文件改动影响到生产环境配置,即使没有影响,开发人员在改动时也要小心翼翼,害怕哪里改错。当我们将这些配置分开时,开发、测试的配置文件无论如何改动,都不会影响到生产环境文件,这正是我们想要的结果。所以我们将不同环境的配置放到不同的配置文件中。我们将配置文件分为bootstrap.yml、bootstrap-dev.yml、bootstrap-test.yml、bootstrap-prod.yml

<!-- bootstrap.yml -->
server:
port: 8001
spring:
profiles:
active: @spring.profiles.active@
application:
name: @artifactId@
cloud:
nacos:
discovery:
server-addr: ${spring.nacos.addr}
config:
server-addr: ${spring.nacos.addr}
file-extension: yaml
prefix: ${spring.nacos.config.prefix}
group: ${spring.nacos.config.group}
enabled: true
<!-- bootstrap-dev.yml -->
spring:
profiles: dev
nacos:
addr: 127.0.0.1:8848
config:
prefix: gitegg-cloud-config
group: GITEGG_CLOUD
<!-- bootstrap-test.yml -->
spring:
profiles: test
nacos:
addr: 测试地址:8848
config:
prefix: gitegg-cloud-config
group: GITEGG_CLOUD
<!-- bootstrap-prod.yml -->
spring:
profiles: prod
nacos:
addr: 生产地址:8848
config:
prefix: gitegg-cloud-config
group: GITEGG_CLOUD

  上面的配置可以满足分环境打包读取不同配置文件的目的,但是在实际开发过程中我们发现,我们的微服务太多,如果要修改Nacos配置的话,每个微服务的配置文件都需要修改一遍,虽然可以用IDEA批量替换,但是感觉这不是很好的方式。我们理想的方式是这样的:

  • 所有的微服务配置文件默认都从一个统一的地方读取
  • 当有某一个微服务需要特殊的配置时,只需要修改它自己的配置文件即可

实现上面的方式,我们可以将Nacos的配置到放到Maven的profile中,不同环境的bootstrap.yml可以读取其对应环境的配置信息,修改后的配置如下:

<!-- bootstrap.yml -->
server:
port: 8001
spring:
profiles:
active: @spring.profiles.active@
application:
name: @artifactId@
cloud:
nacos:
discovery:
server-addr: ${spring.nacos.addr}
config:
server-addr: ${spring.nacos.addr}
file-extension: yaml
prefix: ${spring.nacos.config.prefix}
group: ${spring.nacos.config.group}
enabled: true
<!-- bootstrap-dev.yml -->
spring:
profiles: dev
nacos:
addr: @nacos.addr@
config:
prefix: @nacos.config.prefix@
group: @nacos.config.group@
<!-- bootstrap-test.yml -->
spring:
profiles: test
nacos:
addr: @nacos.addr@
config:
prefix: @nacos.config.prefix@
group: @nacos.config.group@
<!-- bootstrap-prod.yml -->
spring:
profiles: prod
nacos:
addr: @nacos.addr@
config:
prefix: @nacos.config.prefix@
group: @nacos.config.group@
<!-- pom.xml -->
<profiles>
<profile>
<activation>
<!--默认为dev环境打包方式-->
<activeByDefault>true</activeByDefault>
</activation>
<id>dev</id>
<properties>
<spring.profiles.active>dev</spring.profiles.active>
<nacos.addr>1127.0.0.1:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
</properties>
</profile>
<profile>
<id>test</id>
<properties>
<spring.profiles.active>test</spring.profiles.active>
<nacos.addr>测试环境地址:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
</properties>
</profile>
<profile>
<id>prod</id>
<properties>
<spring.profiles.active>prod</spring.profiles.active>
<nacos.addr>生产环境地址:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
</properties>
</profile>
</profiles>

这样,通过在pom.xml里面不同profile的配置,就可以实现修改一处,使所有微服务读取Nacos的配置文件同时修改。

  修改完之后,可能会有这样的疑惑:现在我们三个文件bootstrap-dev.yml、bootstrap-test.yml、bootstrap-prod.yml内容配置基本是一样的,只有profiles的值不同,那么实际可以直接写在bootstrap.yml一个文件中,通过pom.xml来配置区分不同环境即可。那么这里做的目的和意义:主要是为了后续可扩展定制,某个环境特定的配置。

2、Maven打包配置

在编写pom.xml之前,我们先了解一下几个常用Maven打包插件的区别和联系:

  • maven-compiler-plugin: 用于在编译(compile)阶段加入定制化参数,比如设置项目源码的jdk版本、编译的jdk版本,以及项目编码等。
  • maven-jar-plugin: 将maven工程打成 jar 包,提供了manifest的配置,生成jar包中一般存放的是.class文件和resources目录下的配置,不会将依赖的jar包打包成一个可运行的jar包。
  • spring-boot-maven-plugin: 其在Maven的package生命周期阶段,能够将mvn package生成的软件包,再次打包为可执行的软件包,并将mvn package生成的软件包重命名为*.original。 其主要作用就是将SpringBoot工程代码和依赖的jar包全部打包为可执行的jar或war文件,可以直接在jre环境下运行。

  因为maven-jar-plugin打包的jar是把打包的jar和lib放在同一目录下,不是打成一个包,所以这样打的jar包文件很小。spring-boot-maven-plugin打包是把maven-jar-plugin打的jar包和依赖库repackage一个可运行的jar包,这个jar包文件很大。如果考虑到系统升级时的网络因素,那么使用maven-jar-plugin是最好不过了,当依赖库不改变的时候,只升级很小的jar包即可。这里因为是企业级微服务应用开发框架,不考虑网络传输的影响,考虑系统升级稳定性,不至于开发时依赖库修改了版本,而生产环境依赖库版本升级导致所有微服务受到影响,所以我们选择使用spring-boot-maven-plugin插件进行打包。

  在GitEgg工程的父级pom.xml里配置如下:

    <properties>
<!-- jdk版本1.8 -->
<java.version>1.8</java.version>
<!-- maven-compiler-plugin插件版本,Java代码编译 -->
<maven.plugin.version>3.8.1</maven.plugin.version>
<!-- maven编译时指定编码UTF-8 -->
<maven.compiler.encoding>UTF-8</maven.compiler.encoding>
</properties> <build>
<finalName>${project.name}</finalName>
<resources>
<!-- 增加分环境读取配置 -->
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
<excludes>
<exclude>**/*.jks</exclude>
</excludes>
</resource>
<!-- 解决jks被过滤掉的问题 -->
<resource>
<directory>src/main/resources</directory>
<filtering>false</filtering>
<includes>
<include>**/*.jks</include>
</includes>
</resource>
<resource>
<directory>src/main/java</directory>
<includes>
<include>**/*.xml</include>
</includes>
</resource>
</resources>
<pluginManagement>
<plugins>
<!-- 用于在编译(compile)阶段加入定制化参数,比如设置项目源码的jdk版本、编译的jdk版本,以及项目编码等 -->
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
<version>${maven.plugin.version}</version>
<configuration>
<source>${java.version}</source>
<target>${java.version}</target>
<encoding>${maven.compiler.encoding}</encoding>
<compilerArgs>
<arg>-parameters</arg>
</compilerArgs>
</configuration>
</plugin>
<!-- 能够将Spring Boot应用打包为可执行的jar或war文件,然后以通常的方式运行Spring Boot应用 -->
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
<version>${spring.boot.version}</version>
<configuration>
<fork>true</fork>
<finalName>${project.build.finalName}</finalName>
</configuration>
<executions>
<execution>
<goals>
<goal>repackage</goal>
</goals>
</execution>
</executions>
</plugin>
</plugins>
</pluginManagement>
<plugins>
<plugin>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-maven-plugin</artifactId>
</plugin>
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-compiler-plugin</artifactId>
</plugin>
</plugins>
</build> <profiles>
<profile>
<activation>
<!--默认为dev环境打包方式-->
<activeByDefault>true</activeByDefault>
</activation>
<id>dev</id>
<properties>
<spring.profiles.active>dev</spring.profiles.active>
<nacos.addr>127.0.0.1:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
</properties>
</profile>
<profile>
<id>test</id>
<properties>
<spring.profiles.active>test</spring.profiles.active>
<nacos.addr>127.0.0.1:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
</properties>
</profile>
<profile>
<id>prod</id>
<properties>
<spring.profiles.active>prod</spring.profiles.active>
<nacos.addr>127.0.0.1:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
</properties>
</profile>
</profiles>

  以上Maven配置完成之后,就可以进行正常的打可运行的SpringBoot包了。通常情况下,如果不使用docker和k8s集群,那么就可以直接使用Jenkins一键打包部署到测试或生产环境了。

  我们下面将一步步介绍如何实现将微服务打包为Docker文件,进而发布到Docker镜像仓库私服Harbor上,k8s拉取私服Harbor上的Docker文件进行分布式部署。

  • Docker: 开源的应用容器引擎,打包应用以及依赖包到一个可移植的镜像中,可以发布到任何流行的 Linux或Windows操作系统的机器上。
  • Harbor: 区别于Docker官方提供的公共的镜像仓库,可以用于本地部署的私有Docker镜像仓库。
  • Kubernetes(k8s): 用于自动部署,扩展和管理容器化应用程序的开源系统,可以自由地部署在企业内部,私有云、混合云或公有云
3、Docker打包配置

  目前,网上有多种Docker打包插件使用说明,讲解最多的是Spotify开源的,Spotify官方已不再推荐使用docker-maven-plugin插件进行打包,而是推荐其最新的docker打包插件dockerfile-maven-plugin,但是dockerfile-maven-plugin也已经很久没有更新了,在使用方面也有局限性,比如:只支持在本机Docker的镜像build、tag、push。经过在网上搜索,发现Google开源的Jib插件功能更强大,它可以不写Dockerfile,不需要在本地安装Docker环境就能实现Docker打包,而且一直在更新,所以这里选择这个插件作为我们的Docker打包插件。

  SpringBoot打包会将所有的依赖和资源文件等打包到一起,生成一个Fat Jar,这个Fat Jar的文件大小往往高达百兆,如果受制于网络环境,那么发布时,会传输较慢;同时,发布多次后,会占用大量的磁盘空间。尤其微服务架构下,会有一堆的Far Jar,那么,我们可以利用Docker镜像的分层结构特性,将应用程序的公共依赖打包为源镜像层,发布应用时,只发布业务修改层的代码。下面介绍Jib( jib-maven-plugin插件 )如何将SpringBoot应用程序分层打包Docker镜像,充分利用Docker的镜像分层复用机制,解决网络限制和占用大量磁盘空间的问题。

Jib( jib-maven-plugin插件 )构建的三个参数:

  • buildTar:本地构建,不需要Docker daemon就可以将镜像生成tar文件,保存在工程的target目录下

  • dockerBuild:将构建的镜像存到当前环境的Docker daemon

  • build:将构建的镜像推送到远程仓库,官方仓库或者Harbor私有仓库

  • 在GitEgg工程的父级pom.xml里配置jib-maven-plugin如下:

    <properties>
......
<!-- jib-maven-plugin插件版本,代码打包docker -->
<jib.maven.plugin.version>3.1.4</jib.maven.plugin.version>
......
</properties>
<pluginManagement>
<plugins>
......
<!-- Docker 打包插件 -->
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<version>${jib.maven.plugin.version}</version>
<!-- 绑定到Maven的install生命周期 ,此处如果不使用https,会有问题,需要设置sendCredentialsOverHttp=true-->
<executions>
<execution>
<phase>install</phase>
<goals>
<goal>build</goal>
</goals>
</execution>
</executions>
<configuration>
<!--允许非https-->
<allowInsecureRegistries>true</allowInsecureRegistries>
<!-- 相当于Docerkfile中的FROM -->
<from>
<image>openjdk:8-jdk-alpine</image>
</from>
<to>
<image>${docker.harbor.addr}/${docker.harbor.project}/${project.artifactId}:${project.version}</image>
<auth>
<username>${docker.harbor.username}</username>
<password>${docker.harbor.password}</password>
</auth>
</to>
<container>
<!--jvm内存参数-->
<jvmFlags>
<jvmFlag>-Xms512m</jvmFlag>
<jvmFlag>-Xmx4g</jvmFlag>
</jvmFlags>
<volumes>/giteggData</volumes>
<workingDirectory>/gitegg</workingDirectory>
<environment>
<TZ>Asia/Shanghai</TZ>
</environment>
<!--使用该参数保证镜像的创建时间与系统时间一致-->
<creationTime>USE_CURRENT_TIMESTAMP</creationTime>
<format>OCI</format>
</container>
</configuration>
</plugin>
</plugins>
</pluginManagement>
...... <profiles>
<profile>
<activation>
<!--默认为dev环境打包方式-->
<activeByDefault>true</activeByDefault>
</activation>
<id>dev</id>
<properties>
<spring.profiles.active>dev</spring.profiles.active>
<nacos.addr>172.16.20.188:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
<docker.harbor.addr>172.16.20.175</docker.harbor.addr>
<docker.harbor.project>gitegg</docker.harbor.project>
<docker.harbor.username>robot$gitegg</docker.harbor.username>
<docker.harbor.password>Jqazyv7vvZiL6TXuNcv7TrZeRdL8U9n3</docker.harbor.password>
</properties>
</profile>
<profile>
<id>test</id>
<properties>
<spring.profiles.active>test</spring.profiles.active>
<nacos.addr>127.0.0.1:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
<docker.harbor.addr>172.16.20.175</docker.harbor.addr>
<docker.harbor.project>gitegg</docker.harbor.project>
<docker.harbor.username>robot$gitegg</docker.harbor.username>
<docker.harbor.password>Jqazyv7vvZiL6TXuNcv7TrZeRdL8U9n3</docker.harbor.password>
</properties>
</profile>
<profile>
<id>prod</id>
<properties>
<spring.profiles.active>prod</spring.profiles.active>
<nacos.addr>127.0.0.1:8848</nacos.addr>
<nacos.config.prefix>gitegg-cloud-config</nacos.config.prefix>
<nacos.config.group>GITEGG_CLOUD</nacos.config.group>
<docker.harbor.addr>172.16.20.175</docker.harbor.addr>
<docker.harbor.project>gitegg</docker.harbor.project>
<docker.harbor.username>robot$gitegg</docker.harbor.username>
<docker.harbor.password>Jqazyv7vvZiL6TXuNcv7TrZeRdL8U9n3</docker.harbor.password>
</properties>
</profile>
</profiles>

在需要docker打包的工程pom.xml里面添加插件引用

    <build>
<plugins>
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
</plugin>
</plugins>
</build>

在不需要docker打包的工程pom.xml里面需要配置skip=true

    <build>
<plugins>
<plugin>
<groupId>com.google.cloud.tools</groupId>
<artifactId>jib-maven-plugin</artifactId>
<configuration>
<!--此模块不打可执行的jar包,打普通jar包即可-->
<skip>true</skip>
</configuration>
</plugin>
</plugins>
</build>

Docker本地打镜像tar包命令:

clean package -Ptest jib:buildTar -f pom.xml

Docker把镜像push到本地docker命令:

clean package -Ptest jib:dockerBuild -f pom.xml

Docker把镜像push到远程镜像仓库命令:

clean package -Ptest jib:build -Djib.httpTimeout=200000 -DsendCredentialsOverHttp=true -f pom.xml

  Jib( jib-maven-plugin插件 )的构建可以绑定到maven生命周期,以上实例中,已经绑定到maven的install生命周期,在实际使用时,因为安全方面的考虑,不支持http发送用户名密码,需要设置sendCredentialsOverHttp=true。

常见问题
  • 在bootstrap.yml中无法读取@spring.profiles.active@,且提示found character '@' that cannot start any token.

    解决:项目中如果没有指定spring-boot-starter-parent,resources->resource->filtering一定要设置为true才能够解析@,如下所示:
  <build>
<resources>
<resource>
<directory>src/main/resources</directory>
<filtering>true</filtering>
</resource>
</resources>
</build>
  • GitEgg-Platform作为平台jar包,不需要打docker文件,在GitEgg-Cloud打包时会引入GitEgg-Platform的jar包,所以上面的配置只需要在GitEgg-Cloud工程下配置。
  • K8S部署yaml,Jenkins脚本会首先读取子工程是否有配置部署的yaml,如果有则使用,如果没有则读取根目录下的部署yaml。
apiVersion: apps/v1
kind: Deployment
metadata:
name: {APP_NAME}-deployment
labels:
app: {APP_NAME}
spec:
replicas: 1
revisionHistoryLimit: 3
selector:
matchLabels:
app: {APP_NAME}
template:
metadata:
labels:
app: {APP_NAME}
spec:
hostNetwork: true
containers:
- name: {APP_NAME}
image: {IMAGE_URL}/{IMAGE_PROGECT}/{APP_NAME}:{IMAGE_TAG}
imagePullPolicy: Always
resources:
limits:
cpu: 300m
memory: 500Mi
requests:
cpu: 100m
memory: 100Mi
ports:
- containerPort: {APP_PORT}
env:
- name: SPRING_PROFILES_ACTIVE
value: {SPRING_PROFILE}
imagePullSecrets:
- name: harbor-key ---
kind: Service
apiVersion: v1
metadata:
name: {APP_NAME}-service
labels:
app: {APP_NAME}
spec:
selector:
app: {APP_NAME}
ports:
- protocol: TCP
port: {APP_PORT}
targetPort: {APP_PORT}
  • docker安装启动命令
docker pull 172.16.20.175/gitegg/gitegg-service-system:1.0-SNAPSHOT
# --restart=always 自动重新启动 , /opt/gitegg 是配置 jar包运行的位置
docker run -d imageId --restart=always --name=gitegg-service-system -p 8006:8006 /opt/gitegg
# 查看是否启动
docker ps
# 查看日志
docker logs --tail 100 -f gitegg-service-system
  • docker-compose配置启动
docker-compose up -d
  • docker使用容器内网络,当服务注册中心Nacos使用docker-compose安装时使用,注册到Nacos的地址为docker容器内ip
......
networks:
- giteggNetworks
......
networks:
giteggNetworks:
driver: bridge
......

完整yaml

version: '3'
services:
gitegg-service-system:
image: 172.16.20.175/gitegg/gitegg-service-system:1.0-SNAPSHOT
container_name: gitegg-service-system
ports:
- 8001:8001
volumes:
- "/data/gitegg/gateway/gitegg-service-system.jar:/app.jar"
- "/data/gitegg/gateway/logs:/logs"
logging:
options:
max-size: "100m"
networks:
- giteggNetworks
gitegg-service-base:
image: 172.16.20.175/gitegg/gitegg-service-base:1.0-SNAPSHOT
container_name: gitegg-service-base
ports:
- 8002:8002
volumes:
- "/data/gitegg/base/gitegg-service-base.jar:/app.jar"
- "/data/gitegg/base/logs:/logs"
networks:
- giteggNetworks
gitegg-oauth:
image: 172.16.20.175/gitegg/gitegg-oauth:1.0-SNAPSHOT
container_name: gitegg-oauth
ports:
- 8003:8003
volumes:
- "/data/gitegg/oauth/gitegg-oauth.jar:/app.jar"
- "/data/gitegg/oauth/logs:/logs"
networks:
- giteggNetworks
gitegg-service-extension:
image: 172.16.20.175/gitegg/gitegg-service-extension:1.0-SNAPSHOT
container_name: gitegg-service-extension
ports:
- 8005:8005
volumes:
- "/data/gitegg/extension/gitegg-service-extension.jar:/app.jar"
- "/data/gitegg/extension/logs:/logs"
networks:
- giteggNetworks
gitegg-code-generator:
image: 172.16.20.175/gitegg/gitegg-code-generator:1.0-SNAPSHOT
container_name: gitegg-code-generator
ports:
- 8006:8006
volumes:
- "/data/gitegg/generator/gitegg-code-generator:/app.jar"
- "/data/gitegg/generator/logs:/logs"
networks:
- giteggNetworks
gitegg-gateway:
image: 172.16.20.175/gitegg/gitegg-gateway:1.0-SNAPSHOT
container_name: gitegg-gateway
ports:
- 801:80
volumes:
- "/data/gitegg/gateway/gitegg-gateway:/app.jar"
- "/data/gitegg/gateway/logs:/logs"
networks:
- giteggNetworks
networks:
giteggNetworks:
driver: bridge
  • docker使用宿主机网络,不能和上面的使用容器内网络同时使用。当服务注册中心Nacos单独部署时使用,Nacos获取到的是docker宿主机的ip
......
network_mode: "host"
......

完整yaml,使用了network_mode: "host"之后,不能再使用ports端口映射

version: '3'
services:
gitegg-service-system:
image: 172.16.20.175/gitegg/gitegg-service-system:1.0-SNAPSHOT
container_name: gitegg-service-system
network_mode: "host"
volumes:
- "/data/gitegg/gateway/gitegg-service-system.jar:/app.jar"
- "/data/gitegg/gateway/logs:/logs"
logging:
options:
max-size: "100m"
gitegg-service-base:
image: 172.16.20.175/gitegg/gitegg-service-base:1.0-SNAPSHOT
container_name: gitegg-service-base
network_mode: "host"
volumes:
- "/data/gitegg/base/gitegg-service-base.jar:/app.jar"
- "/data/gitegg/base/logs:/logs"
gitegg-oauth:
image: 172.16.20.175/gitegg/gitegg-oauth:1.0-SNAPSHOT
container_name: gitegg-oauth
network_mode: "host"
volumes:
- "/data/gitegg/oauth/gitegg-oauth.jar:/app.jar"
- "/data/gitegg/oauth/logs:/logs"
gitegg-service-extension:
image: 172.16.20.175/gitegg/gitegg-service-extension:1.0-SNAPSHOT
container_name: gitegg-service-extension
network_mode: "host"
volumes:
- "/data/gitegg/extension/gitegg-service-extension.jar:/app.jar"
- "/data/gitegg/extension/logs:/logs"
gitegg-code-generator:
image: 172.16.20.175/gitegg/gitegg-code-generator:1.0-SNAPSHOT
container_name: gitegg-code-generator
network_mode: "host"
volumes:
- "/data/gitegg/generator/gitegg-code-generator:/app.jar"
- "/data/gitegg/generator/logs:/logs"
gitegg-gateway:
image: 172.16.20.175/gitegg/gitegg-gateway:1.0-SNAPSHOT
container_name: gitegg-gateway
network_mode: "host"
volumes:
- "/data/gitegg/gateway/gitegg-gateway:/app.jar"
- "/data/gitegg/gateway/logs:/logs"

源码地址:

Gitee: https://gitee.com/wmz1930/GitEgg

GitHub: https://github.com/wmz1930/GitEgg

SpringCloud微服务实战——搭建企业级开发框架(三十四):SpringCloud + Docker + k8s实现微服务集群打包部署-Maven打包配置的更多相关文章

  1. SpringCloud微服务实战——搭建企业级开发框架(十一):集成OpenFeign用于微服务间调用

    作为Spring Cloud的子项目之一,Spring Cloud OpenFeign以将OpenFeign集成到Spring Boot应用中的方式,为微服务架构下服务之间的调用提供了解决方案.首先, ...

  2. SpringCloud微服务实战——搭建企业级开发框架(八):使用注解校验微服务消息参数

      平时开发过程中,经常要用到参数校验,如果直接在代码逻辑里面写参数校验,代码有点冗余且用起来不是非常方便,显得代码逻辑复杂且重复代码太多,这里我们使用注解的方式进行参数校验,SpringBoot中常 ...

  3. SpringCloud微服务实战——搭建企业级开发框架(十四):集成Sentinel高可用流量管理框架【限流】

      Sentinel 是面向分布式服务架构的高可用流量防护组件,主要以流量为切入点,从限流.流量整形.熔断降级.系统负载保护.热点防护等多个维度来帮助开发者保障微服务的稳定性. Sentinel 具有 ...

  4. SpringCloud微服务实战——搭建企业级开发框架(十二):OpenFeign+Ribbon实现负载均衡

      Ribbon是Netflix下的负载均衡项目,它主要实现中间层应用程序的负载均衡.为Ribbon配置服务提供者地址列表后,Ribbon就会基于某种负载均衡算法,自动帮助服务调用者去请求.Ribbo ...

  5. SpringCloud微服务实战——搭建企业级开发框架(十五):集成Sentinel高可用流量管理框架【熔断降级】

      Sentinel除了流量控制以外,对调用链路中不稳定的资源进行熔断降级也是保障高可用的重要措施之一.由于调用关系的复杂性,如果调用链路中的某个资源不稳定,最终会导致请求发生堆积.Sentinel ...

  6. SpringCloud微服务实战——搭建企业级开发框架(十):使用Nacos分布式配置中心

    随着业务的发展.微服务架构的升级,服务的数量.程序的配置日益增多(各种微服务.各种服务器地址.各种参数),传统的配置文件方式和数据库的方式已无法满足开发人员对配置管理的要求: 安全性:配置跟随源代码保 ...

  7. SpringCloud微服务实战——搭建企业级开发框架(十六):集成Sentinel高可用流量管理框架【自定义返回消息】

    Sentinel限流之后,默认的响应消息为Blocked by Sentinel (flow limiting),对于系统整体功能提示来说并不统一,参考我们前面设置的统一响应及异常处理方式,返回相同的 ...

  8. SpringCloud微服务实战——搭建企业级开发框架(十九):Gateway使用knife4j聚合微服务文档

      本章介绍Spring Cloud Gateway网关如何集成knife4j,通过网关聚合所有的Swagger微服务文档 1.gitegg-gateway中引入knife4j依赖,如果没有后端代码编 ...

  9. SpringCloud微服务实战——搭建企业级开发框架(三十七):微服务日志系统设计与实现

      针对业务开发人员通常面对的业务需求,我们将日志分为操作(请求)日志和系统运行日志,操作(请求)日志可以让管理员或者运营人员方便简单的在系统界面中查询追踪用户具体做了哪些操作,便于分析统计用户行为: ...

  10. SpringCloud微服务实战——搭建企业级开发框架(三十八):搭建ELK日志采集与分析系统

      一套好的日志分析系统可以详细记录系统的运行情况,方便我们定位分析系统性能瓶颈.查找定位系统问题.上一篇说明了日志的多种业务场景以及日志记录的实现方式,那么日志记录下来,相关人员就需要对日志数据进行 ...

随机推荐

  1. Java编程之学习技巧

    **本人博客网站 **IT小神 www.itxiaoshen.com 找到技术点 首先得知道自己要学习技术是什么?不管是来自同事.技术大牛推荐还是通过搜索引擎得到,或者另有出处如.技术交流群.技术论坛 ...

  2. SpringBoot集成邮件发送

    一:简述 在日常中的工作中难免会遇到程序集成邮件发送功能.接收功能:此篇文章我将使用SpringBoot集成邮件发送功能和接收功能:若对邮件一些基本协议和发送流程不懂的请务必参考我之前写的博客或者浏览 ...

  3. 7.4 k8s结合ceph rbd、cephfs实现数据的持久化和共享

    1.在ceph集群中创建rbd存储池.镜像及普通用户 1.1.存储池接镜像配置 创建存储池 root@u20-deploy:~# ceph osd pool create rbd-test-pool1 ...

  4. 洛谷 P4094 [HEOI2016/TJOI2016]字符串(SA+主席树)

    题面传送门 一道码农题---- u1s1 感觉这类题目都挺套路的,就挑个有代表性的题写一篇题解罢. 首先注意到答案满足可二分性,故考虑二分答案 \(mid\),转化为判定性问题. 考虑怎样检验 \(m ...

  5. 洛谷 P3266 - [JLOI2015]骗我呢(容斥原理+组合数学)

    题面传送门 神仙题. 首先乍一看此题非常棘手,不过注意到有一个条件 \(0\le x_{i,j}\le m\),而整个矩阵恰好有 \(m\) 列,这就启发我们考虑将每个元素的上下界求出来,如果我们第一 ...

  6. [R]在dplyr基础上编写函数-(2)substitute和quote

    关于这两个函数,官方是这么定义的: substitute returns the parse tree for the (unevaluated) expression expr, substitut ...

  7. C#表格GridView显示2位百分比

    <asp:BoundField HeaderText="占比" DataField="number" DataFormatString="{0: ...

  8. A Child's History of England.36

    CHAPTER 11 ENGLAND UNDER MATILDA AND STEPHEN The King was no sooner dead than all the plans and sche ...

  9. day16 Linux三剑客之awk

    day16 Linux三剑客之awk 1.什么是awk,主要作用是什么? 什么是awk,主要作用是什么? awk 主要用来处理文件,将文本按照指定的格式输出.其中包含变量,循环以及数组. 2.awk的 ...

  10. Hive(六)【分区表、分桶表】

    目录 一.分区表 1.本质 2.创建分区表 3.加载数据到分区表 4.查看分区 5.增加分区 6.删除分区 7.二级分区 8.分区表和元数据对应得三种方式 9.动态分区 二.分桶表 1.创建分桶表 2 ...