Plumego：一个回归 Go 本质的极简服务框架

前言：为什么还要再做一个 Go 框架

在 Go 生态已经高度成熟的今天，“再做一个 Go Web 框架” 看起来既多余，又无趣。

我们已经有了：

• 功能极其完备、社区庞大的全栈式框架
• 极致性能导向、偏底层的 HTTP / RPC 框架
• 面向云原生、与 Kubernetes 深度绑定的应用运行时
• 为微服务量身定制的一整套工程体系

Plumego 并不是要和它们竞争。

Plumego 诞生的背景，恰恰来自另一类真实但常被忽视的工程需求：

我们是否还能用 几乎只有 Go 标准库 的方式，构建一个 长期可维护、行为完全可预测、足够优雅 的服务框架？

Plumego 的目标不是“功能最多”，而是：

• 代码能被完整读懂
• 行为能被完全推理
• 架构能被自然演进
• 十年后依然不会成为技术债

如果你正在寻找的是“最后一个你愿意长期维护的 Go 服务骨架”，
那么 Plumego 可能正是你需要的那个选择。

Plumego 是什么

Plumego 是一个基于 Go 标准库构建的极简服务框架。

它并不试图替你做所有事情，而是提供一套稳定、克制、工程化的最小能力集合，帮助你：

• 快速搭建一个可运行的 HTTP 服务
• 明确地组织路由、上下文和中间件
• 在不引入沉重依赖的前提下，构建可扩展的业务结构
• 为未来引入 WebSocket、Webhook、Pub-Sub、JWT、Local DB 等能力预留清晰边界

Plumego 的核心理念可以总结为一句话：

用最少的魔法，换取最大的确定性。

设计哲学：Plumego 坚持的五个原则

1. 标准库优先（Standard Library First）

Plumego 几乎完全构建在 Go 标准库之上：

• net/http
• context
• encoding/json
• sync
• time

这意味着：

• 没有隐藏的行为
• 没有难以升级的第三方核心依赖
• 不会被某个库的设计决策所绑架

你看到的，就是 Go 本身。

2. 结构清晰优于功能堆叠

Plumego 不追求“一行代码搞定一切”。

相反，它更在意：

• 请求从哪里来
• 中间件在什么时候执行
• Context 如何被构建和传递
• Handler 在哪里结束自己的职责

每一个步骤，都是显式的、可跟踪的、可调试的。

3. 行为可预测优于“开发爽感”

很多框架在早期会给你极强的“爽感”：

• 自动注入
• 隐式绑定
• 全局魔法
• 约定优于配置到极致

但 Plumego 更关心的是：

• 一年后你是否还敢改
• 三年后新同事是否能接手
• 线上出问题时是否能快速定位

因此，Plumego 对“隐式行为”保持高度警惕。

4. 框架即骨架，而不是产品

Plumego 本身并不是一个“完成品”。

它更像是：

• 一个可裁剪的工程骨架
• 一套推荐但不强制的组织方式
• 一个可以被复制到多个仓库的起点

你可以在 Plumego 之上构建：

• 内部服务
• 小型 SaaS
• API Gateway
• 游戏后端
• 自动化系统
• 工具型服务

5. 为长期演进而设计

Plumego 的设计天然考虑：

• 模块替换
• 能力下沉
• 服务拆分
• 单体 → 多服务

它不会逼你一开始就“上微服务”，但也不会阻止你未来这样做。

Plumego 的整体架构概览

从宏观上看，一个基于 Plumego 的服务，通常由以下几层组成：

┌──────────────────────────┐
│        HTTP Server       │
│   (net/http 标准库)     │
└──────────┬──────────────┘
│
┌──────────▼──────────────┐
│         Router           │
│   路由匹配与分发层       │
└──────────┬──────────────┘
│
┌──────────▼──────────────┐
│       Middleware         │
│   横切关注点处理         │
└──────────┬──────────────┘
│
┌──────────▼──────────────┐
│        Context           │
│   请求上下文封装         │
└──────────┬──────────────┘
│
┌──────────▼──────────────┐
│        Handler           │
│   业务入口（边界层）     │
└──────────┬──────────────┘
│
┌──────────▼──────────────┐
│      Domain / Usecase    │
│   纯业务逻辑             │
└──────────────────────────┘

Plumego 严格区分：

• 框架层：只负责请求生命周期
• 业务层：不感知 HTTP，不依赖框架

HTTP Server：回归 net/http 的纯粹

Plumego 并没有重新实现一个 HTTP Server。

它直接使用 Go 标准库的 http.Server，并在其之上提供：

• 清晰的启动与关闭流程
• 可控的超时设置
• 显式的 Context 生命周期管理

这意味着你完全可以：

• 接入标准的反向代理（Nginx / Caddy）
• 使用现有的监控与 tracing 方案
• 对行为进行精确调优

Router：不追求花哨，只追求清晰

Plumego 的 Router 设计遵循三个原则：

1. 路由规则必须一眼可读
2. 匹配顺序必须可预测
3. 不隐藏路径解析细节

Plumego 不鼓励复杂的 DSL，而更偏向于：

router.GET("/users/:id", handler)
router.POST("/users", handler)

你知道它是如何工作的，也能在必要时轻松替换。

Middleware：显式、线性、可组合

在 Plumego 中，中间件不是“黑盒”。

它遵循严格的调用顺序：

Request
  → Middleware A
    → Middleware B
      → Handler
    ← Middleware B
  ← Middleware A
Response

典型的中间件包括：

• 日志
• TraceID 注入
• 鉴权
• 限流
• Panic Recovery

每一个中间件都是普通的 Go 函数。

Context：比 net/http 更友好，但不更复杂

Plumego 会在标准 context.Context 之上，封装一层更偏业务友好的 Context：

• 请求信息
• 响应写入
• 常用工具方法
• 统一错误返回

但它不会：

• 隐藏原始 context
• 强制使用全局变量
• 引入难以理解的生命周期规则

Handler：清晰的系统边界

在 Plumego 的理念中，Handler 是：

系统的边界，而不是业务的中心。

Handler 的职责只有三个：

1. 解析输入
2. 调用业务逻辑
3. 构造输出

真正的业务规则，应该存在于：

• Domain
• Usecase
• Service

这使得你的业务代码：

• 可测试
• 可复用
• 可脱离 HTTP 独立运行

为什么 Plumego 特别适合长期项目

如果你符合以下任意一条，Plumego 都非常适合你：

• 你不希望项目被某个框架“锁死”
• 你更看重代码寿命，而不是短期效率
• 你正在构建一个会运行很多年的系统
• 你需要一个可以被复制、裁剪、演进的工程骨架
• 你厌倦了“魔法太多”的框架

Plumego 并不试图取悦所有人。

它只为那些愿意为确定性付出一点显式代码成本的工程师而存在。

Plumego 与 Birdor 的关系

Plumego 是 Birdor 工程体系中的底层服务骨架之一。

在 Birdor 的设计中：

• 前端强调语义化与长期一致性
• 工具强调本地优先、无侵入
• 后端同样追求 冷静、克制、可推理

Plumego 正是这种工程哲学在后端的自然延伸。

结语：Plumego 的真正价值

Plumego 的价值，不在于它“能做什么”。

而在于：

• 它明确不做什么
• 它拒绝哪些诱惑
• 它为未来留下了多少空间

如果你正在寻找的是：

一个不会在三年后被你亲手推翻的 Go 服务框架。

那么，Plumego 值得你认真看一眼。

Plumego is not about speed. It is about trust.