架构 on PlumePHP

架构评审与技术债管理

Thu, 13 Aug 2026 02:00:00 +0800

架构评审与技术债管理

架构不是一次性的设计，而是持续演进的过程。架构评审与技术债管理是保障系统长期健康的关键实践。

1. 架构评审方法

ATAM（Architecture Tradeoff Analysis Method）

卡内基梅隆大学提出的结构化评审方法：

SLA/SLO/SLI 与容量规划

Thu, 13 Aug 2026 01:55:00 +0800

SLA/SLO/SLI 与容量规划

SRE 的核心是量化可靠性。SLA/SLO/SLI 定义了"多可靠算足够可靠"，容量规划确保资源满足这些目标。

1. 定义区分

缩写	全称	含义	示例
SLI	Service Level Indicator	服务质量指标	请求延迟 P99 < 200ms
SLO	Service Level Objective	目标值	99.9% 的请求延迟 < 200ms
SLA	Service Level Agreement	服务等级协议（对外承诺）	可用性 < 99.9% 退款 10%

SLI: 测量什么
↓
SLO: 目标值多少
↓
SLA: 达不到的后果（法务/商务）

2. SLI 选择

Google SRE Book 推荐的 SLI 类型：

云原生架构模式

Thu, 13 Aug 2026 01:50:00 +0800

云原生架构模式

云原生（Cloud Native）是一套技术体系与方法论，旨在充分利用云计算的弹性、分布式与自动化能力。Sidecar、Service Mesh、Serverless、GitOps 是其核心模式。

CQRS 与事件溯源

Thu, 13 Aug 2026 01:45:00 +0800

CQRS 与事件溯源

CQRS（Command Query Responsibility Segregation）将读写操作分离，事件溯源以事件序列替代状态快照。两者常结合使用，解决高并发读写冲突。

消息驱动架构（EDA）

Thu, 13 Aug 2026 01:40:00 +0800

消息驱动架构（EDA）

事件驱动架构（Event-Driven Architecture）通过事件的发布与订阅实现服务解耦，是微服务异步协作的核心模式。

1. 核心模式

事件通知

Service A ──(Event)──→ Event Bus ──(Fan-out)──→ Service B
 ──→ Service C
 ──→ Service D

A 不感知 B/C/D，仅声明"发生了什么"

事件驱动状态转移（Event-Carried State Transfer）

事件携带完整状态数据，消费者无需回查生产者。

分布式链路追踪

Thu, 13 Aug 2026 01:35:00 +0800

分布式链路追踪

在微服务调用链中，一次请求可能涉及数十个服务。分布式链路追踪记录了请求的完整路径，让"慢在哪里"一目了然。

1. 核心概念

Trace：一次完整请求
 └── Span A (Gateway) [0ms ───── 5ms]
 └── Span B (Order) [2ms ───── 15ms]
 ├── Span C (DB) [3ms ─ 8ms]
 └── Span D (Stock)[10ms ─ 14ms]
 └── Span E (RPC)[11ms ─ 13ms]

概念	说明
Trace	一次端到端请求的完整链路，由唯一 TraceID 标识
Span	链路中的一个操作单元，包含起止时间、标签、日志
SpanContext	跨进程传递的上下文（TraceID + SpanID + flags）
Baggage	随链路传播的自定义键值对

2. 数据模型（OpenTelemetry）

Span:
 - trace_id: 16 bytes
 - span_id: 8 bytes 
 - parent_span_id: 8 bytes (根 Span 为空)
 - name: "GET /api/orders"
 - kind: SERVER / CLIENT / PRODUCER / CONSUMER / INTERNAL
 - start_time, end_time
 - attributes: { "http.method": "GET", "http.status_code": 200 }
 - events: [ { timestamp, name, attributes } ]
 - status: UNSET / OK / ERROR

3. TraceID 透传机制

HTTP Header 传递

请求入站:
 traceparent: 00-4bf92f3577b34da6a3ce929d0e0e4736-00f067aa0ba902b7-01
 
 格式: {version}-{trace-id}-{parent-id}-{trace-flags}
 		 00 4bf9...4736 00f0...02b7 01

代码示例（OpenTelemetry Java）

// 自动埋点（Spring Boot）
implementation 'io.opentelemetry:opentelemetry-spring-boot-starter'

// 手动创建 Span
Tracer tracer = openTelemetry.getTracer("order-service");

Span span = tracer.spanBuilder("processOrder")
 .setSpanKind(SpanKind.SERVER)
 .startSpan();

try (Scope scope = span.makeCurrent()) {
 span.setAttribute("order.id", orderId);
 span.setAttribute("user.id", userId);
 
 // 业务逻辑...
 
 span.addEvent("validation.completed");
} catch (Exception e) {
 span.recordException(e);
 span.setStatus(StatusCode.ERROR);
 throw e;
} finally {
 span.end();
}

跨进程传播

// 服务端提取上下文
Context extracted = propagator.extract(Context.current(), headers, getter);

// 客户端注入上下文
propagator.inject(context, requestBuilder, setter);

4. 采集与存储

架构

