Weave中的GitOps:API网关与gRPC生成 - 第二部分

作者:API传播员 · 2025-12-13 · 阅读时间:5分钟

在本文的第1部分中,我们详细介绍了如何构建自动生成的 API 网关。本篇文章将进一步探讨自定义协议生成器 protocol-gen-weave-go 的工作原理,以及它如何与内部包 wgateway 协作,将 API 网关的各个部分整合在一起。

我们将通过 API 网关公开服务,这些服务在集中式原型存储库中被定义为“模式”。在本文中,我们将继续使用“模式”这一术语。


快速回顾

如果您需要更深入地了解如何设置 API 网关和 gRPC 生成系统,请参考本文的第1部分。


架构路由

集中式“架构”存储库以 protobuf 格式存储所有 API 规范。我们在 weave/schemas 目录中设置了 API 网关 URL 的根路径。例如,以下目录结构展示了如何通过 API 网关访问服务:

# API 网关根部
└── 功能标志
├── v1
│ └── feature-flags.proto
└── v2
└── feature-flags.proto

在这种情况下,API 可以通过以下路径访问:

  • <API-gateway-domain>/feature-flags
  • <API-gateway-domain>/feature-flags/v2

自动生成的内容

对于每个模式,当提交被推送到模式存储库时,以下内容会自动生成:

模式
└── 特征标志
└── v2
└── 网关
├── main.go
├── feature_flags.pb.client.go
├── feature_flags.pb.client.mock.go
├── feature_flags.pb.client.mock_test.go
├── feature_flags.pb.go
├── feature_flags.pb.gw.go
├── feature_flags.pb.server.go
├── feature_flags.pb.server.mock.go
├── feature_flags.pb.validate.go
├── feature_flags_grpc.pb.go
├── gateway.pb.go
└── metadata.yaml

其中,以下文件是由自定义插件 protocol-gen-weave-go 生成的:

  • feature_flags.pb.client.go
  • feature_flags.pb.client.mock.go
  • feature_flags.pb.client.mock_test.go
  • feature_flags.pb.server.go
  • gateway.pb.go

这些文件主要通过 Go 模板生成,模板中填充了从 protobuf 文件解析的数据。例如,以下是生成 feature_flags.pb.client.go 文件的 Go 模板示例:

package {{.Package}}

import (
    "context"
    "google.golang.org/grpc"
)// ConvenienceClient 封装了 {{.Service.Name}}Client,允许方法重载
type ConvenienceClient struct {
    {{.Service.Name}}Client
    conn *grpc.ClientConn
}// NewClient 初始化一个新的 ConvenienceClient
func NewClient(ctx context.Context) (*ConvenienceClient, error) {
    // 初始化 gRPC 连接
    return &ConvenienceClient{
        {{.Service.Name}}Client: new{{.Service.Name}}Client(conn),
        conn: conn,
    }, nil
}// Close 关闭底层 gRPC 客户端连接
func (c *ConvenienceClient) Close() error {
    return c.conn.Close()
}

通过这种方式,基础设施中的任何服务都可以通过简单地导入自动生成的包并调用其 NewClient 函数来与其他服务通信。


生成的网关文件

生成的 gateway.pb.go 文件是整个系统的核心,它将所有生成的 Go 代码与 protobuf 文件中的路由和自定义选项联系在一起。以下是文件的主要组成部分:

  • 端口地址
  • 特定编组功能
  • 中间件
  • runtime.ServeMux 选项
  • gRPC 拦截器及拨号选项
  • 每个端点的身份验证及 ACL

这些功能大部分通过 protobuf 声明中的自定义选项支持。下面我们将详细探讨网关的初始化和路由配置。

网关初始化

wgateway.Gateway 提供了一种类型,用于配置和运行服务的 gRPC 网关代理。无论是作为 sidecar 部署,还是直接运行在主应用程序容器中,初始化方式都是一致的。

以下是生成的 NewGateway 函数的主要逻辑:

  1. 使用提供的选项初始化网关。
  2. 向网关注册所有路由。

自定义选项

自定义选项用于配置非路由相关的功能。例如,在 feature-flags 服务中,我们可以指定以下选项:

  • 使用 auth-api 客户端进行身份验证。
  • 设置 Okta 身份验证客户端。
  • 配置运行时编组器。

路由配置

生成的网关文件会将 protobuf 文件中的所有路由与自定义选项关联起来,并为每个路径添加 CORS 预检路由。支持的自定义选项包括:

  • 身份验证类型
  • 特定 ACL
  • 预定义中间件

运行网关

一旦 wgateway.Gateway 被初始化,就可以运行网关。运行方式包括:

  1. 初始化 gRPC 客户端连接。
  2. 注册 HTTP 处理程序。
  3. 启动服务器。

无论是作为 sidecar 部署,还是直接运行在主应用程序中,运行逻辑都是相同的。


总结

我们构建了一套世界级的模式优先生成管道,极大地简化了工程师的工作。他们只需专注于定义 protobuf 文件和 API 合同,其余的工作由 DevX 团队完成,包括代码生成和 Docker 容器构建。

希望本文能为您提供启发,帮助您在公司内部构建类似的系统。

原文链接: https://engineering.getweave.com/post/api-gateway-and-grpc-generation-2/