Skip to content

后端架构与服务治理技术详解


一、架构模式

1.1 分层架构(Layered Architecture)

定义

将系统按职责划分为展示层、业务层、数据层等水平层次,层间依赖单向的架构模式。

解决的问题

  • 代码职责不清
  • 耦合严重
  • 难以测试和维护

典型分层

用户体验层(SSR)

业务边界层(Gateway/BFF)

核心服务层(微服务)

基础设施层(K8s/DB)

1.2 微服务架构(Microservices Architecture)

定义

将单体应用拆分为多个独立部署、独立扩展的小型服务,每个服务负责一个业务能力。

解决的问题

  • 单体应用难以扩展
  • 故障影响全局
  • 技术栈固化

三种实现模式

模式说明
RESTful API模式服务通过API提供,云服务属于这一类
RESTful应用模式通过传统网络协议提供服务,企业内部常见
集中消息模式采用消息代理实现消息队列、负载均衡

1.3 事件驱动架构(Event-Driven Architecture, EDA)

定义

通过异步事件在服务间传递状态变化,实现松耦合通信的架构模式。

解决的问题

  • 同步调用链路长导致超时
  • 服务间强依赖
  • 分布式事务难实现

核心组件

组件职责
事件队列接收事件的入口
分发器将事件分发到不同业务逻辑单元
事件通道分发器与处理器之间的联系渠道
事件处理器实现业务逻辑

二、服务治理

2.1 API Gateway(API网关)

定义

系统的统一入口,负责路由、认证、限流、监控等横切关注点。

解决的问题

  • 前端直连多个微服务导致复杂性高
  • 安全风险大
  • 流量无法统一管控

核心功能

功能说明
路由转发将请求路由到后端服务
认证鉴权统一处理身份验证
限流熔断保护后端服务
协议转换HTTP/gRPC/WebSocket转换
日志审计统一日志记录

常用产品

  • Kong
  • APISIX
  • Spring Cloud Gateway
  • Nginx

2.2 BFF(Backend for Frontend)

定义

为不同前端(Web、Mobile、小程序)定制的轻量聚合层,按前端需求组装数据。

解决的问题

  • 前端直接调用多个微服务导致请求多
  • 数据冗余
  • 网络开销大

架构示意

Web端 → Web BFF → 
                  → 后端微服务群
Mobile端 → Mobile BFF →

效果

一次请求聚合模板、用户、权益等多个服务数据,减少80%的前端请求数。

2.3 gRPC

定义

Google开源的高性能RPC框架,基于HTTP/2和Protocol Buffers,支持多语言。

解决的问题

  • REST/JSON通信性能低
  • 序列化开销大
  • 接口契约不明确

特点

  • 比REST快5-10倍
  • 通过.proto文件定义接口契约
  • 类型安全和自动代码生成

示例

protobuf
syntax = "proto3";

service TemplateService {
  rpc GetTemplate(GetTemplateRequest) returns (Template);
  rpc ListTemplates(ListTemplatesRequest) returns (ListTemplatesResponse);
}

message GetTemplateRequest {
  string template_id = 1;
}

message Template {
  string id = 1;
  string name = 2;
  string category = 3;
}

三、数据一致性

3.1 Outbox Pattern(事务性发件箱模式)

定义

在业务事务中同时写入业务数据和事件到同一数据库,通过后续进程保证事件发布的模式。

解决的问题

  • 分布式事务复杂
  • 本地事务与消息发送无法保证原子性

实现流程

1. 业务操作 + 写入Outbox表(同一事务)

2. CDC工具监听Outbox表变化

3. 事件投递到消息队列

4. 下游服务幂等消费

3.2 CDC(Change Data Capture)

定义

监听数据库变更日志(如MySQL binlog),实时捕获数据变化并发布到下游的技术。

常用工具

  • Debezium
  • Maxwell
  • Canal

架构示例

MySQL (binlog) → Debezium → Kafka → Flink/Spark → 下游系统

3.3 幂等消费(Idempotent Consumer)

定义

消费者处理消息时,保证重复消费同一条消息不会产生副作用的设计。

解决的问题

