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

By Leeting Yan

前言：为什么还要再做一个 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.