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

转发自互联网 分享一个自己刚优化的极简版的代码规范，生成代码的质量很相当不错 开发规范 【代码生成原则（按优先级）】 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 方法中： QueryDataSource func(ctx context.Context, id int) (*DataSource, error) dubbo:"queryDataSource" 根本原因是类型不匹配：在 Go 中，int 和 int64 通常都是 8 字节，而在 Java 中，int 类型只有 4 字节。 这种差异导致 Java 无法正确识别要调用的方法。 解决方案： 将 Go 方法中的 int 参数更改为 int32。 QueryDataSource func(ctx context.Context, id int32) (*DataSource, error) dubbo:"queryDataSource" 这个修改应该能解决类型兼容性问题。 Go 中的枚举表示...

issue 关联 先查出可以清理的数据 按索引删除数据 给delete加上limit 查询代码后发现，在 tcc-fence 模式下并不存在自动删除日志的功能，于是准备实现该功能。 pull request 1. 配置文件 在 config 模块中新增了 Config 结构体，用于配置 TCC Fence 日志清理功能的相关参数。 type Config struct { Enable bool `yaml:"enable" json:"enable" koanf:"enable"` Url string `yaml:"url" json:"url" koanf:"url"` LogTableName string `yaml:"log-table-name" json:"log-table-name" koanf:"log-table-name"` CleanPeriod time.Duration `yaml:"clean-period" json:"clean-period" koanf:"clean-period"` } Enable: 是否启用日志清理功能。 Url: 数据库连接字符串。 LogTableName: TCC 日志表的名称。 CleanPeriod: 清理任务的执行周期。 2. 初始化函数 在客户端的 InitTCC 函数中添加了对 fence 的初始化逻辑。 func InitTCC(cfg fence.Config) { fence.InitFenceConfig(cfg) rm.GetRmCacheInstance().RegisterResourceManager(GetTCCResourceManagerInstance()) } 3. 配置初始化 在 InitFenceConfig 函数中，根据配置参数初始化相关组件，并启动清理任务。...

issue 关联 client: dubbo-go: v3.2.0-rc2 server: dubbo v3.3.0 registry: zookeeper 问题 1：biStream 客户端没有关闭长连接的接口；如果服务端不调用 onCompleted，那么 Receive 会永久 block 客户端应当具有主动 Close 能力才对，底层使用的是 grpc，而 grpc 客户端是能够主动关闭连接的。 问题 2：Java 服务端调用 onCompleted() 后，biStream.Receive 返回 EOF 但是和服务端的 TCP 连接仍然存在；我知道 dubbo client 内部是连接池，但是我测试了一下，TCP 连接似乎并没有被复用 源码分析 func TestBiDiStream2(svc greet.GreetService) error { fmt.Printf("start to test triple bidi stream 2\n") stream, err := svc.GreetStream(context.Background()) if err != nil { return err } if sendErr := stream.Send(&greet.GreetStreamRequest{Name: "stream client!"}); sendErr != nil { return err } resp, err := stream....