PIGX从零开始快速构建分布式服务

如果你还在为构建一个分布式服务感到繁琐，被各种配置文件和服务搞到眼花缭乱头晕脑胀，那么这篇文章就可以帮你解决这个问题，让你快速构建一个可用的、安全的分布式服务。这里给出每个步骤的详细解释和截图，即使你对各个组件没有任何基础也一样可以快速搭建完成，但如果对以下组件有基础就会很容易理解各个步骤，下面的这些文档可以帮你快速进行了解pigx中涉及到的组件使用(都是精选好文，不过不熟悉这些并不影响环境搭建)，如有需要请自取。

Maven快速构建父子工程：maven构建父子工程详解
Mysql数据库快速安装：快速构建mysql各个版本数据库
Nacos入门到精通：nacos入门到精通
Redis入门到精通-各种架构的搭建: redis入门到精通
SpringSecurity+Oauth2快速认证: SpringSecurity+Oauth2 详解
Gateway入门到精通: Gateway入门到精通
Sentinel入门到精通: sentinel入门到精通
Xxl-Job官方文档: xxl-job官方文档
Springboot admin 详解: Springboot admin 详解
Swagger3: Swagger3 使用详解
Vue3基础入门：VUE3基础知识梳理

一、环境搭建

pig相关代码地址：
后端代码地址：https://gitee.com/log4j/pig.git
前端代码地址：https://gitee.com/log4j/pig-ui
pig官方文档参考地址：https://www.yuque.com/pig4cloud/pig

1.代码下载

根据上面提供的地址下载代码，如下图，笔者选择的版本是3.4.3的版本（选择版本时，最好选择前后端版本均存在的）。选择这个版本因为使用的是jdk8，且这个版本的pigx前后端都是存在的。

下载完解压以后是这样的文件夹目录：

需要关注的是下面的目录：

pig-ui  -- https://gitee.com/log4j/pig-ui

pig
├── pig-auth -- 授权服务提供[3000]
└── pig-common -- 系统公共模块
     ├── pig-common-bom -- 全局依赖管理控制
     ├── pig-common-core -- 公共工具类核心包
     ├── pig-common-datasource -- 动态数据源包
     ├── pig-common-job -- xxl-job 封装
     ├── pig-common-log -- 日志服务
     ├── pig-common-mybatis -- mybatis 扩展封装
     ├── pig-common-security -- 安全工具类
     ├── pig-common-swagger -- 接口文档
     ├── pig-common-feign -- feign 扩展封装
     └── pig-common-test -- oauth2.0 单元测试扩展封装
├── pig-register -- Nacos Server[8848]
├── pig-gateway -- Spring Cloud Gateway网关[9999]
└── pig-upms -- 通用用户权限管理模块
     └── pig-upms-api -- 通用用户权限管理系统公共api模块
     └── pig-upms-biz -- 通用用户权限管理系统业务处理模块[4000]
└── pig-visual
     └── pig-monitor -- 服务监控 [5001]
     ├── pig-codegen -- 图形化代码生成 [5002]
     ├── pig-sentinel-dashboard -- 流量高可用 [5003]
     └── pig-xxl-job-admin -- 分布式定时任务管理台 [5004]

2 更改maven目录

注意解压后服务是最外层是pig，内层就是auth，gateway这些了
新打开的项目，默认的目录都是c盘的默认位置，将maven和配置文件、仓库等信息进行调整，这里我习惯使用3.6.1

2更改完成后等待jar包的下载

这个过程受网络和下载地址影响，时间可能会很长，请耐心等待。。。

3 认真阅读README.md

IDEA打开后默认展示README.md，请认证阅读这个文档，这个会使得我们少走很多弯路，该文档里有初次搭建的文档地址，有学习视频的地址，有项目的各个组件的版本，有目录简介等，基本需要的信息，这里都是可以看到的，建议认证阅读。这里笔者使用的pig版本是3.4.3 他的主要组件版本如下：

依赖	版本
Spring Boot	2.6.2
Spring Cloud	2021.0.0
Spring Cloud Alibaba	2021.1
Spring Security OAuth2	2.3.6
Mybatis Plus	3.4.3.4
hutool	5.7.18
Avue	2.6.18

初次部署，建议先把环境对其：https://www.yuque.com/pig4cloud/pig/vsdox9，该文档会介绍当前版本锁需要的组件的版本和环境，建议保持一致。

4 更改服务名

将父工程的pig，以及各个子工程的服务名更改为自己需要的服务名即可，注意同时更改模块名和目录名

更改完成以后，还需要进入到该工程的父目录，将父目录中的modeles中的工程名对应修改掉才行

所有的其他服务需要修改服务名的，均需要做这种操作，其他修改这里就省略了。

注意1：更改后maven可能无法识别元项目了，需要我们手动添加下，在下面位置添加即可：

