在网络通信中，端口是用于区分不同服务的重要资源。通常，每个服务会绑定到一个特定端口上，但有时我们需要通过同一个端口来代理不同的服务。这种技术被称为端口复用。本文将介绍端口复用的场景、用途、协议特性，并分别使用 Nginx 和 HAProxy 进行端口复用配置。

端口复用的场景与用途

端口复用在以下场景中非常有用：

1. 资源限制：在IP地址和端口资源有限的环境中，通过同一端口提供多个服务可以最大化利用现有资源。
2. 简化配置：简化客户端配置，使其无需关心不同服务使用不同端口的问题。
3. 负载均衡与高可用性：在负载均衡器或反向代理服务器上，通过同一端口代理不同的后端服务，提高服务的可用性和可靠性。

协议特性

端口复用的实现依赖于协议特性。通过分析协议的特定字段或数据包的前几个字节，可以判断请求的类型并将其转发到相应的后端服务。

可重现构建(reproducible builds)是一组软件开发实践，如果给定相同的源代码、构建环境和构建指令，任何一方都可以bit-by-bit重新构建出相同副本，则构建是可重现的。本文将探讨可重现构建的重要性，以及在maven项目中如何实现这一目标。

为什么需要可重现构建？

不知道你有没有发现，你的java工程在没有修改代码的情况下，两次构建出来的jar/war包md5值是不一样的。为什么会出现这种情况呢？jar包其实是一个zip压缩包，当你解包两次构建查看其中的差异时，你会发现最明显的区别就是文件夹的时间不一样了：

除了时间不一样以外，还有元数据等等，具体要解决的问题，在apache官网有个提案，记录了可重现构建需要解决的问题。

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 目前仅支持 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博客。

背景

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

• RocketMQ 4.X 架构

  

• RocketMQ 5.X 架构

  

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