在过去的几个月里，我一直在开发 Breeze，这是一个构建在 gnet 之上的网络引擎。
其目标并非创造“另一个 Web 框架”。
其目标是探索事件循环架构在现代 Go 服务中能走多远。
我做出的一些设计决策：
⚡ 事件循环驱动的架构
🌐 原生 HTTP 和 WebSocket 支持
🚀 WebSocket 快速路径（升级后避免经过 HTTP 路由器）
🧵 工作池以保持事件循环的响应性
📦 低分配请求处理
📚 内置 Swagger 支持
🔌 用于实时应用的内置 WebSocket 中心
我特别希望讨论的一个设计选择是，HTTP 和 WebSocket 并未被同等对待。
每个传入的连接都在事件循环内部进行分类。HTTP 请求遵循路由逻辑，而升级后的 WebSocket 连接则直接分派到 WebSocket 引擎。这使得热路径保持精简，并在协议建立后避免不必要的工作。
该项目仍在演进中，在称其为“生产就绪”之前，我正刻意质疑每一个架构决策。
我真诚地感谢拥有以下经验的开发者提供的反馈：
高并发 Go 服务器
gnet 或事件循环架构
大规模 WebSocket 系统
低延迟后端服务
代码仓库：
https://github.com/nelthaarion/breeze
文档：
https://nelthaarion.github.io/breeze
我尤其想了解你会做出哪些改变。架构讨论往往比基准测试数据更有价值。
乐意回答任何问题或深入探讨实现细节。🚀
免责声明：本文内容来自互联网，该文观点不代表本站观点。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌抄袭侵权/违法违规的内容，请到页面底部单击反馈，一经查实，本站将立刻删除。