注意2：可能会碰到目录名无法修改的情况
此时检查是否有打开对应工厂的文件，将其关掉即可，若是找不到，建议重启电脑肯定会排除找不到的打开文件，再修改就可以了。

注意3：修改时所的父子工程都需要跟随变化
修改时会有多个层级的父子工程，注意不要修改漏了，如果有修改漏了肯定会有maven异常提示，最终修改完以后笔者的是这个样子

注意4：pig-common-bom 中引入的依赖名不要漏了，这里需要同步修改

注意5：更改sentinel-dashboard时，需要同步更改pom的finalname，如下位置：

5 编译代码

以上更改完毕，重新编译整个工程，直接编译父工程即可，验证代码有误问题，出现下图所示的BUILD SUCCESS 即表示代码无问题，我们可以直接使用的

二、基础服务auth、upms、gateway配置与启动

这是三个最基础的服务，将这三个服务跑起来，基本就成功了，其他的服务都是属于搭配的服务，可有可无，所以这三个才是根本，这里将这三个放到一起进行说明。

1 搭建数据库

根据上面README.md 的中提到的搭建文档，数据库我们应该用mysql5.7.8以上的版本，这里使用mysql8.0.30
搭建文档详见这里，这里不做详细介绍了：https://java-dream.blog.csdn.net/article/details/126630980
使用docker搭建完以后如下：

然后尝试连接，发现ok（如有异常，请在上面的安装文档里对号入座）：

2 初始化pig数据库信息

在下载的pig代码中有一个db文件夹，如下：

这里面有所有的pig需要依赖的数据库，我们需要将其初始化到自己的数据库中，这里的数据库名都是pig开头的，这里进行调整下

pig            ---->    ac_sys            ---->     系统库：用户、权限等
pig_codegen    ---->    ac_codegen        ---->     代码生成库：自动生成代码相关
pig_config     ---->    ac_config         ---->     配置库：租户、nacos相关表
pig_job        ---->    ac_job            ---->     分布式任务：xxl-job相关表

注意：记得在每个文件的最开始位置，同步修改库名，其他则不需要动了，修改完成后整体复制到navicat中执行即可。

如下所示就搭建完了所有需要的数据库了：

数据库搭建完成以后，有关数据库的更改还没结束，这里还需要我们将每个服务里用到的数据库名做对应调整，但调整会有一个问题，就是所有的配置文件都在pig-register（这里已经修改成ac-register了），我们需要先把这个服务启动起来才可以正常看到服务的配置文件，下一节来说说nacos服务（使用pig更改后的pig-register）的启动。

3构建nacos服务端

pigx封装了nacos服务端，不过一般不会直接使用他的nacos。不过无论你是否单独构建自己的nacos服务，首先都得启动pig-register的这个nacos服务，因为默认的配置信息都在这里，必须将其启动以后才可以看到，然后才可以将这些信息迁移到自己的nacos服务中，同时建议如果想要更换nacos服务端，建议将所有环境都调通以后最后再进行更换

3.1 更改pig-register配置并启动

首先找到pig-register中的配置文件bootstrap.yml，更改如下位置信息：

按照图中圈出的位置进行更改配置信息，这些信息都是上面数据库创建时声明的，请根据自己声明的信息进行对号入座修改。修改完成以后直接启动项目即可，控制台展示如下：

这时就可以访问nacos的控制台了使用地址：http://localhost:8848/nacos, pig-rester中的用户名密码是nacos，这个和nacos官方保持一致。

登录到系统以后可以看到有如下的配置文件，这些就是pigx提供的服务的默认配置文件了：

3.2 nacos中修改相关配置文件的配置信息

需要修改的配置文件如下：

将以上三个标红的配置文件的内容进行修改为对应的库名称（如果没有像笔者一样更改库名，则不需要这个操作了）。这里以pig-auth-dev.yml为例，其他类似。

3.3 nacos中修改认证配置applicaiton-dev.yml

这里的applicaiton-dev.yml配置文件，是一个公共配置文件，本地的配置文件通过nacos的shared-configs指定的都是公共配置文件。这里的配置信息可以被其他服务一起引用。
认证的服务名称我们已经修改为了ac-auth，所以各个资源服务器（访问服务时被security+oauth管理的服务）都需要更改对应的token验证地址的路径名，pig把这块的配置放在了公共配置文件applicaiton-dev.yml中，做如下修改即可。

security:
  oauth2:
    resource:
      loadBalanced: true
      # token-info-uri: http://pig-auth/oauth/check_token
      token-info-uri: http://ac-auth/oauth/check_token

3.4 nacos中网关配置更改ac-gateway-dev.yml

这里更改了服务名同时更改了pom的工件id，所以需要同步调整网关服务里的名称，这里做如下调整，详细更改的地方见文件里的注释

