Golang微服务多协议支持的核心是分层解耦与协议适配器模式：业务逻辑通过纯Go接口隔离传输协议，各协议（HTTP/gRPC/WS/MQTT）由独立adapter负责请求解析与响应格式化，共享统一RequestContext和AppError，配置驱动启停，adapter严格限于翻译职责。
用 Golang 实现微服务的多协议支持，核心不是堆砌框架，而是分层解耦 + 协议适配器模式。重点在于让业务逻辑与传输协议（HTTP、gRPC、WebSocket、甚至 MQTT）完全隔离，协议只负责“把请求接进来、把响应送出去”。
统一入口：定义清晰的业务接口
所有协议最终都要调用同一套业务逻辑。先抽象出不依赖任何网络层的 service 接口：
- 例如 UserService 提供
CreateUser(ctx, req) (resp, error)方法，参数和返回值用纯 Go struct，不含 HTTP header、gRPC metadata 等协议相关字段 - 避免在 service 层做 JSON 序列化、status code 设置、中间件拦截等——这些是协议层的事
- 这样后续增删协议（比如加个 WebSocket 订阅用户事件），只需新增 adapter，不用动业务代码
协议适配器：为每种协议写薄薄一层胶水
每个协议对应一个独立的 adapter 包，职责明确：解析入参 → 调用 service → 格式化响应。
-
HTTP adapter：用
net/http或gin/chi，从*http.Request提取 body/query/header → 构造 service 入参；用http.ResponseWriter写状态码和 JSON -
gRPC adapter：实现 .proto 生成的 server interface，把 pb struct 转成 service 所需的 domain struct；错误用
status.Errorf统一转成 gRPC Code -
WebSocket adapter：用
gorilla/websocket，读消息后根据 type 字段路由到对应 service 方法，结果以 JSON 消息推回 client - 关键点：adapter 层不做业务判断，只做“翻译”，且可单独启停（比如临时关闭 gRPC 端点）
共享上下文与错误处理：跨协议一致体验
不同协议对 context 和 error 的表达差异大，需统一收敛：
立即学习“go语言免费学习笔记（深入）”；
- 用自定义
RequestContext封装通用字段（traceID、userID、locale），各 adapter 在接收请求时注入，service 层只认这个 ctx - 定义全局 error 类型（如
AppError），含Code（业务码）、HTTPStatus、GRPCCode；adapter 根据协议选择对应字段映射（HTTP 返回 400，gRPC 返回 InvalidArgument） - 避免在 service 里写
if grpc.IsOK(err) {...}这类协议相关判断
配置驱动协议开关与端口绑定
- YAML 配置示例：
http: { enabled: true, port: 8080 }、grpc: { enabled: true, port: 9000 }、ws: { enabled: false } - 启动时根据配置初始化对应 server，共用同一个 service 实例（非单例，可按需注入依赖）
- 健康检查端点（如
/healthz）建议只走 HTTP，避免协议冗余
基本上就这些。不复杂但容易忽略的是：别让 protocol adapter 变成“万能胶”，它只该有 100 行左右的核心逻辑；一旦发现 adapter 里开始写重试、熔断、鉴权，说明职责越界了——该抽成 middleware 或 service decorator。
