2. Go语言基础回顾

在分布式系统中，跨服务调用是常态。接口（interface）作为 Go 语言中行为抽象的基石，是构建可测试、可扩展业务逻辑的核心工具。本章将系统回顾 Go 接口的定义、使用模式，以及 error 接口与自定义错误的实现，为后续超时与重试机制的落地打下坚实基础。

2.1 接口的定义与核心特性

Go 的接口是隐式实现的：一个类型只要实现了接口中的所有方法，就自动满足该接口，无需显式声明。这种“鸭子类型”风格使得代码耦合度极低，非常适合在业务接口层进行抽象。

2.2 接口的典型使用模式

以下代码展示了一个业务接口的定义、实现与使用，模拟跨服务调用的抽象层：

// 定义业务接口：远程调用器
type Invoker interface {
    Invoke(ctx context.Context, request []byte) (response []byte, err error)
}

// 具体实现：HTTP 调用
type HTTPInvoker struct {
    BaseURL string
    Client  *http.Client
}

func (h *HTTPInvoker) Invoke(ctx context.Context, request []byte) ([]byte, error) {
    req, _ := http.NewRequestWithContext(ctx, "POST", h.BaseURL+"/api", bytes.NewReader(request))
    resp, err := h.Client.Do(req)
    if err != nil {
        return nil, fmt.Errorf("http invoke: %w", err)
    }
    defer resp.Body.Close()
    return io.ReadAll(resp.Body)
}

// 使用：业务逻辑只依赖接口
func BusinessProcess(invoker Invoker, data []byte) error {
    resp, err := invoker.Invoke(context.Background(), data)
    if err != nil {
        return fmt.Errorf("business process failed: %w", err)
    }
    // 处理 resp ...
    return nil
}

2.3 error 接口与自定义错误

Go 的内置 error 是一个极其简洁的接口：

type error interface {
    Error() string
}

任何实现了 Error() string 方法的类型都可以作为错误值。在分布式系统中，错误往往需要携带更多上下文（如状态码、重试标识、根因），因此自定义错误类型是必备技能。

2.3.1 自定义错误类型

// 自定义错误：携带 HTTP 状态码和可重试标识
type HTTPError struct {
    StatusCode int
    Message    string
    Retryable  bool
}

func (e *HTTPError) Error() string {
    return fmt.Sprintf("HTTP %d: %s (retryable=%v)", e.StatusCode, e.Message, e.Retryable)
}

// 使用
func (h *HTTPInvoker) Invoke(ctx context.Context, request []byte) ([]byte, error) {
    // ... 发起请求
    if resp.StatusCode == 503 {
        return nil, &HTTPError{
            StatusCode: 503,
            Message:    "service unavailable",
            Retryable:  true,
        }
    }
    // ...
}

2.3.2 错误包装与 unwrap

Go 1.13 引入的 %w 格式化动词和 errors.Is / errors.As 函数，使得错误链的构建与检查变得标准化：

// 包装错误
func BusinessProcess(invoker Invoker, data []byte) error {
    resp, err := invoker.Invoke(context.Background(), data)
    if err != nil {
        return fmt.Errorf("invoke failed: %w", err) // %w 创建可 unwrap 的错误链
    }
    // ...
    return nil
}

// 检查错误链中的特定类型
var httpErr *HTTPError
if errors.As(err, &httpErr) {
    if httpErr.Retryable {
        // 执行重试逻辑
    }
}

2.4 接口与错误在跨服务调用中的协同

下面的 SVG 图展示了接口、自定义错误与调用方之间的协作关系，这是后续实现超时与重试的架构基础：

2.5 接口设计的最佳实践

1. 小接口原则： 一个接口只包含 1-3 个方法。如 Invoker 只定义 Invoke，便于组合和 mock。
2. 接受接口，返回结构体： 函数参数使用接口，返回值使用具体类型，保持灵活性。
3. 错误类型应携带重试语义： 在分布式系统中，错误应明确标识是否可重试（如 Retryable bool），避免调用方猜测。
4. 使用 errors.As 而非类型断言： 在错误链中检查自定义错误时，优先使用 errors.As，它支持 unwrap 后的多层嵌套。