spring:
  cloud:
    gateway:
      locator:
        enabled: true
      routes:
        # 认证中心
        - id: ac-auth  # pig-auth --> ac-auth
          uri: lb://ac-auth  # pig-auth --> ac-auth
          predicates:
            - Path=/auth/**
          filters:
            # 验证码处理
            - ValidateCodeGatewayFilter
            # 前端密码解密
            - PasswordDecoderFilter
        #UPMS 模块
        - id: ac-upms-biz  # pig-upms-biz -->  ac-upms-biz
          uri: lb://ac-upms-biz  # pig-upms-biz -->  ac-upms-biz
          predicates:
            - Path=/admin/**
          filters:
            # 限流配置
            - name: RequestRateLimiter
              args:
                key-resolver: '#{@remoteAddrKeyResolver}'
                redis-rate-limiter.replenishRate: 100
                redis-rate-limiter.burstCapacity: 200
        # 代码生成模块
        - id: ac-codegen  # pig-codegen -->  ac-codegen
          uri: lb://ac-codegen  # pig-codegen -->  ac-codegen
          predicates:
            - Path=/gen/**


gateway:
  encode-key: 'thanks,pig4cloud'
  ignore-clients:
    - test

swagger:
  ignore-providers:
    - ac-auth   # pig-auth --> ac-auth
    - ac-codegen   # pig-codegen -->  ac-codegen

3.5 搭建自己的nacos服务并修改配置文件名

生产上大部分场景都是需要多个系统共用nacos服务的，所以建议还是使用自己的nacos服务，别用pig的pig-register了，这样方便共用，如果只是自己用直接用它的就行，省的自己搭了，这里笔者是使用自己的nacos服务。这里不做nacos服务端构建的详细过程，需要了解的参考这篇文章：https://java-dream.blog.csdn.net/article/details/132639913
自己搭建完nacos以后（建议使用2.0.3 以上的版本naocs服务端，我这里使用2.0.4版本服务端），
然后就需要我们手动将配置文件在自己的nacos服务端从新创建了，这里不能使用导出导入的功能迁移配置文件，因为配置文件建立后名称无法更改（导出后更改再导入会失败，我试过）。这里没啥特别需要说明的，在自己的nacos服务中创建好对应的配置文件把内容copy过去即可。

注意：上面因为已经修改了服务名（pig的服务名取的都是pom里的artifactId），所以配置文件的名称也需要同步修改，不然nacos是无法正常寻找到对应的配置文件的。

4 搭建自己的redis服务并修改配置文件applicaiton-dev.yml

这里不做redis服务的搭建的详细介绍，redis单机、主从、哨兵、集群的搭建，请看这里：https://java-dream.blog.csdn.net/article/details/118732529
笔者这里使用redis集群的方式，然后将application-dev.yml配置信息做如下更改即可：

spring:
  redis:
    # host: pig-redis # 这是单机时的配置
    database: 0 # 集群模式只能使用0号库
    pool:
      max-active: 500 #连接池最大连接数（负值表示没有限制）
      max-wait: 3000 #连接池最大阻塞等待时间（负值表示没有限制）
      max-idle: 300 #连接池最大空闭连接数
      min-idle: 50 #连接汉最小空闲连接数
      timeout: 1000 #连接超时时间（毫秒）
    cluster:
      nodes:
        - 172.17.32.184:7000
        - 172.17.32.184:7001
        - 172.17.32.184:7002
    password: 'newstart221'

5 修改pig-auth本地配置信息，启动服务

下面展示需要修改的各个服务的配置文件信息，需要在远端nacos服务中修改的配置已经修改完了，下面需要调整下本地的服务的配置信息，这里只需要修改nacos的配置信息即可，ip地址和port修改为我们真正的nacos的ip和端口即可，其他配置信息无需更改。
注意：这里无法加载下面的pom中的信息，手动将其修改为dev就行

然后就可以启动pig-auth服务了，可以发现正常启动了。

观察naocs中服务列表也是正常的：

6 修改pig-upms本地配置信息，启动服务

上面更改了auth服务，这里继续修改upms服务，auth的认证需要借助upms，所以只有修改完upms才可以初步的实现认证的正常执行，这里的修改内容和auth一样都是修改nacos的配置信息，和spring.profile.active。如下：

然后启动项目，发现项目正常启动了：

7 成功启动auth和upms，开始验证登录接口

上面已经启动了auth和upms可以开始验证登录了，，这里不做SpringSecurity+Oauth2的普及，需要了解相关知识请看这里：https://java-dream.blog.csdn.net/article/details/135815326。下面验证下获取token的接口：

# 请求方式POST
http://localhost:3000/oauth/token?client_id=pig&client_secret=pig&grant_type=password&username=admin&password=123456&scope=server

这里简单解释下，上面的参数是OAuth2中标准的一些请求参数，client_secret 和 client_id 可以去 pig库（我已经改成ac_sys库）中的sys_oauth_client_details表中查看，grant_type 授权模式这里是密码模式，固定传password，然后就是用户和密码需要去pig库中的sys_user表查看，不过密码是加密的默认是123456，scope 参数是授权范围的标识，如果不做支持三方登录的功能都是用server就行了，这个值也是和sys_oauth_client_details表中对应的，如下：

然后使用postman发起上面的请求就行了，执行结果如下：

发现，不对报错了说是密码错误，这里一下就想到了是不是数据库配置的有问题，去检查了下发现没有问题，然后就怀疑到用户信息加载出了问题（如果对认证流程不熟悉的建议看看上面的文章，不然不好排查问题），然后去看了下Springsecurity中的UserDetailsService的实现类，发现有一个远程调用的接口，用的是upms服务的接口查询用户信息，这里的feign客户端需要声明服务在nacos中的名称，这里的名称还是pig-upms-biz，如下图：

所以这里是属于漏改了，继续更正，将上图的两个名称的pig都替换成ac即可（如果对这个架构了解的不是太多，建议还是别改服务名和数据库名了），然后重启auth和upms系统再次使用postman发起调用，结果如下，可以发现已经正常响应token等信息了，说明upms和auth系统启动成功了。

然后使用获取到的token，随机测试一个upms的接口，这里就选择获取菜单树的接口了：/menu/tree ,下面是请求的postman信息截图了，可以发现信息获取正常，到此彻底确认auth和upms可用。

注意：OAuth中token验证的位置是Authentication中的Bearer Token，这点别搞错了，这是pigx要求的认证位置没啥好商量的只能这么传。

8 修改pig-gateway本地配置信息，启动服务

上面的主要服务auth和upms已经启动完成了，所以这里需要慢慢的增加边侧服务了，首先就是gateway，gateway的需要修改的配置和auth、upms都是一样，都是nacos的信息和spring.profile.active，这里同样不做gateway基础知识的普及，需要的看这里：
https://java-dream.blog.csdn.net/article/details/134882837
如下图：

然后启动gateway服务，启动如下，可以发现已经正常启动了：

正常启动以后，就可以验证服务的可用性了，先去看下gateway的路由规则，这里还是使用上面的菜单树接口来验证，所以我们还是通过gateway的路由调用upms服务，upms路由配置如下：

根据路由配置可知，我们想要调用upms服务需要增加前缀路径admin，所以通过网关路由到upms服务正确的路径如下：

http://localhost:9999/admin/menu/tree

执行截图如下，可以发现请求成功，证明网关服务正常了。

到这里为止，基础的springcloud的配置已经更改完成了，后面还有需要更改的是代码自动生成、监控、流控、分布式任务等的配置。

三、边侧服务sentinel、xxl、codegen、monitor配置与启动

如果对这四块没有使用要求，是可以直接将这四块代码删除，并不影响上面三个服务的运行的。上面三个基础服务已经完全够用了。所以这里将这四块一起说下。
注意：这四块的配置是以完成了第二部分的配置为基础开始的，如果没有看第二部分最好先把第二部分处理完以后再来配置这四块信息。

1.流控组件Sentinel控制台：ac-sentinel-dashboard

Sentinel是和Hystix类似的组件，都是用于系统的流量防控，被称为分布式系统的流量防卫兵。
这里不做Sentinel基础知识的介绍，需要了解的建议详细看看这篇文章：https://java-dream.blog.csdn.net/article/details/132796974
这里的ac-sentinel-dashboard，是Sentinel的dashboard控制台，其实没有这个控制台Sentinel也是可以正常工作的，只需要各个服务集成Sentinel时配置正确即可，但有了控制台可以更直观的看到Sentinel的流控规则。

1.1 更改 ac-sentinel-dashboard 本地配置

这里更改的内容还是nacos和spring.profile.active的配置，如下：

然后启动服务，启动正常，展示如下：

然后打开浏览器输入地址，用户名和密码都是sentinel

# sentinel 控制台
http://localhost:5003/#/login

登录成功则说明这个dashboard没有问题。
补充：本地配置文件application.yml中的配置项

logging:
  level:
    org:
      springframework:
        web: info
  file:
    name: ${user.home}/logs/csp/sentinel-dashboard.log

这里的name最好将${user.home}去掉，不然打包时会导致，加载本地的用户目录到测试和生产环境，我开始没有去掉，部署到测试环境会在服务位置建立如下目录：

上面的配置修改后如下：

logging:
  level:
    org:
      springframework:
        web: info
  file:
    name: logs/csp/sentinel-dashboard.log

1.2 更改nacos配置文件applicaiton-dev.yml

这里配置了共用的sentinel的配置，用以指明sentinel的dashboard的地址，需要我们更改为自己的dashboard地址，也就是上面我们启动的服务，我这里是本地启动的，ip更改为我本地的就行。

1.3 重启 auth、upms、gateway

上面已经更改完了所有需要更改的服务了，这里需要重启下auth、upms、gateway三个服务，来验证下sentinel和dashboard的可用性，重启后再次登录http://localhost:5003/#/login，会有如下展示：

这说明我们的服务集成sentinel和dashboard都是ok的了。

1.4 验证流控

这里我们还是使用upms的/menu/tree接口来进行验证。

• 第一步：调用一次接口 http://localhost:4000/menu/tree
  这一步调用接口让dashboard中可以正常看到接口信息的展示，sentinel中称为簇点链路，如下图：
  

• 第二步：增加流控规则
  点击上图中的流控按钮增加流控规则，流控配置页面如下图进行配置：
  
  配置完成后点击新增，即出现如下所示页面，这表示该接口最多1s种只处理10个请求，大于10个会提示流控异常（这里pig对异常进行了封装，只会返回code为1）。
  

• 第三步：使用jmeter验证流控
  这里借助jmeter来帮助我们实现并发的调用（如果并发设置小点手动点postman也是可以的），jmeter配置如下：
  
  下面是接口配置，注：别忘了加token
  
  然后开动测试，结果如下，可以发现确实有部分返回异常了（绿色正常，红色异常），到这里已经验证了sentinel的服务可用以及dashboard可用了。
  
  sentinel到这里就验证完毕了，这里不做sentinel的知识延展，需要了解的请看上面提供的文档连接。

2.分布式任务管理job：ac-xxl-job-admin

xxl-job是一个BS架构的组件，这里的ac-xxl-job-admin算是服务端，用以控制任务的调度执行和任务的展示以及日志的记录等功能，同样的这里也不做xxl-job的基础知识的普及，默认已经掌握了xxl-job的基础知识了，如需学习xxl-job的基础知识，这里推荐官方文档，介绍的特别详细：https://www.xuxueli.com/xxl-job/#%E4%BA%8C%E3%80%81%E5%BF%AB%E9%80%9F%E5%85%A5%E9%97%A8
下面开始更改对应的配置。

2.1 更改本地配置文件application.yml

这里根据自己的信息进行修改就行，我这里已经将数据库名由pig_job更改为了ac_job，所以我这里的库名是ac_job，
注意这里还增加了token的配置，用以调度中心和客户端的通信验证，这个最好加上保证生产使用时的安全。

2.2 更改本地配置文件bootstrap.yml，启动xxl-job-admin服务

这里需要更改的是nacos的配置和spring.profile.active，和上面的auth的更改都是类似的，如下图：

然后启动服务就行了，启动展示如下，说明启动成功了：

然后打开登录页面，使用默认的账号密码登录 admin/123456：

http://localhost:5004/xxl-job-admin

登陆进入系统以后有一个默认的任务，这个是xxl-job自带的，没啥用，如下图：

2.3 客户端upms服务配置，启动upms服务
服务端上面已经配置完成了，下面需要搞定客户端的配置了，pigx中并没有为某个服务引入job的依赖，使用时需要我们手动引入pigx的pig-common-job依赖，这里还是使用upms进行验证，所以在ac-upms-biz中引入如下依赖：

• 第一步：引入依赖

  # 无需声明版本，pig-common-bom已经声明了版本
  <dependency>
  	<groupId>com.pig4cloud</groupId>
  	<artifactId>pig-common-job</artifactId>
  </dependency>
  

• 第二步：bootstrap.yml增加配置信息
  xxl-job的客户端需要提供配置信息，配置信息如下，这里是我的配置，各个配置信息的含义详见配置里的注释

  # xxljob 配置
  xxl:
    job:
      admin:
        # 指定调度中心地址
        addresses: http://172.17.65.57:5004/xxl-job-admin
      executor:
        appname: upms-dev # 执行器名称，这个名称需要与调度中心配置的完全相同
        ip:             #执行器IP，默认为空表示自动获取当前服务IP
        port: 4001 # 该端口号是供调用中心调用执行器时与目标服务建立连接时使用
        accessToken: dc077699837d4190bd4050690bed879f # 与xxl-admin通讯的token，配置与调度中心保持一致
        logpath: /data/xxl-job/jobhandler  # 执行器运行日志文件存储磁盘路径
        logretentiondays: 7  # 执行器的调度日志保存天数
  
  

• 第三步：更改upms启动类注解SpringBootApplication配置
  pig-common-job的配置信息是放在pig-common-job的根目录文件上的。upms这个SpringBoot项目的自动加载配置只能加载当前项目根路径以下的配置信息，所以是无法加载pig-common-job中的配置信息的，所以需要我们对ac-upms-biz的启动类注解做如下更改，以帮我我们手动扫描到pig-common-job的配置信息：

  @SpringBootApplication(scanBasePackages = { "com.pig4cloud.pig.*" })
  

  配置截图如下：
  注意：指定的目录必须涵盖本项目原路径，若是不涵盖，就再传入一个本项目路径，不然会造成本项目的配置无法加载
  

2.4 upms服务增加测试类，启动upms服务

测试类代码如下，比较简单，注意bean交给spirng容器管理，同时value值一会需要在调度中心进行配置时与调度中心保持一致。

package com.pig4cloud.pig.admin.xxl;

import com.xxl.job.core.handler.annotation.XxlJob;
import org.springframework.stereotype.Component;

/**
 * @author pcc
 * @version 1.0.0
 * @description 测试xxl-job
 */
