系统架构 · 常见架构模式

场景 1 · 32 个服务的接入统一到 APISIX: 路由 / 限流 / 灰度一处搞定

以前每个服务自带一份 nginx + 各自限流, 出入口策略对不齐。网关统一后, 南北向策略一处声明、全站生效。

# APISIX 路由: 认证、限流、灰度在网关一层做完, 微服务只管业务
routes:
- uri: /api/orders/*
  upstream_id: orders-upstream
  plugins:
    jwt-auth: {}                 # 验签失败 → 401, 流量不进业务
    limit-req:
      rate: 500                  # 令牌桶平滑速率 (r/s)
      burst: 200                 # 允许 200 瞬时突发
      key_type: var
      key: remote_addr
      rejected_code: 429         # 超限明说, 别装死
# upstreams:
# - id: orders-upstream
#   nodes: {"10.0.0.1:8080": 95, "10.0.0.9:8080": 5}   # 5% 灰度 v2

新服务接入从"改 5 处配置"变成"加一条路由", 出入口策略首次有了单一事实源。

场景 2 · 商品详情读 QPS 是写的 400 倍: MySQL 写 + ES 读的 CQRS 落地

写走 MySQL 保事务与不变式, 查走 ES 支撑多条件聚合搜索; 中间用 binlog 变更做投影, 写侧是唯一写入点。

# 投影链路: MySQL binlog → Kafka → indexer → ES (写 MySQL 是唯一写入点)
# 1) MySQL binlog ROW 格式; 2) Canal/Debezium 订阅变更投 product.changes
# 3) indexer 消费并物化宽表:
PUT product_view
{ "mappings": { "properties": {
    "title":    { "type": "text", "analyzer": "ik_max_word" },
    "price":    { "type": "scaled_float", "scaling_factor": 100 },
    "sales_7d": { "type": "integer" } } } }
# 关键: 改索引结构不用停写 — 投影只是变更的另一种物化, 删了重建即可

详情页聚合查询 P99 从 MySQL 的 1.2s 降到 ES 的 45ms, 写侧零改动。

场景 3 · 银行对账要"任意时刻账户状态": 事件溯源重建聚合

可疑交易要回放案发时刻的余额——当前状态表做不到, 事件日志一行 fold 就出来。

type Event struct {
    At     time.Time
    Kind   string  // open | deposit | withdraw | fee | refund
    Amount int64   // 分
}

// 重建任意时点 t 的余额: 只回放 At <= t 的事件 (日志按时间有序)
func balanceAt(events []Event, t time.Time) int64 {
    var bal int64
    for _, e := range events {
        if e.At.After(t) { break }  // 越过时点即停
        switch e.Kind {
        case "withdraw", "fee":
            bal -= e.Amount
        default:
            bal += e.Amount
        }
    }
    return bal  // → balanceAt(23:59:59) = 案发前一秒的精确余额
}

审计与合规直接复用这条路径: 任意时点、任意账户, 秒级出账。

场景 4 · 跨境单 Saga: 订单-库存-支付三步, 失败自动逆向退款

分布式大事务拆成三个本地事务, 每步必配补偿; 编排器落库 saga_log, 卡住的流程可人工接管。

// 编排式 Saga: 步骤表驱动, 每步必配补偿(补偿必须幂等)
var flow = []Step{
    {"create_order", createOrder, cancelOrder},
    {"hold_stock",   holdStock,   releaseStock},
    {"charge_usd",   chargeUSD,   refundUSD},
}
func (s *Orchestrator) Run(ctx context.Context, o *OrderCtx) error {
    for i, st := range flow {
        if err := st.Do(ctx, o); err != nil {
            for j := i - 1; j >= 0; j-- {       // 逆序补偿
                _ = flow[j].Undo(ctx, o)      // 补偿失败进死信, 人工接管
            }
            return fmt.Errorf("saga failed at %s: %w", st.Name, err)
        }
        s.log.Step(o.ID, st.Name, "done")     // saga_log 落库, 全程可观测
    }
    return nil
}

上线后"卡单"从每天 40+ 笔人工处理降到个位数, 且每一笔都能查到停在哪个补偿。

场景 5 · App 首页一屏要调 4 个接口: BFF + GraphQL 一次聚合

移动端弱网 4 次 RTT 才能凑齐一屏。App-BFF 聚合并裁剪字段, 响应从 38KB 瘦到 6KB。

# App-BFF: 首页聚合 订单/用户/物流/推荐 四个域, 一次 RTT
query HomePage($uid: ID!) {
  user(id: $uid) { nickname avatarUrl }          # 裁剪: 不要 email/birth
  pendingOrders(uid: $uid, limit: 3) { id amount }
  shipmentTrace(uid: $uid) { carrier eta }
  feed(limit: 10) { skuId title price }          # 推荐只要展示字段
}
# 各解析器并发取数, 总耗时 ≈ max(四个下游) 而非求和
# 上线后: 首页请求数 4→1, P75 首屏耗时 1.9s → 0.8s

场景 6 · 库存服务一抖全站陪葬? Sidecar 接管重试 / 熔断, 业务零代码

手写的 retry 库各服务一份、行为不一致。下沉到 Istio 数据面, Go 代码里删掉所有 retry。

# Istio: DestinationRule 熔断 + VirtualService 重试 (数据面生效)
apiVersion: networking.istio.io/v1beta1
kind: DestinationRule
metadata: {name: stock, namespace: prod}
spec:
  host: stock.prod.svc.cluster.local
  trafficPolicy:
    connectionPool:
      http: {http1MaxPendingRequests: 200}
    outlierDetection:              # 连续 5xx 的实例踢出去 30s
      consecutive5xxErrors: 5
      interval: 10s
      baseEjectionTime: 30s
---
apiVersion: networking.istio.io/v1beta1
kind: VirtualService
metadata: {name: stock, namespace: prod}
spec:
  http:
  - retries: {attempts: 2, perTryTimeout: 300ms, retryOn: "connect-failure"}
    timeout: 1s

库存抖动时上游只慢 1s 就快速失败, 线程池不再被拖满, 故障半径锁回库存服务自己。

场景 7 · 第三方支付 SDK 一年改三次, 领域层零改动: 六边形防腐层

领域服务直接 import Stripe SDK, 升级一次改一片。收进 adapter 后, SDK 怪癖再也出不了这层。

// Port: 领域层定义, 不 import 任何第三方包
type PaymentGateway interface {
    Charge(ctx context.Context, p Payment) (TxnID, error)
}

// Adapter: 包住 StripeSDK 的所有怪癖, 领域层看不见
type stripeAdapter struct{ cli *stripe.Client }

func (a *stripeAdapter) Charge(ctx context.Context, p Payment) (TxnID, error) {
    ch, err := a.cli.PaymentIntents.Create(&stripe.PaymentIntentParams{
        Amount:   stripe.Int64(p.Cents),       // 单位换算在 adapter 内消化
        Currency: stripe.String(p.Currency),
    })
    if err != nil { return "", translateErr(err) } // SDK 错误 → 领域错误
    return TxnID(ch.ID), nil
}
// 换 PayPal: 新写 paypalAdapter, 领域服务一行不改

场景 8 · 20 人团队的仓库系统: 模块化单体先行, 半年后拆服务毫不费力

没追微服务风潮, 先用 Go 的包边界练内功——拆分当天只是把 internal/orders 挪进独立 main.go。

// 目录即边界: 跨模块只许 import 对方根包的 Service 接口
/internal
  /orders    orders.Service   // 对外接口 + DTO
    /repo     (私有; 别的模块 import 会被 CI 门禁直接拦下)
  /billing   billing.Service
  /shipping  shipping.Service
// 迁移日: internal/orders 原样搬进独立仓库, 接口换成 gRPC 定义
// 关键: 模块间"编译期强边界"是拆服务的全部前置条件

半年后按业务需要拆出物流服务, 因为边界早已清晰, 迁移只花了三天。

场景 9 · 报表导出一个月加三种格式: 注册表插件化, 核心零改动

导出格式从 CSV 长到 Excel / PDF / Parquet, 每次都改核心 if-else。抽成注册表后, 新格式 = 一个新文件。

// 扩展点: 核心只认 Exporter 接口 + 注册表
type Exporter interface {
    ContentType() string
    Write(w io.Writer, rows <-chan Row) error
}
var registry = map[string]Exporter{}          // 格式名 → 实现

func Register(name string, e Exporter) {      // 各插件 init() 里自注册
    if _, dup := registry[name]; dup { panic("exporter dup: " + name) }
    registry[name] = e
}
// 新增 parquet = 新文件 parquet.go + init(){Register("parquet",...)}
// 核心路由代码从上线那天起没再改过一行

场景 10 · "订单"到底归谁管? DDD 限界上下文定服务边界

交易、物流、售后都要"订单", 却要完全不同的字段与生命周期——按上下文拆库拆服务, 跨上下文靠 ID 引用 + 事件同步。

-- 同一个词, 两个上下文两张表, 字段互不迁就
CREATE TABLE trading.orders (
  id BIGINT PRIMARY KEY, buyer_id BIGINT,
  amount_cents INT, pay_status VARCHAR(16)   -- 交易关心钱
);
CREATE TABLE logistics.orders (
  id BIGINT PRIMARY KEY, trading_order_id BIGINT,
  receiver_addr VARCHAR(256), parcels INT     -- 物流关心地址件数
);
-- 交易下单成功 → OrderPaid 事件 → 物流上下文落自己的表
-- 关键: 服务边界 = 上下文边界, 不存在"一张大订单表管所有业务"

此后"改物流字段要过交易团队评审"的事故再没发生过——两个上下文各自发布。