PGO 项目初衷：我的微服务学习之路

缘起：为什么要“造轮子”？

这个项目对于整个开源世界而言，本质上当然也是在“造轮子”。 市面上已经有无数成熟、强大、性能卓越的 Go 语言微服务框架，为什么我还要写一个 PGO？

不过，对于我个人而言，这件事情还是很有意义的。 它不仅仅是一个工具库，更是我技术成长的见证。这个项目，更多的其实是在记录这些学习过程，以及作为我自己的学习成果而存在的。 这个“轮子”，不管从性能上还是代码的优雅上，从来没有想过要去跟其他成熟框架做比较。

框架的选择：为什么是 Kratos？

在开始之前，我试用过一些“功能丰富的”框架。 相比之下，我最终用于实际开发的是 Kratos。

原因是其设计理念更符合我所需要的。下面这段话可以在 Kratos 的官方文档中找到：

“Kratos 更类似于一个使用 Go 构建微服务的工具箱，开发者可以按照自己的习惯选用或定制其中的组件，来打造自己的微服务。”

灵活性与成长的空间

一些框架可能会要求“当你需要使用 A 功能时，你必须配套使用 B 模块”。 比起这种“强绑定”的限制，Kratos 提供了很好的灵活性。

在我还没有了解足够多的技术细节时，它允许我搭建出“简单够用”而又留有“足够上限”的“自己的框架”。 并且随着项目的发展，当我逐步添加其他特性（如链路追踪、监控、服务发现）到“自己的框架”中时，Kratos 也带给我非常好的体验。

所谓的“体验”来自于其配合我自己学习的路径：先学习相关知识，然后在 Kratos 中找到实现的方式，最后封装进 PGO。

一个反例

举个反例来说明一下，某些其他框架可能会： 提供了自己封装的一套接口，该接口内部基于更加基础的库，实现了经典的参数设置和提供了更加完善的管理机制， 比如 MySQL 的连接数管理，以及重连机制等等。而调用者只需要一个简单的 Init 函数即可。

这并没有什么不好，工业级的框架理应如此方便。而本项目（PGO）也在做同样的事情。 我想表达的是，Kratos 是我学习路上很好的伴侣，它没有剥夺我探索底层实现的机会，而是提供了积木让我自己搭建。

PGO 的定位：中间层

也可以认为这个项目的定位是“开源框架”和“实际业务代码”中间的一层“中间框架”。

[ 业务逻辑代码 ]
      |
      v
[   PGO (中间层)   ]  <-- 本项目
      |
      v
[ 开源框架 (Kratos/Zap/Gorm...) ]

这种分层设计带来了意想不到的好处。 我也确实成功在“不用大范围修改业务代码”的情况下，更改过一次底层的“开源框架”，从一开始纯粹手敲的“简陋框架”更换到 Kratos。 并且现在看来，如果要更换成其他框架，业务代码也并不需要“大范围修改”。

核心模块概览

PGO 包含了我对微服务开发中常见问题的思考和封装（初步设想，后续扩展不再更新文章了）：

• Context (上下文): 解决了在业务代码中透传 trace_id、user_id 等信息的繁琐问题，在标准库 Context 和开发便捷性之间寻找平衡。
• Log (日志): 基于 Zap 进行了封装，统一了日志格式，使其更符合业务查询和分析的需求。
• Config (配置): 简化了配置文件的加载和读取，支持多环境配置。
• JWT (认证): 梳理了 Authorization、Authentication 等概念，提供了一套简单的认证实现。

结语

PGO 是我学习 Go 微服务架构的一个缩影。它可能不完美，但它足够真实，也足够实用（至少对我而言）。