@Component
public class TestXxlJob {

	@XxlJob(value="testXxl")
	public String testXxl(){
		  System.out.println("执行任务");
	return "ok";
	}
}

然后就可以启动upms服务了，启动后有如下信息展示说明启动成功了：

2.5 调度中心配置执行器

在xx-job-admin中的执行管理器中增加一个执行器（理解成服务即可），位置如下：

然后做如下设置即可：

这里注册方式使用的是自动注册，如果保存后没有数据，从新打开这个配置保存下就会重新触发即可获取到客户端的信息了，如果没有也可以手动注册，手动注册的话就是在下面的机器地址中输入你的ip:port，注意这里的port是下图中的这个port：

2.6 调度中心配置测试任务，并测试

在调度中心的如下页面进行新增任务，任务需要关联上一步创建的执行器（理解成服务）：

点击新增按钮后会弹出如下页面，该页面就是我们最后一步的配置了，注意以下三块的配置，其他信息保持默认，或者随意指定就行：

然后保存就行，保存后再如下位置点击运行一次：

运行结束后可以再调度中心看调度日志也可以在upms中看我们自己打印的日志，这里展示下调度中心的日志，可以看到已经成功了。

到这里xxl-job的集成就全部成功了。如果有其他服务需要集成xxl-job进行调度，只需要参考upms的配置即可。

