Kitex 接口开发流程

一次 RPC 怎样到达业务函数？

业务代码
  → Client middleware（日志/超时/重试等横切逻辑）
  → 服务发现 + 负载均衡（选一个实例）
  → 序列化 + 传输（把结构体变成字节并送上网）
  → Server 接收
  → Server middleware
  → Handler（你的业务函数）
  → 原路返回响应

开发链路中的对象如何分工？

对象	承担的职责	继续学习
IDL / 生成代码	定义契约并生成类型、编解码和调用桩	代码生成
Handler / Server	实现方法并接收 RPC	服务端
Client	按契约调用远端方法	客户端
Option / Suite	在明确作用域配置行为	配置体系
Middleware	在业务前后执行公共逻辑	服务端

如何完成一个 Kitex 接口的开发？

• 第一步: 用 Thrift 或 proto3 写 IDL，定义 service、method、请求和响应;
• 第二步: 用 kitex 命令生成 kitex_gen 桩代码;
• 第三步: 服务端实现 Handler，用 NewServer 启动;
• 第四步: 客户端用 NewClient 创建可复用 Client，然后调用方法;
• 第五步: 按生产需要配置寻址、超时、重试、熔断和可观测性;

如何找到适合当前接口的通信方案？

• 契约选择: Thrift 与 proto3 的生成前提见 IDL;
• 协议选择: 编码相同不代表网络互通，比较 传输与序列化协议;
• 持续收发: 按 StreamX 选择流的方向;
• 动态接口: 网关或测试平台运行时才知道方法时，参见 泛化调用;
• HTTP 边界: 对外 HTTP API 通常由 Hertz 承载，再调用内部 Kitex 服务;