ZBProxy 自 2021 年 6 月 20 日第一次提交以来，至今已走过超过三个年头。ZBProxy 的发展见证了我个人技术的成长，这三年来我们也一直坚持更新，不断将它打造为更专业的加速IP最佳选择。

经过接近一个月的准备，我非常高兴地宣布即将到来的 ZBProxy 3.1 版本。它将是一个大更新，也是一个小更新。大，是因为我完全重写了所有代码，也引入了新的软件结构；小，是因为它近乎完全兼容旧版本的配置，依旧支持一键部署。我也想借此吐槽一些 ZBProxy 项目建项以来的槽点，尽管不少已经在我的个人群内被我提前讨论过了。（笑）

大更新？

是的，它是。

我们引入的更改包括如下：

• 重构整个代码，引入基于规则的分流机制
• 全新的日志格式，支持日志分级
• 代码趋近于模块化
• 支持以注册的方法添加自定义功能
• 迁移文档至 mkdocs ，归档旧的 GitBook 文档
• 恢复 Release 发布进程。我们将用 Release 发布稳定版本，并继续用 Action 发布开发版本临时构建。

这几乎完成了我最初在群内公布的计划。

超过三千行代码的重写，每一行都是对新代码结构的思考。引入的新结构能解决一直以来的痛点，比如：

• 重载部分的代码晦涩难懂。每次更改都有可能产生新的 bug，并且一些 bug 难以得到解决（比如 #103）
• 不能做到单入口多出口。以往一个服务只能转发到一个目标，端口无法复用。这难以通过简单更改配置或优化代码做到。

所以我重写了代码，然后把它变得模块化，在原有的基础上设计了配置文件新的部分。现在的 ZBProxy 不仅是一个程序，也是一个 Go 库，可以被其它项目调用。整个 ZBProxy 使用一个结构体管理，没有全局变量，使用 Go context 控制，支持注册自定义规则/嗅探，能满足你的所有想象。你也可以只调用 ZBProxy 的部分功能，以及一些 common 包，减少代码量和重复劳动。

我还提供了官方的扩展示例： https://github.com/layou233/ZBProxy-plugin-examples

目前编写了一个公会专属的加速 IP ，使用 ZBProxy 作为依赖，而没有修改任何一行 ZBProxy 本体的代码。 设计较为简陋，是因为我只是拿这个作为一个演示，证明了 ZBProxy 的潜力可以完全替代以前需要魔改才能做到的事情。如果有兴趣，你可以进一步开发，做到你想要的任何功能并部署到生产环境上。

对于 MC 开发者来说，不需要编写任何一行有关 Minecraft 协议数据解析的代码，因为所有相关明文信息都已经被预读取好并存入 metadata 元数据中，只需访问即可。（需要嗅探）

更多详见文档的原理——开发页，我会进一步阐述如何使用以及其优点和限制。

小更新。

关于新设计和旧版本的兼容性，实际上我想了一段时间。最后在模块化之后，这一问题迎刃而解。

我们保留 Service 的一些旧设计，比如内置的 Minecraft 功能。我们将这些旧功能成为“旧字段”（legacy field）。而使用旧字段的服务成为“旧服务”（legacy service）。

在识别为旧服务后，ZBProxy 会自动为旧服务生成一个对应的 outbound。实际上，旧服务是新服务和出站的捆绑，能完美兼容以前的功能和配置。 旧服务监听接受到的连接，不会进入路由，而是直接进行对应嗅探后进入内置的出站，与以前的做法效果相同。

对旧服务的支持恰恰是 ZBProxy 的程序优势。虽然称为“旧”，但我个人中短期内没有计划将其删除，因为它配置起来简单，能满足一些简单的需求，并且实现容易，并不会打乱代码结构。 因此虽然不刻意鼓励，但我依然支持你使用旧服务，尽管我可能只会为旧服务提供有限的功能性更新。

因此，这也是一个小更新。没有东西被破坏，一切如初。这很好，不是吗？

一些问题

以下部分摘选自我在群里的发言（

Q1: ZBProxy 1 和 2 是什么？

A1: ZBProxy 1 是最初的版本，仅实现了基础功能（恰好能跑的 bug）。ZBProxy 2 是对屎山的修改（更大的屎山）。其实 2 并不是一个非常大的升级，只是 1 的微不足道的性能优化，现在我更趋向于把它划为 1.1 或者 1.0.1 ，可是早在两年前就发布了，我也改不了啦。

Q2: 为什么 3 这么久才发布？

A2: 一是时间因素，二是我希望它足够稳定，三是仍有一些最初设计的功能迟迟没有实现（现在已放弃）。总的来说，前两个问题都是因为 ZBProxy 早期 versioning 不成熟导致。

Q3: ZBProxy 的 mcprotocol 包适合什么样的使用场景

A3: 适用于性能需求高的开发场景，因为它能实现缓冲区复用、向量化IO（vectorized IO）等十分需要技巧的优化。目前它不是一个完整的 MC 协议框架，没有加密、压缩等支持，只能处理简单的数据包（这对于 ZBProxy 来说足够了），但它确实拥有最佳性能，相比 go-mc 有许多可取之处。

目前不建议使用它用于对 Minecraft 协议的完整处理，除非你需要性能。go-mc 的接口在不经过修改的前提下可以进行的优化很少，但你也可以自行修改它以提升其性能。

有人说使用它写出来的代码难以阅读，实际上只是我过于追求优化而把代码写的比较魔幻而已（笑）。实际上它写起来也可以是整齐、优雅的。

Q4: ZBProxy 3.1 的代码量比以前明显变多了，看不懂！

A4: 这显然是一个伪命题。代码模块化之后，你需要作出一个修改所需要阅读的代码量是减少的，因为你只需要阅读那一个模块的代码，甚至无需通读全文。

你认为它变得更难理解，是因为你还没有开始阅读它。当你有需要的时候，你会花费精力去理解，而当需要变得没那么重要的时候，你放弃思考，而这是困难的根源。