3.代码自动生成：ac-codegen

代码生成还是一个有用的功能的，这样我们只需要关注业务代码即可，增删改查完全就不用自己写了。不过只有一个后端服务会很不好用，这里最好的是配合前端服务一起使用，前端服务放到第四部分了（请移步至第四部分，先把前端搞定再看这里），对codegen服务做如下配置更改（和其他都是类似，修改nacos和spring.profile.active）：

下面是启动后的日志展示，可以发现正常启动了：

这里假设已经正常搞定了前端工程了（如果前端不熟建议花个半天了解下vue/node/npm等基础操作就可以上手前端了）。

3.1 配置数据源

代码自动生成的原理是根据数据库的表，然后生成对应的实体、mapper、service、serviceimpl等类或接口。所以数据源我们是必须要配置的，这里数据源根据自己想要操作的表进行变化，假设我们想要自动生成代码的对象表是ac_sys 库里的sys_log表。在pigx的后台打开如下页面：

进行数据源的新增，这里我进行测试的jdbc链接如下:

# 数据源
jdbc:mysql://172.17.32.184:3306/ac_sys?characterEncoding=utf8&zeroDateTimeBehavior=convertToNull&useSSL=false&useJDBCCompliantTimezoneShift=true&useLegacyDatetimeCode=false&serverTimezone=GMT%2B8&nullCatalogMeansCurrent=true&allowPublicKeyRetrieval=true

