转眼 5 年，两个当初写着玩的 go 项目不知不觉加了很多功能，合计也有 3000 多 star 了，开心又疲惫，当作是职业生涯的纪念

两个项目分别是： https://github.com/lesismal/arpc

2024 年到现在的主要变化：

arpc

一点缝缝补补
顺便支持了 stream 。我个人觉得 stream 比较鸡肋，因为原本已经支持双向 Call/Notify 在绝大多数场景都比 stream 还方便，需要 stream 的场景并不多。

nbio

优化 http/websocket 解析相关的逻辑和对象，降低了内存使用和 gc 压力，配合 SetMemoryLimit 让，在 4c 的 ubuntu 虚拟机上，百万连接 websocket 1k payload 压力测试，内存占用能控制在 1G 以内、tps 10w 。
优化了 bufferpool ，[]byte 变为 *[]byte ，减少小对象频繁分配，降低 gc 压力，这是首次 sub package interface 定义变更、与之前版本不兼容，但 nbio 主 package 仍然保持兼容性，除非自定义了 mempool 否则用户因该也不需要对代码做改变。
改掉了一些 buffer 相关的低概率脏内存 bug

当初这两个项目都是写着玩的

两年多前，把 arpc 也拿去 rpc benchmark 仓库去跟其他知名项目对比了下，也算是跑出了个不错的成绩，比较公平的三方测试可以请看鸟窝老师这里： https://colobu.com/2021/08/01/benchmark-of-rpc-frameworks/ https://colobu.com/2022/07/31/2022-rpc-frameworks-benchmarks/

nbio 是为了解决 golang 海量连接场景的内存与 GC 压力、以及对应的 OOM 和 STW 问题，暂时算是 golang 社区里功能比较齐全的独一份。

arpc 实现很简单、没费太多精力，但 nbio 花费了太多精力，这几年身体都有点垮了。还想给 nbio 支持 HTTP2.0/QUIC ，但业余时间用爱发电，目前是没精力了，因为实在是太耗精力了。

5 年，40+的年纪，也算是程序员职业生涯末期，秋后的蚂蚱了，给自己留个纪念。

感谢所有我仓库的用户的支持, 感谢所有 issue pr 以及经常交流讨论的朋友们, 我个人精力有限, 大家的关注支持和交流让我的仓库完善了很多!

提前祝大家新年快乐，身体健康，诸事顺遂！

lesismal

225 天前

> 为什么两个加起来一个 issue 都没有？

@stabc
不是一个 issue 都没有, 而是一个 Open 状态的都没有. 兄弟你查 Closed 状态的, 到目前 arpc 有 47 个, nbio 有 242 个.
一个 Open 状态的都没有有两个原因:
1. 作者个人形单影只, 宣传力度不够, 吹个牛说, 虽然功能性能个方面都算是同领域 Top 级的, 但知名度太低, 知道的人少, 来 issue 的人也就少. 看看其他一些同领域的, 功能比这个少, 性能不比这个强, 但是 star 比这多的多, issue 不解决比这多的多
2. 每次有 issue, 作者都尽量迅速答复和解决, 所以除了极个别迷案无果而终, 绝大多数都已经解决了然后就关闭了