修改源码定制SkyWalking-UI访问路径

SkyWalking简介

Apache SkyWalking是一款开源的观测性能平台,专为分布式系统设计,提供了全面的应用性能监控(APM)、服务网格观测、以及分布式追踪等功能。它帮助开发者和运维人员深入洞察应用的性能状况,快速定位问题根源,从而提升系统的稳定性和效率。SkyWalking的核心组件包括OAP服务器(Observability Analysis Platform)和UI界面,两者协同工作,为用户提供强大的可视化监控能力。

SkyWalking-UI简介

SkyWalking-UI是SkyWalking的可视化界面,它负责展示从OAP服务器收集来的监控数据,包括服务拓扑图、追踪详情、性能指标、告警信息等。通过SkyWalking-UI,用户可以直观地了解系统的健康状况,进行性能分析,以及配置监控规则。UI的设计旨在易于使用,同时支持高度定制化,以满足不同场景下的监控需求。

定制UI访问路径并重新编译

在某些场景下,用户可能需要将SkyWalking-UI的访问路径固定为特定的URL前缀,例如/skywalking-ui,以便更好地融入现有系统架构或便于管理。要实现这一需求,需要对SkyWalking-UI源码进行适当修改并编译。以下是一个简化的编译与配置步骤指南,适用于具有Java和Maven环境的用户。

准备工作

首先你得有JDK、Maven,版本要求参考官网

拉取代码

git clone --recurse-submodules https://github.com/apache/skywalking.git
cd skywalking/
git checkout v9.7.0 # 根据你的需求切换版本

HBuilderX uniapp项目转 cli 项目实现在容器中打包

HBuilderX 目前仅支持 Windows 和 macOS,这给发布流水线造成不小的阻碍,我们最初的做法是在一台 Windows 上安装 HBuilderX、Jenkins(下文称之为HXJenkins),HXJenkins 使用 HBuilder cli 命令行打包,主 Jenkins 调用 HXJenkins API 进行构建。我们实践之后,发现不少问题:

  • HXJenkins 打包 h5,我们要制作成容器镜像,打包后的 dist 需要回传给 Linux 服务器,Linux 服务器再制作容器镜像。流程非常复杂,还需要考虑文件如何回传等问题;
  • HBuilder cli 时不时会出现打不开项目的问题,需要重启 HBuilderX
  • 有时打包会特别的慢,且容易报错
  • 主 Jenkins 调用 HXJenkins API 进行构建,HXJenkins 构建报错上游无法知道,增加心智负担
  • ……

我们希望能实现基于容器的 uniapp 打包方案,经过在 DCloud 官网及搜索一番了解后,主要的方案有两个:

  1. HBuilderX 项目转为 vue cli 项目
  2. 底层都是 node,HBuilderX 只是把操作封装罢了,因此研究 HBuilderX 的打包原理,通过一些技术手段分析 HBuilderX 最终是执行的什么命令来打包的

方案一相对简单,也是本文所探讨的方案,但是可能在你的项目上实践不会轻而易举就能成功,一般会在依赖包以及依赖包的版本上会踩坑。

方案二相对复杂,但是通用性应该更好,方案二已经有大佬写了博客以及在 github 上维护了源码,有兴趣的读者请参考 漫谈Uniapp App热更新包-Jenkins CI/CD打包工具链的搭建_uniapp jenkins-CSDN博客

RocketMQ 5.X 初使用 & 踩坑

背景

RacketMQ 5.X 的发布,向云原生迈出了一大步。从官方的文档中,我们可以看到其中最大的一块变化是新增了 Proxy 模块,新旧版本架构对比如下:

  • RocketMQ 4.X 架构

    rocketmq4.x-arch.png

  • RocketMQ 5.X 架构

    rocketmq5.x-arch.png

在 RocketMQ4.X 的时候,深入使用过 RocketMQ 的人很多都可能遇到一个问题,RocketMQ 在复杂网络下是有缺陷的,比如说网上就有很多人问 RocketMQ 如何同时对内网和外网提供服务。得到的答案可能是让你修改brokerIP1、brokerIP2,brokerIP1 指向公网IP,brokerIP2 指向内网IP。但是这样并不能解决问题,因为 NameServer 始终会向客户端返回 brokerIP1 的地址,并不是真正解决了内外网的问题。

使用hook规范GitLab提交的用户名和邮箱

背景

使用GitLab的时候,开发者是可以随意设置其用户名和邮箱的。

git config --global user.name "abc"
git config --global user.email "123"

像我这样设置,代码依然可以正常提交,在gitlab上查看的时候显示的用户名是“abc”。

git-commit-username.png

Git本身精神就是协作,是自由、平等,而非集权式的代码库。这样设计也没毛病,但是在公司的代码管理中,这样就很不好,尤其是在开发 Leader review 代码的时候,如果没有正确配置用户名可能都不知道这代码是谁写的。

一劳永逸解决Jenkins安装插件超时、慢等问题

众所周知的原因,在国内访问Jenkins的插件站点不是很稳定,经常访问很慢或者超时。

如果你网上搜索Jenkins更换国内源等关键字,大多数文章都会告诉你做以下三个步骤:

  • 修改"Manage Jenkins"--->"Manage Plugins"--->"Advanced" --->"Update Site" URL为国内源,如https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json
  • /var/jenkins_home/updates/default.json文件内容中https://updates.jenkins.io/download替换为国内源,如https://mirrors.tuna.tsinghua.edu.cn/jenkins
  • 重启Jenkins

第一步有一个坑:https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/update-center.json下载的是始终是最新的插件,和旧版本的Jenkins是不兼容的,要替换为https://mirrors.tuna.tsinghua.edu.cn/jenkins/updates/dynamic-stable-VERSION/update-center.json才能装到匹配的插件版本,其中VERSION是当前Jenkins的版本。如果不是LTS版本,则dynamic-stable-VERSION要换成dynamic-VERSION

第二步修改了之后,过一段时间你想再装插件你会发现/var/jenkins_home/updates/default.json这个文件又被恢复成官方的了。此举并不是一劳永逸的,因为Jenkins会定时更新这个文件。

那么有没有更好的办法呢?答案是有的,下面就教大家如何一劳永逸地将Jenkins插件站点换为你想要的任何镜像站点。

方法示意图:

Jenkins.png

  • 修改hosts,使updates.jenkins.io指向nginx的IP
  • 配置nginx反向代理,指向你所希望访问的Jenkins插件站点

需要解决一个问题,Jenkins源站点是https协议的,Jenkins会校验SSL证书的有效性,因此我这里将使用nginx的sub_filter模块将update-center.json返回的内容修改为http协议的。