根据自己的实际信息参考如下配置进行设置：

3.2 开始生成代码

在如下位置点击生成按钮：

然后弹出如下界面：

着重关注如上两个设置，根据自己服务路径情况进行设置即可。
包名最好设置为，启动类路径去除最后一个路径（如果启动类路径是com.pig4cloud.pig.auth，最好包名使用com.pig4cloud.pig），而模块名就使用启动类路径的最后一个（如果启动类路径是com.pig4cloud.pig.auth，则是auth）。然后点击预览：

预览可以看到，已经生成了我们想要的所有代码了，然后返回点击下载即可

将下载下来的zip压缩包文件，解压后对号入座到自己的项目目录即可：

到这里代码自动生成就完成了，还是可以帮我们节省挺多CRUD时间的。

4.系统监控：ac-monitor

真正的生产系统一般不会用这个做监控，都有自己的一套监控系统，如果你们公司没啥成本投入又缺乏监控那就用这个吧，也能满足大部分场景需要不过如果想要做到故障通知还得二次开发。pigx的monitor通过集成spring-boot-admin来实现对服务的监控的，这里同样不做SpringBoot Admin的知识普及，如果需要了解请看这里：https://java-dream.blog.csdn.net/article/details/136263841.

4.1 更改配置文件

这里配置文件的更改与上面均无区别，不过这里需要集成nacos的原因还是需要提一下的，SpringBoot Admin获取服务信息都是通过ip+port+固定端口实现的，如果我们知道ip+port就无需客户端提供什么配置了，只需要SpringBoot Admin就行，而Nacos恰恰可以做这个事情，所以这里集成Nacos就可以完成这个事了。