消息队列至少一次语义导致重复消费引发数据重复或错误。

实现方式

  • 消息ID + 分布式锁
  • 唯一索引去重
  • 状态机控制

四、流量治理

4.1 限流(Rate Limiting)

定义

限制单位时间内请求数量,防止过载的流量控制手段。

常用算法

算法说明
固定窗口每个时间窗口独立计数
滑动窗口平滑限流,避免边界问题
令牌桶允许突发流量,令牌以固定速率生成
漏桶请求以固定速率处理,平滑流量

示例配置

yaml
# Gateway层限流
rate_limit:
  per_ip: 100/s     # 单IP每秒100次
  per_user: 10/min  # 单用户每分钟10次AI调用

4.2 熔断(Circuit Breaker)

定义

当下游服务故障率超过阈值时,自动切断请求,快速失败并返回降级响应的保护机制。

状态机

闭合(Closed) ←→ 开启(Open)
       ↓              ↓
      正常          快速失败
       ↓              ↓
      (故障率↑)    (冷却期后)
       ↓              ↓
    → 半开(Half-Open) ←

       探测请求

    成功率高 → 闭合
    成功率低 → 开启

常用工具

  • Hystrix(已停止维护)
  • Resilience4j
  • Sentinel

4.3 重试与退避

指数退避

第1次重试:等待 100ms
第2次重试:等待 200ms
第3次重试:等待 400ms
第4次重试:等待 800ms(+ 随机抖动)

最佳实践

  • 设置最大重试次数(如3次)
  • 添加随机抖动避免重试风暴
  • 配合幂等性设计

五、领域驱动设计(DDD)

5.1 核心概念

定义

一种软件设计方法论,通过识别业务领域、建立统一语言、划分限界上下文来组织复杂系统。

解决的问题

  • 业务逻辑分散
  • 模型贫血
  • 服务边界模糊

5.2 战术模式

模式说明
聚合根一组相关对象的根实体,保证一致性边界
实体具有唯一标识的对象
值对象无唯一标识,通过属性值定义的对象
领域事件领域中发生的有业务意义的事件
仓储聚合的持久化接口

5.3 限界上下文

用户域          模板域          编辑域
┌─────────┐   ┌─────────┐   ┌─────────┐
│ 用户    │   │ 模板    │   │ 项目    │
│ 账户    │   │ 素材    │   │ 页面    │
│ 权限    │   │ 分类    │   │ 图层    │
└─────────┘   └─────────┘   └─────────┘
     ↓             ↓             ↓
  认证服务      模板服务       编辑服务

六、契约管理

6.1 契约测试(Contract Testing)

定义

验证服务间接口约定(契约)是否被正确实现和遵守的测试方法。

解决的问题

  • 微服务间接口变更导致运行时错误
  • 集成测试成本高

工具

  • Pact
  • Spring Cloud Contract

6.2 API版本管理

策略

策略示例
URL路径/api/v1/templates/api/v2/templates
HeaderAccept-Version: v1
查询参数?version=1

兼容性原则

  • 向后兼容:新版本能处理旧格式请求
  • 向前兼容:旧版本能忽略新字段

七、安全认证

7.1 OAuth2

定义

开放授权标准,允许第三方应用在不获取用户密码的情况下访问用户资源。

授权流程

用户 → 第三方应用 → 授权服务器 → 资源服务器
         ↓              ↓
      授权请求      发放Token
         ↓              ↓
      用户授权    携带Token访问资源

7.2 OIDC(OpenID Connect)

定义

基于OAuth2的身份认证协议,提供标准化的用户身份信息(ID Token)。

7.3 RBAC vs ABAC

特性RBACABAC
定义基于角色的访问控制基于属性的访问控制
粒度角色级别细粒度(用户、资源、环境属性)
示例管理员、编辑、查看者只能访问自己创建的资源
复杂度

7.4 JWT(JSON Web Token)

结构

Header.Payload.Signature

示例:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4ifQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

优势

  • 无需服务端存储会话
  • 支持分布式系统无状态扩展

上次更新:

如有转载或 CV 的请标注本站原文地址