Application → SDK/Agent → Collector → Backend → UI
 (OTLP) (Jaeger/Tempo)
 
 ┌─────────────────────┐
 │ OpenTelemetry │
 │ Collector │
 │ receivers → processors → exporters
 └─────────────────────┘

采样策略

策略	说明	适用场景
头部采样	在请求入口处决定是否采样	简单、低开销
尾部采样	收集后根据完整链路特征决定	仅保留错误/慢请求
概率采样	固定比例采样	通用场景
限速采样	限制单位时间采样数	高流量服务

# Collector 尾部采样配置
tail_sampling:
 policies:
 - name: errors
 type: status_code
 status_code: { status_codes: [ERROR] }
 - name: slow
 type: latency
 latency: { threshold_ms: 1000 }

5. Jaeger 实战

部署

# Docker Compose 示例
services:
 jaeger:
 image: jaegertracing/all-in-one:latest
 ports:
 - "16686:16686" # UI
 - "14268:14268" # Collector HTTP
 environment:
 COLLECTOR_OTLP_ENABLED: true

查询分析

Jaeger UI 功能：
- Search：按服务、标签、时间范围检索 Trace
- Compare：对比两次请求的链路差异
- Dependencies：服务依赖拓扑图
- Trace View：瀑布图展示 Span 时序
- Critical Path：识别最长路径

与 Prometheus/Grafana 联动

# Grafana 数据源配置
- name: Jaeger
 type: jaeger
 url: http://jaeger-query:16686

# 在 Grafana 中关联 Metrics → Traces
# 点击延迟峰值直接跳转到对应 Trace

6. 长尾延迟分析

P99 延迟高 ≠ 所有请求都慢。分析长尾请求：

1. 按 Trace 中最大 Span 耗时排序
2. 识别 Critical Path 上的瓶颈
3. 对比正常 vs 异常 Trace 的差异
4. 常见根因：
 - 某实例 GC STW 过长
 - 数据库慢查询
 - 下游服务超时重试
 - 网络抖动

7. 最佳实践

命名规范：Span name 格式统一 操作方法，如 SELECT orders 或 GET /api/orders
属性标准化：遵循 OpenTelemetry Semantic Conventions
避免过度追踪：高并发服务使用采样，防止采集压垮系统
关联日志：TraceID 写入日志，实现日志与追踪联动
业务标签：在 Span 中记录业务关键标识（订单ID、用户ID）

总结

组件	角色
OpenTelemetry	标准协议 + 多语言 SDK
Collector	数据采集、处理、导出
Jaeger/Tempo	存储与查询后端
Grafana	统一可视化

链路追踪让分布式系统的"黑盒"变透明，是定位性能瓶颈和故障的根本手段。

熔断、降级与限流

Thu, 13 Aug 2026 01:30:00 +0800

熔断、降级与限流

微服务调用链中，单点故障可能引发级联雪崩。熔断、降级、限流是保障系统稳定性的三道防线。

1. 熔断器（Circuit Breaker）

状态机

 ┌─────────┐ 失败率>阈值 ┌─────────┐
 │ CLOSED │──────────────→│ OPEN │
 │ (正常) │ │ (熔断) │
 └────┬────┘ └────┬────┘
 │ │
 失败计数恢复 │ 超时后
 │ ↓
 │ ┌─────────────┐
 └─────────────────│ HALF-OPEN │
 探测失败 │ (半开/探测) │
 └─────────────┘

参数配置

参数	说明	典型值
failureThreshold	触发熔断的失败次数/比例	5 次或 50%
slowCallThreshold	触发熔断的慢调用比例	80%
waitDurationInOpenState	OPEN 持续时间	30s
permittedNumberOfCallsInHalfOpenState	半开探测次数	3

Resilience4j 示例

CircuitBreakerConfig config = CircuitBreakerConfig.custom()
 .failureRateThreshold(50)
 .waitDurationInOpenState(Duration.ofSeconds(30))
 .permittedNumberOfCallsInHalfOpenState(3)
 .slidingWindowSize(100)
 .build();

CircuitBreaker cb = CircuitBreaker.of("orderService", config);

// 装饰调用
Supplier<String> decorated = CircuitBreaker
 .decorateSupplier(cb, () -> orderClient.getOrder(id));
String result = Try.ofSupplier(decorated)
 .recover(throwable -> "fallback_order")
 .get();

2. 降级（Degrade）

当服务不可用或响应过慢时，提供简化替代方案。

分布式配置中心

Thu, 13 Aug 2026 01:25:00 +0800

分布式配置中心

在微服务架构中，管理数十乃至上百个服务的配置是一项挑战。配置中心统一管控配置，支持动态更新与灰度发布。

1. 为什么需要配置中心

痛点	配置中心解决方式
配置散落各处	集中存储与管理
修改需重启	热更新、实时推送
多环境混乱	环境隔离、命名空间
无变更审计	版本管理与操作日志
敏感信息泄露	加密存储与权限控制

2. 核心能力对比