4.2 启动服务，登录

上面配置更改完以后就可以启动服务了，比较简单应该不会有别的啥问题，注意，服务启动后同时启动下别的服务，比如auth、upms、gateway这些（只启动个别的也可以）：

服务正常启动后打开监控地址：

http://localhost:5001/login

这里因为集成了security进行了简单的认证，所以入口变成了登录入口，默认用户和密码都是pig。
登录后展示如下：

只要成功注册到了nacos中的服务都是可以在这里正常展示的，选择其中一个服务进入后可以查看具体的信息，这里以upms为例：

这里就不做具体功能的概述了，感兴趣的可以看笔者给出的链接来快速熟悉SpringBoot Admin ：https://java-dream.blog.csdn.net/article/details/136263841
到这里，所有的边侧服务也都是已经ok了。到这里基本就完成了大部分工作了。

四、前端服务pig-ui

上面已经完成了全部的后端服务的信息的更改和启动，也已经验证了服务的可用性，下面开始最前端项目进行启动了，如果对vue3不太熟悉，可以看这里：https://java-dream.blog.csdn.net/article/details/133779161前端项目根据README.md中的提示，我们环境应该满足以下条件：

# 查看 node 版本
node -v
v16.17.1

# 查看 npm 版本
npm -v
8.15.0

最好根据官方的要求提供node环境和npm的版本，这里不做node和npm等的安装指导，都比较简单网上随便就可以找到了。

1.前端环境对其

将我们的node版本调整为16.17.1或者以上，将npm调整为8.15.0或以上版本，笔者版本比较新，如下（这里有坑先别急和我保持一致，先往下看）：

2.下载pig-ui代码

pigx前端代码地址：https://gitee.com/log4j/pig-ui/tags
因为后端服务选择的版本是3.4.3 ，所以前端这里版本依然选择3.4.3，如下图所示进行下载：

代码下载下来以后放入到想要存储代码的文件夹即可，我这里是和后端服务放一起了，方便使用idea(我的idea版本2023.1.5)一起打开了，如下所示：

然后打开IDEA就会发现这里已经有了前端项目：

3.编译pig-ui项目

这里从IDEA进入到终端（使用cmd也是一样），先对项目进行依赖引入：

# 进入pig-ui文件夹
cd .\pig-ui-v3.4.3\
# 安装依赖
npm install

然后发现各种报错，这里省略1万字前端环境调整过程，说下最终如何ok的。
开始我的node和npm版本都是高于pigx要求的版本的，然后执行npm install 各种报错不行，然后切换node和npm版本将其和pigx要求的保持一致，依然各种报错，然后降低版本将版本降为了pigx要求的版本以下，然后执行npm install 就顺利通过了，如果你也碰到了类似问题，可以尝试下降低node 和 npm的版本，我最终成功的node和npm版本如下

npm install 受网络影响，请耐心等待一会。

4.启动pig-ui

在package.json所在的目录执行以下命令，启动pig-ui项目：

# 启动pig-ui
npm run dev

耐心等待一会后提示如下，说明成功了：

这时候可以点击链接访问我们的前端项目了，但是别着急登录，我们需要把所有需要的后端服务都起起来才可以正常使用，登录页如下：

5.启动所需后端服务，登录系统

这里依赖的后端服务有auth、upms、gateway、codegen、xxl-job-admin（如果你配置了xxljob就起，没有配置可以不起这个服务）
这些服务，在上面的介绍中都已经修改成功启动了，这里防止有未加载的配置，最好从新编译下顶级的父工程，让所有jar包都从新编译打包，然后重启上面介绍的五个服务。
重启完成后刷新下前端页面，此时验证码就会可以正常加载了，然后我么就可以使用admin/123456进行登录了，登录成功后展示如下：

到这里pig-ui就配置启动完成了，可以开启你前端代码的自定义工作了。

五、补充和总结

上面已经将所有的pigx涉及的服务都正常启动了，其实已经可以开发使用了，这里再补充说下文档接口和配置文件的拆分，这样应该就基本还改了pigx使用的绝大部分知识点了。

1.在线接口文档：Swagger

Swagger这里使用的是3.0.0的版本，他是一个简单易用的在线接口文档框架，这里同样不做知识的普及，想要详细了解的可以看看这里：https://java-dream.blog.csdn.net/article/details/136286474
pigx将swagger集成到了Gateway中，所以我们需要启动Gateway和upms两个服务才可以看出来，请先参考上面的介绍正常启动这两个服务，然后完成后打开如下地址：

