我来到，我看见，我记录。

Go 的一些理解 如何解决循环依赖（Circular Dependency） 什么是循环依赖 package a 导入了 package b package b 又反过来导入了 package a 1 2 3 4 5 6 a.go b.go +--------+ +--------+ | package| --> | package| | a | | b | | | <-- | | +--------+ +--------+ 依赖循环是设计的问题，如果遇到依赖的情况，需要重新思考该如何对项目进行设计。 解决循环依赖 核心思想是 打破循环。Go 社区推崇的最佳实践是利用 接口（Interface） 和 依赖倒置原则（Dependency Inversion Principle, DIP）。 方案一：使用接口（最推荐、最优雅的 “Go Way”） 依赖倒置原则的核心是 “依赖于抽象，而不是依赖于具体实现”。在 Go 中，这个“抽象”就是接口。 方案二：提取公共依赖到新包 如果循环仅仅是因为共享了某个数据结构（struct），那么最简单的办法就是把这个公共的数据结构提取到一个新的、更底层的包里。 警告：不要滥用这个模式，避免创建一个什么都往里扔的“垃圾桶”(common, utils)包。这个新包应该只包含稳定、底层、被广泛依赖的数据结构或常量。 Pixiu 里不是什么东西都能放进 model 和 common 里的，这点需要注意，希望最后不用重构。 ...

1. 引言 本文档旨在探讨在 dubbo-go-pixiu 网关中，基于现有的 Http2ListenerService 实现对原生 gRPC 流式传输（包括客户端流、服务端流和双向流）支持的几种设计方案。核心目标是使 Pixiu 能够接收来自 gRPC 客户端的流式请求，并利用 grpcdynamic 库动态地将这些请求代理到后端的 gRPC 服务。 2. 通用前提与核心组件 在讨论具体方案之前，我们明确以下通用前提和将要使用的核心组件： Listener 配置: Pixiu 网关配置了一个 protocol_type: GRPC 或 protocol_type: HTTP2 的 Listener。这将默认或间接使用 Http2ListenerService (位于 pkg/listener/http2/http2_listener.go) 来处理底层的 HTTP/2 连接。 grpcdynamic 库: 用于在网关内部动态地构建和发送 gRPC 请求到后端服务，以及解析响应，无需预编译的 gRPC Stub。 方法描述符 (desc.MethodDescriptor): 网关需要有能力获取目标后端 gRPC 服务的方法描述符。这可以通过 gRPC 反射机制、在网关加载 .proto 文件或 FileDescriptorSet 文件，或通过其他配置服务来实现。 网络过滤器链 (NetworkFilterChain): 请求在 Http2ListenerService 接收后，会经过此处理链。我们需要在这里集成 gRPC 流处理逻辑。 3. 设计方案嵌入式标准 gRPC 服务器与 grpc.UnknownServiceHandler 3.1. 核心思想 修改 Http2ListenerService，使其内部的 http.Server 的 Handler 直接设置为一个标准的 grpc.Server 实例。这个嵌入的 grpc.Server 利用 grpc.UnknownServiceHandler 选项来捕获所有未在网关显式注册的 gRPC 服务调用，然后在其 Handler 内部使用 grpcdynamic 将这些调用动态代理到后端。 ...

转发自互联网 分享一个自己刚优化的极简版的代码规范，生成代码的质量很相当不错 开发规范 【代码生成原则（按优先级）】 First Principles（第一性原理）：梳理最核心需求与边界 YAGNI：只实现当前真正需要的功能 KISS：保持设计和实现的简单性 SOLID：面向对象/模块化设计时，遵循单一职责、开放封闭等 DRY：消除重复，提炼公用逻辑 根据场景动态调整顺序 架构级／需求分析（Project Kickoff） First Principles → YAGNI → KISS → SOLID → DRY 新功能迭代／增量开发：YAGNI → KISS → SOLID → DRY → First Principles 小函数／工具库实现：KISS → DRY → YAGNI → SOLID → First Principles 复杂业务组件／面向对象建模：First Principles → SOLID → YAGNI → KISS → DRY

Pixiu AI 演进 AI 应用架构新范式 AI 应用架构图 调用链路说明 用户向AI应用发起请求，请求流量进入流量网关（云原生API网关）。 云原生API网关侧维护管理了不同类型的AI Agent的API或路由规则，将用户请求转发至对应的AI Agent。（可以考虑接入 A2A 协议） AI Agent无论以哪种方式实现，只要其中的节点需要获取数据，便向MCP网关（云原生API网关）请求获取可用的MCP Server及MCP Tool的信息。 因为MCP网关处可能维护了很多MCP信息，可以借助LLM缩小MCP范围，减少Token消耗，所以向AI网关（云原生API网关）发请求和LLM交互。（这一步可选） MCP网关将确定好范围的MCPServer及MCP Tool的信息List返回给AIAgent。 AI Agent将用户的请求信息及从MCP网关拿到的所有MCP信息通过AI网关发送给LLM。 经过LLM推理后，返回解决问题的唯一MCP Server和MCP Tool信息。 AI Agent拿到确定的MCP Server和MCP Tool信息后通过MCP网关对该MCP Tool做请求。 实际生产中 ③-⑧ 步会多次循环交互 云原生 API 网关 [!注释] 南北走向流量为 client-server 的流量 东西走向流量为 server-sever 流量 Web Application Firewall，Web应用防火墙，简称WAF 传统的流量网关和 API 网关集成的微服务网关（SpringCloud Gateway）注重于同 k8s 中的 Pod 进行交互，有东西走向流量和南北走向流量。 而新一代网关 增加了AI 流程的同时，有如下特点 流量网关、API网关，微服务网关、AI网关、MCP网关多合一 统一东西南北向流量 集成 WAF ，内容安全数据面 集成 AI 领域 LLM，MCP 差异化竞争力：服务治理、API管理、LLM管理、MCP管理 + 基本竞争力：高性能、高可用、零信任、易扩展 ...

issue 关联 Environment Server: Java-server, dubbo version v3.0.14 Client: Dubbo-go, v3.1.1 Protocol: Dubbo Registry: Nacos, v2.1.2 Problem dubbo-go 的 client 端无法调用 dubbo 的 server 端的代码。 问题分析 在调试并复现代码问题后，我发现问题出在 QueryDataSource 方法中： 1 QueryDataSource func(ctx context.Context, id int) (*DataSource, error) dubbo:"queryDataSource" 根本原因是类型不匹配：在 Go 中，int 和 int64 通常都是 8 字节，而在 Java 中，int 类型只有 4 字节。 这种差异导致 Java 无法正确识别要调用的方法。 解决方案： 将 Go 方法中的 int 参数更改为 int32。 1 QueryDataSource func(ctx context.Context, id int32) (*DataSource, error) dubbo:"queryDataSource" 这个修改应该能解决类型兼容性问题。 Go 中的枚举表示 我注意到您定义的 Java 枚举类型在 Go 中表示为字符串： 1 Type string hessian:"type" // Mapped from Java enum 为了解决这个问题并确保在 Go 中正确处理枚举，我建议使用 dubbo-go-hessian2 仓库中提供的枚举生成工具。 ...