Skywalking 在 9.0+ 版本后重做了前端 UI，叫做“Booster UI”，以前的“Rocketbot UI”被弃用。默认状况下，新版本的 UI 在官网提供的“SkyWalking APM”下载包中，默认以 jar 包的模式进行部署。下载后通过查看其官网文档对于 UI 的配置文件和阐明，会发现该 UI 我的项目的前端内部又被包裹了一层 Spring Boot/Spring Cloud Gateway 网关。当咱们须要将该 UI 我的项目部署到自定义的网关（如 nginx）后，并且减少映射拜访门路时，会发现无论如何申请都无奈失常路由到正确的前端资源地址，因为在 Booster UI 中，前端门路都写死到了根门路下，于是就没有方法在两头减少映射门路了。
首先，思考到官网应用 Spring Boot/Spring Cloud Gateway 对前端我的项目进行了又一层的封装，这对于自定义网关和前端门路来说都减少了不少难度，因而就开始寻找有没有前端本来的我的项目源码，便找到了 Github 上的 skywalking-booster-ui。clone 下来源码之后，批改 vue.config.js，在 module.exports 中减少一行 publicPath: "/skywalking"，这个就是你前端部署在服务器上之后须要配置的子门路。如果只批改这一行，部署之后会发现，前端要去申请一个 graphql 地址，这个地址没有被 publicPath 所影响，因而其申请的门路还是域名根门路，随后在代码中全局搜寻 ”/graphql”，发现有三个中央配置了 graphql 申请门路，即 vue.config.js 的 29,8，fetch.ts 的 25,6 和 index.ts 的 53,10，三个中央都改成 /skywalking/graphql，而后应用 npm 编译（此处省略 npm 的装置过程），并且 npm 版本必须是 LTS 16+，不能是 Current 18+，否则会报编译谬误。编译命令是npm run build。而后将生成的 dist 文件夹上传部署到服务器的既定目录下。
当初，就能够应用 nginx 对该前端资源进行代理了。这里先贴出 nginx 的相干配置：
location /skywalking/graphql {
proxy_method POST;
proxy_pass http://127.0.0.1:12800/graphql;
}
location /skywalking {
alias /opt/skywalking/skywalking-front/dist/;
try_files $uri $uri/ /skywalking/index.html;
}首先，当 location 有重叠局部时，nginx 是依照先后顺序匹配的，因而将具备子门路的 location /skywalking/graphql 写在 location /skywalking/ 后面。而后，依据官网提供的 webapp.yml 配置文件的以下内容：
spring:
cloud:
gateway:
routes:
- id: oap-route
uri: lb://oap-service
predicates:
- Path=/graphql/**
discovery:
client:
simple:
instances:
oap-service:
- uri: http://localhost:12800咱们能够揣测，当申请本机的 /graphql/** 接口时，申请被重定向到 http://localhost:12800/graphql，并且该申请通过测试为 post 申请，因而咱们将其申请代理转发到对应的 Skywalking server 的 rest 端口上，并且接口为/graphql，办法为 post，因而有了location /skywalking/graphql 的两行配置。至于 location /skywalking/ 的两行配置，首先 alias 和 try_files 的作用能够看 nginx 官网文档，另外，以后端我的项目为 vue 时，vue+nginx 的配置，vue 路由必须先加载 index.html 或者 XX.js 能力辨认到路由，因而能够了解成最初一行为针对 vue 我的项目 history 路由模式的固定配置，hash 路由据悉无此问题。对于 hash 和 history 路由模式的在 nginx 下的区别，能够参考 history 路由模式下的 nginx 配置。
至此，skywalking-ui 曾经可能被 nginx 所失常代理了。