能力	Spring Config	Nacos	Apollo
配置推送	依赖 Bus/Webhook	长轮询秒级	长轮询秒级
灰度发布	不支持	部分	完善（灰度规则）
版本管理	Git 版本	历史版本	发布历史+回滚
权限控制	弱	命名空间级	细粒度 RBAC
多集群	Profile	Namespace	Cluster + Namespace
控制台	无	有	完善
配置校验	无	无	语法校验

3. Apollo 详解

携程开源，功能最完善的配置中心。

服务注册发现与负载均衡

Thu, 13 Aug 2026 01:20:00 +0800

服务注册发现与负载均衡

在微服务架构中，服务实例动态扩缩容，客户端无法硬编码地址。注册中心与负载均衡解决了"如何找到服务"和"如何分配流量"的核心问题。

API 网关与 BFF 架构

Thu, 13 Aug 2026 01:15:00 +0800

API 网关与 BFF 架构

网关是微服务架构的流量入口，BFF 是适配多端体验的专用层。两者结合实现灵活的前后端协作。

1. API 网关核心职责

 Client
 ↓
 ┌───────────────┐
 │ API Gateway │ ← 流量入口
 └───────────────┘
 │
 ┌───────────────┼───────────────┐
 ↓ ↓ ↓
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Order │ │ Payment │ │ User │
│ Service │ │ Service │ │ Service │
└──────────┘ └──────────┘ └──────────┘

功能矩阵

职责	说明
请求路由	按路径/Host/Header 转发到后端服务
负载均衡	多种 LB 算法：Round Robin、Least Conn
认证授权	JWT 校验、OAuth 集成、RBAC
限流熔断	令牌桶限流、熔断状态机
协议转换	HTTP ↔ gRPC、REST ↔ GraphQL
日志监控	请求日志、延迟分布、错误率
灰度发布	按用户比例/Header 路由

2. 网关选型

网关	特点	适用场景
Nginx/OpenResty	高性能、Lua 扩展	简单路由、高并发入口
Kong	插件丰富、企业级	全功能 API 管理
Apinto	国产开源、轻量	国内生态替代
Spring Cloud Gateway	Java 生态、Spring 集成	Spring 体系微服务
Envoy	云原生、Service Mesh	K8s + Istio 场景
Traefik	自动服务发现	云原生动态路由

3. BFF 模式

Backend for Frontend：为不同客户端提供定制化的 API。

领域驱动设计（DDD）

Thu, 13 Aug 2026 01:10:00 +0800

领域驱动设计（DDD）

DDD 是一种以业务领域为核心的软件设计方法，通过统一语言连接业务与技术，解决复杂业务系统的建模难题。

1. DDD 核心思想

┌────────────────────────────────┐
│ 统一语言 Ubiquitous │
│ Language │
└────────────────────────────────┘
 ↓ ↑
┌────────────────────────────────┐
│ 领域模型 Domain Model │
│ ┌─────┐ ┌─────┐ ┌────────┐ │
│ │实体 │ │值对象│ │ 聚合 │ │
│ └─────┘ └─────┘ └────────┘ │
└────────────────────────────────┘

核心：技术与业务使用同一套语言进行沟通，模型直接反映业务概念。

单体应用 vs 微服务

Thu, 13 Aug 2026 01:05:00 +0800

单体应用 vs 微服务

单体还是微服务？这不是非此即彼的选择，而是演进过程中的阶段性决策。

1. 单体架构

所有功能模块打包为单个应用，共享代码库与数据库。

类型演进

简单单体 → 模块化单体 → 分布式单体（伪微服务）
 ↑ ↑ ↑
 起步阶段 团队扩大 反模式

单体优势

优势	说明
开发简单	无需考虑分布式问题
易测试	集成测试在一个进程内完成
部署便捷	单个 artifact，一键部署
性能高效	本地调用无网络开销
事务简单	单数据库天然支持 ACID

单体痛点

代码耦合严重，任何改动都需全量回归
技术栈锁死，难以渐进式引入新技术
部署粒度粗，小改动也需全量发布
团队并行开发困难，合并冲突频发

模块化单体

渐进式改良：在单体内部划分清晰模块，为未来拆分做准备。

架构设计基础原则

Thu, 13 Aug 2026 01:00:00 +0800

架构设计基础原则

架构设计不是凭空创造，而是在约束与目标之间寻找最优解。掌握基础原则是做出正确决策的前提。

1. SOLID 原则

单一职责原则（SRP）

一个类只应该有一个引起它变化的原因。

// 反例：UserService 同时处理用户管理与邮件发送
class UserService {
 void createUser() { ... }
 void sendEmail() { ... } // 职责混杂
}

// 正例：分离职责
class UserService { void createUser() { ... } }
class EmailService { void sendEmail() { ... } }

开闭原则（OCP）

对扩展开放，对修改关闭。 通过抽象和多态实现。

系统架构设计

Thu, 13 Aug 2026 00:00:00 +0800

系统架构设计

本专题从架构设计基础原则出发，深入讲解单体到微服务的演进、领域驱动设计（DDD）、云原生架构模式、服务治理、容量规划与架构评审等核心主题，帮助你建立完整的系统架构设计知识体系。