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所失常代理了。