API网关后端云原生【免费下载链接】tykOpen Source API and AI Gateway supporting REST, GraphQL, TCP, gRPC and MCP (Model Context Protocol)项目地址https://gitcode.com/gh_mirrors/ty/tyk点击查看免费下载本文以 Tyk 开源仓库 coprocess/grpc/README.md 为主体结合 proto 定义、配置结构 与测试用例系统讲解如何通过 gRPC 后端为 Tyk API 网关编写中间件请求预处理、后处理、响应改写以及自定义认证逻辑。读完本文你将掌握 Tyk Coprocess gRPC 的完整工作流程、tyk.conf与 API 定义中的全部关键配置项并能基于 Ruby / Python / Java / C 等任意受支持语言实现自己的 gRPC Dispatcher 服务。Coprocess gRPC 是什么把中间件逻辑搬到独立的 gRPC 服务中Tyk 的 Coprocess协同进程特性允许开发者用自己熟悉的语言编写网关中间件而 gRPC 是其中最灵活的接入方式之一。gRPC 基于 Protocol Buffersprotobuf官方支持 C、Java、Python、Go、Ruby、C#、Node.js、Objective-C、PHP 等多种语言这意味着你可以复用团队已有的技术栈来实现网关逻辑。Tyk Coprocess 同样基于 Protocol Buffers 来派发消息主要是请求与事件因此可以很自然地与同样基于 protobuf 的 gRPC 服务对接。整个接入契约由仓库中的 coprocess_object.proto 定义核心是一个名为Dispatcher的 gRPC 服务service Dispatcher { rpc Dispatch (Object) returns (Object) {} rpc DispatchEvent (Event) returns (EventReply) {} }Dispatch接收 Tyk 网关传入的Object封装请求、会话、元数据等信息经你的中间件逻辑处理后返回ObjectDispatchEvent接收Event事件以 JSON 字符串承载用于处理 Tyk 事件系统派发的事件。从源码结构看Dispatcher接口的实现类由各语言的生成代码提供见 bindings 目录 中的 Java、Python、Ruby、C 等绑定Tyk 网关侧则通过coprocess.RegisterDispatcherServer等调用与之建立连接见 coprocess_grpc.pb.go。工作原理Tyk 启动即连接请求逐条派发一个最简单的 gRPC 后端使用场景如下你使用 Tyk 提供的 protobuf 定义用任意受支持语言编写一个 gRPC serverTyk 启动时根据全局配置连接到这个 gRPC server连接方式可以是本地的 UNIX socket也可以是网络上的 TCP 连接每当 Tyk 网关收到一个请求就会向你的 gRPC server 发起一次Dispatch调用你的 gRPC server 负责完成实际的中间件任务——例如请求转换、响应改写甚至是认证Authentication。这个“网关 ↔ gRPC 后端”之间的一问一答模型让 Tyk 只负责路由、限流、配额等网关本职工作而把业务相关、语言相关的自定义逻辑完全交给外部服务实现。全局配置在 tyk.conf 中启用 Coprocess 并指定 gRPC 地址以下tyk.conf配置片段完成两件事启用 Coprocess 特性、声明 gRPC server 地址。它是运行 gRPC 插件的必需前提coprocess_options: { enable_coprocess: true, coprocess_grpc_server: tcp://127.0.0.1:5555 }, enable_bundle_downloader: true, bundle_base_url: http://my-bundle-server.com/bundles/, public_key_path: /path/to/my/pubkey各字段说明如下配置项含义enable_coprocess启用 rich plugins富插件特性gRPC 与 Python 插件均依赖它coprocess_grpc_servergRPC server 的主机地址仅使用 gRPC 插件时需要示例中的tcp://前缀表示 TCP 连接也可使用 UNIX socketenable_bundle_downloader启用 bundle 下载器用于从远端拉取插件 bundlebundle_base_url下载 bundle 的基础 URL若 API 设置中指定了test-bundleTyk 会请求http://my-bundle-server.com/bundles/test-bundlepublic_key_path用于校验签名 bundle 的公钥路径如果使用未签名 bundle 可省略在仓库源码中上述coprocess_options对应 config/config.go 中的CoProcessConfig结构体除文档列出的字段外还包含以下可供参考的扩展配置配置项JSON对应结构体字段含义grpc_recv_max_sizeGRPCRecvMaxSize从 gRPC server 接收消息的最大字节数grpc_send_max_sizeGRPCSendMaxSize发送给 gRPC server 消息的最大字节数grpc_authorityGRPCAuthoritygRPC 连接中使用的 authority 值grpc_round_robin_load_balancingGRPCRoundRobinLoadBalancing启用 gRPC 服务的轮询负载均衡此时coprocess_grpc_server需使用dns:///协议提供负载均衡服务地址测试代码 services_test.go 展示了这些参数的典型取值如grpc_recv_max_size/grpc_send_max_size设为100000000、grpc_authority设为localhost并演示了在测试中如何用grpc.MaxRecvMsgSize/grpc.MaxSendMsgSize与网关侧配置保持一致——若消息超过限制请求会失败见下文“消息大小限制”。API 设置通过 custom_middleware 挂载 gRPC 钩子下面这段 API 定义配置会让 Tyk 通过 Coprocess此处driver为grpc来完成 API 认证并挂载一个pre类型的预处理中间件enable_coprocess_auth: true, custom_middleware: { pre: [ { name: MyPreMiddleware, require_session: false } ], auth_check: { name: MyAuthCheck }, driver: grpc }各字段说明字段含义enable_coprocess_auth开启 Coprocess 认证认证逻辑交由插件此处为 gRPC 的auth_check完成custom_middleware.pre预处理钩子数组在请求被发送到上游之前执行name必须与 gRPC server 中实现的方法名一致require_session表示该钩子是否需要会话custom_middleware.auth_check自定义认证钩子name指向 gRPC server 中实现认证的方法custom_middleware.driver插件驱动类型gRPC 插件固定为grpc在测试用例 coprocess_grpc_test.go 中可以看到对应的 Go 结构体等价写法apidef.MiddlewareSection中的Pre、AuthCheck、Driver: apidef.GrpcDriver且测试同时验证了post钩子、response钩子、ID Extractor 与config_data注入等场景可作为完整功能清单参考。除pre、auth_check外Tyk 的custom_middleware还支持post后处理、post_key_auth认证后处理与response响应改写等钩子具体由 coprocess_common.proto 中的HookType枚举定义取值包括Pre、Post、PostKeyAuth、CustomKeyCheck、Response。实现 gRPC 后端以 Ruby 示例为模板仓库在 coprocess/grpc/ruby/sample_server.rb 提供了一个可直接运行的 Ruby 参考实现。它继承自生成的Coprocess::Dispatcher::Service核心是dispatch与dispatch_event两个方法并利用 Ruby 的元编程能力按hook_name动态分发到对应钩子方法class SampleServer Coprocess::Dispatcher::Service def dispatch(coprocess_object, _unused_call) if self.respond_to?(coprocess_object.hook_name) coprocess_object self.send(coprocess_object.hook_name, coprocess_object) else raise Coprocess::Dispatcher::HookNotImplemented end return coprocess_object end def dispatch_event(event_wrapper, _unused_call) event JSON.parse(event_wrapper.payload) puts dispatch_event: #{event} return Coprocess::EventReply.new end end其中MyPreMiddleware演示了 pre 钩子最常见的用途——改写请求头def MyPreMiddleware(coprocess_object) coprocess_object.request.set_headers[rubyheader] rubyvalue return coprocess_object endMyAuthCheck则演示了自定义认证从Authorization头或key参数取 token校验通过后构造并返回一个SessionState会话含rate、per、quota_max等限流/配额字段校验失败则通过return_overrides直接返回 401def MyAuthCheck(coprocess_object) valid_token aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d request_token coprocess_object.request.headers[Authorization] || coprocess_object.request.params[key] if request_token.include?(valid_token) new_session Coprocess::SessionState.new new_session.rate 1000 new_session.per 10 new_session.quota_max 60 new_session.quota_renews 1474057703 new_session.quota_remaining 0 new_session.quota_renewal_rate 120 new_session.expires 1474057703 new_session.last_updated (Time.now.to_i 10).to_s # 仅在创建时设置 new_session.id_extractor_deadline 20 coprocess_object.metadata[token] mytoken coprocess_object.session new_session else coprocess_object.request.return_overrides.response_code 401 coprocess_object.request.return_overrides.response_error Not authorized (gRPC/Ruby middleware) end return coprocess_object endserver 启动代码监听0.0.0.0:5555与tyk.conf中coprocess_grpc_server: tcp://127.0.0.1:5555正好对应s GRPC::RpcServer.new s.add_http2_port(0.0.0.0:5555, :this_port_is_insecure) s.handle(SampleServer) s.run_till_terminated仓库还提供了 Python 参考实现 coprocess/bindings/python/sample_server.py展示了完全相同的模式MyPreMiddleware、MyPostMiddleware、MyAuthCheck与Dispatch/DispatchEvent并演示了用coprocess_object.session.CopyFrom(new_session)将新建会话写回对象。这意味着“按hook_name分发到具体函数”是各语言后端通用的组织方式。消息模型理解 Object、MiniRequestObject 与 SessionState要让 gRPC 后端正确读写数据必须理解Dispatch消息中几个关键结构均由coprocess包定义Objectcoprocess_object.proto是Dispatch的请求/响应载体包含hook_type钩子类型对应HookType枚举hook_name插件名称也就是 API 定义中custom_middleware里填写的钩子名gRPC 后端据此找到处理方法requestMiniRequestObject封装请求的头部、参数、body 与 URLsessionSessionState保存当前 key/用户的信息认证钩子负责创建或填充它metadata动态元数据mapstring, stringspecAPI 定义信息如 APIID、OrgID、config_dataresponseResponseObject响应钩子使用字段可在上游响应返回后修改。MiniRequestObjectcoprocess_mini_request_object.proto是中间件处理请求的核心结构字段非常丰富字段含义headers只读的请求头可读取此前中间件注入的头set_headers要追加到请求中的头部key/value 映射delete_headers要从请求中删除的头部名列表body/raw_body请求体字符串形式与原始请求体字节形式multipart 场景下body为空而raw_body有值url/request_uri请求 URL 与未经处理的原始 URL含查询串params/add_params/delete_params只读的请求参数、要新增的参数、要删除的参数return_overrides直接覆盖响应的结构见下method/scheme请求方法GET/POST…与 URL schemehttp/httpsReturnOverridescoprocess_return_overrides.proto允许插件直接接管 HTTP 响应是“认证失败直接返回 401”这类场景的关键包含response_code状态码、response_error错误消息/响应体、headers响应头、override_error等字段。SessionStatecoprocess_session_state.proto是 Tyk 为每个已认证请求创建并存入 Redis 的会话结构gRPC 插件可以像内置认证机制一样创建它。常用字段包括rate/per限流速率与窗口秒数、quota_max/quota_remaining/quota_renews/quota_renewal_rate配额上限、剩余、续期时间点与续期周期秒数、expireskey 过期时间戳、access_rightsAPI 访问权限映射 APIID 到允许的版本与端点、org_id、metadata会话元数据可被其他中间件读取、tags、alias、id_extractor_deadline自定义认证缓存 key 的过期时间戳、session_lifetime、apply_policies等。事件分发DispatchEvent 与 Tyk 事件系统除请求处理外gRPC 后端还可接收 Tyk 事件。DispatchEvent的入参Event只有一个payload字符串字段承载事件的 JSON 序列化数据返回值EventReply是一个空消息仅表示事件已被处理。Ruby 示例中的实现直接解析 JSON 并打印def dispatch_event(event_wrapper, _unused_call) event JSON.parse(event_wrapper.payload) puts dispatch_event: #{event} return Coprocess::EventReply.new end在测试实现 dispatcher_test.go 中DispatchEvent同样只是返回空的EventReply说明事件处理是“即发即忘”模式插件按需实现自己的事件订阅逻辑即可。源码级验证测试如何覆盖 gRPC 插件的各类行为仓库中的测试不仅验证功能更是理解 gRPC 插件行为的权威参考请求头注入coprocess_grpc_test.go 验证 pre 钩子通过object.Request.SetHeaders注入的头部会出现在最终请求中请求体处理同文件验证了 JSON 与 multipart 两种内容类型下body与raw_body字段的取值规则见 dispatcher_test.go会话元数据贯通post 钩子可从object.Session.Metadata读取会话元数据且object.Metadata与object.Session.Metadata应保持键一致见 dispatcher_test.go响应改写response 钩子通过修改object.Response.RawBody改写上游响应体dispatcher_test.go测试断言最终响应体为newbody自定义认证与会话创建testAuthHook1演示了校验 token、填充object.Metadata[token]、构造含Rate与IdExtractorDeadline的SessionState并回写到object.Session的完整流程dispatcher_test.goID Extractor 开关coprocess_grpc_test.go 验证了启用/禁用 ID Extractor 两种模式下会话 key 的生成差异启用时按提取出的 ID 生成会话禁用时直接以 token 作为会话 keyconfig_data 注入同文件验证config_data是否随spec传入插件ConfigDataDisabled控制开关消息大小限制测试表明 20MB 请求可通过网关与 gRPC server 均将最大消息大小设为 100000000而 150MB 请求会被拒绝返回 500印证了grpc_recv_max_size/grpc_send_max_size的实际影响coprocess_grpc_test.go多认证并存TestGRPC_MultiAuthentication验证了 gRPC 认证钩子与标准 token 认证同时启用时的身份优先级与元数据透传coprocess_grpc_test.go。这些测试均通过 services_test.go 启动真实的 gRPC servergrpc.NewServercoprocess.RegisterDispatcherServer再以真实网关配置加载 API 发起 HTTP 请求端到端验证了整个链路。多语言绑定与原型文件从 protobuf 生成你的服务端代码要编写自己的 gRPC 后端你只需使用 Tyk 的 protobuf 定义生成目标语言的 gRPC 代码。仓库 coprocess/proto 目录下提供了全部原型文件包括coprocess_object.protoDispatcher服务与Object/Event/EventReply消息coprocess_mini_request_object.proto请求对象coprocess_session_state.proto会话对象coprocess_common.protoHookType枚举coprocess_return_overrides.proto响应覆盖结构coprocess_response_object.proto响应对象。同时coprocess/bindings 目录已经内置了 C、Java、Python、Ruby 等语言的生成绑定例如 Java 的DispatcherGrpc.java、Python 的coprocess_object_pb2_grpc.py、Ruby 的dispatcher.rb可直接被各语言项目引用无需自己重新生成。适用前提与限制gRPC 插件依赖tyk.conf中enable_coprocess: true与coprocess_grpc_server两项全局配置且 gRPC server 必须在网关启动时可达Tyk 启动时即建立连接coprocess_grpc_server支持tcp://与 UNIX socket 两种传输方式各钩子对会话的依赖不同require_session控制 pre 钩子是否需要会话认证钩子需要自行创建并返回SessionState否则请求将被拒绝传输消息大小受grpc_recv_max_size/grpc_send_max_size限制超大请求会被网关拒绝具体配置字段的完整取值范围与最新行为建议以 config/config.go 中CoProcessConfig的注释与 coprocess/grpc 目录下测试用例为准。赞分享API网关后端云原生【免费下载链接】tykOpen Source API and AI Gateway supporting REST, GraphQL, TCP, gRPC and MCP (Model Context Protocol)项目地址https://gitcode.com/gh_mirrors/ty/tyk点击查看免费下载相关推荐Tyk Coprocess 插件框架实战使用 Python、Lua 与 gRPC 编写自定义 API 中间件Tyk Coprocess 插件框架实战使用 Python、Lua 与 gRPC 编写自定义 API 中间件 CoprocessCo Process是 TAPI网关后端云原生Pixelle-Video深度解析5大技术优势打造全自动AI短视频创作引擎Pixelle Video深度解析5大技术优势打造全自动AI短视频创作引擎 Pixelle Video是一款开源的AI全自动短视频引擎它正在重新定义内容创作人工智能AI 应用音视频媒体生成Go gRPC中间件终极指南从零开始编写自定义拦截器Go gRPC中间件终极指南从零开始编写自定义拦截器 gRPC作为高性能的RPC框架在Go语言生态中被广泛应用。而中间件拦截器作为gRPC的重要特性能后端微服务可观测性创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
![BenchmarkDotNet 参数化基准：[Params] 特性实现多参数组合测试的完整指南](http://pic.xiahunao.cn/yaotu/BenchmarkDotNet 参数化基准：[Params] 特性实现多参数组合测试的完整指南)