# 网关的ip+端口+固定地址
http://localhost:9999/swagger-ui/index.html

打开后看到如上信息则表示正常了，这样swagger就可以正常使用了，不过上面还有一个认证的并未开启使用，如果想要使用还需要替换公共配置文件application-dev.yml中的配置为自己的网关地址就行，如果不想要集成认证则无所谓：

2.后端拆分生产配置文件

前面已经将需要更改的配置文件进行更改了，在真实项目中肯定不可能使用一套配置文件的，需要根据环境进行独立配置文件，一般是三套环境dev、test、prd，三套环境一般配置项都是相同的，只是配置的值不同。
注意springboot配置文件优先级：bootstrap.yml>bootstrap-环境.yml>application.yml>公共配置文件（nacos中使用shared-configs等声明的配置）。注意多个配置文件都存在时他们的配置都有效，只是配置项重叠时优先级不一样而已。

2.1 本地bootstrap.yml配置文件更改

这里以umps服务为例进行更改，多个配置文件通常都是使用spring.profile.active来进行指定环境，这里假如切分了三个环境dev/test/prd，那么我们启动服务时就是通过spring.profile.active来指定环境，其他信息公共的可以保留在bootstrap.yml中，需要根据不同环境区分配置的配置项则可以放置到对应环境的配置文件了。
下面是未拆分更改前的bootstrap.yml文件内容：

server:
  port: 4000

spring:
  application:
    name: @artifactId@
  profiles:
    active: dev
  cloud:
    nacos:
      discovery:
        server-addr: ${NACOS_HOST:172.17.32.184}:${NACOS_PORT:8848}
      config:
        server-addr: ${spring.cloud.nacos.discovery.server-addr}
        file-extension: yml
        shared-configs:
          - application-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}

# xxljob 配置
xxl:
  job :
    admin:
      # 指定调度中心地址
      addresses: http://172.17.65.57:5004/xxl-job-admin
    executor:
      appname: upms-dev # 执行器名称，这个名称需要与调度中心配置的完全相同
      ip:             #执行器IP，默认为空表示自动获取当前服务IP
      port: 4001 # 该端口号是供调用中心调用执行器时与目标服务建立连接时使用
      accessToken: dc077699837d4190bd4050690bed879f # 与xxl-admin通讯的token，配置与调度中心保持一致
      logpath: /data/xxl-job/jobhandler  # 执行器运行日志文件存储磁盘路径
      logretentiondays: 7  # 执行器的调度日志保存天数

这里有我们可以将端口号服务名和spring.profile.active还放在当前的文件，bootstrap.yml拆分更改后如下：

server:
  port: 4000

spring:
  application:
    name: @artifactId@
  profiles:
    active: dev

2.2 新增环境配置文件

这里假设有三个环境dev/test/prd，那么就需要建立三个配置文件：

bootstrap-dev.yml
bootstrap-uat.yml
bootstrap-prd.yml

这些配置文件里只需要声明配置中心和注册中心的配置就行，因为有了nacos的信息其他信息都可以存储在远端的nacos服务中了，所以环境配置文件只需要存放nacos的相关信息就行，这里三个配置文件内容完全相同只是配置的值不同，这里以我的dev为例：

spring:
  cloud:
    nacos:
      discovery:
        namespace: authentication
        server-addr: ${NACOS_HOST:172.17.32.184}:${NACOS_PORT:8848}
      config:
        namespace: authentication
        server-addr: ${spring.cloud.nacos.discovery.server-addr}
        file-extension: yml
        shared-configs:
          - application-${spring.profiles.active}.${spring.cloud.nacos.config.file-extension}

上面这些信息其实还是从boobtstrap.yml迁移过来的，此外增加了namespace的配置，真正使用时不建议使用public命名空间，注意命名空间的位置

2.3 迁移其他配置信息到远端nacos

最开始的bootstrap.yml中还有一块xxl-job的配置，这块信息属于各个环境都需要指定但是value不同的配置项，所以应该放到远端的nacos中，当然如果有别的也可以一同放入到远端的配置文件中，这里就不贴了，直接放进去就行，然后就可以尝试重启项目了，如下：

尝试验证服务功能，如无意外会发现功能正常，当然远端的配置文件也是需要独立各个环境的，需要我们提供多个环境的nacos服务，然后将文件复制过去，将配置值更改为各个环境的真实地址和配置值即可，不过配置项一般是不会有区别的，这里就不细说了。

3.总结

到这里pigx的主体功能就介绍完了，当然这只是框架和架构部分，代码部分并没有详细说都是一提而过，还有一些pigx的使用便捷操作等，等后面空了笔者再继续更新吧，这篇文章用以总结pigx框架的快速搭建过程就到这里了，希望可以帮助到路过的朋友。