senior-architect
Compare original and translation side by side
🇺🇸
Original
English🇨🇳
Translation
ChineseSenior Software Architect
资深软件架构师
Expert-level software architecture for scalable systems.
面向可扩展系统的专业级软件架构内容。
Core Competencies
核心能力
- System design
- Distributed systems
- Microservices architecture
- Scalability patterns
- Technical decision-making
- Architecture documentation
- Technology evaluation
- Performance optimization
- 系统设计
- 分布式系统
- 微服务架构
- 可扩展性模式
- 技术决策制定
- 架构文档
- 技术评估
- 性能优化
Architecture Patterns
架构模式
Monolith vs Microservices
Monolith vs Microservices
| Aspect | Monolith | Microservices |
|---|---|---|
| Complexity | Lower initially | Higher |
| Deployment | Single unit | Independent |
| Scaling | Vertical/Horizontal | Service-level |
| Team Size | Small teams | Multiple teams |
| Data | Single DB | Distributed |
| Best For | Startups, MVPs | Scale, large orgs |
| 维度 | 单体架构 | 微服务架构 |
|---|---|---|
| 复杂度 | 初期较低 | 较高 |
| 部署方式 | 单一单元 | 独立部署 |
| 扩容方式 | 垂直/水平扩容 | 服务级扩容 |
| 团队规模 | 小型团队 | 多团队 |
| 数据管理 | 单一数据库 | 分布式数据 |
| 适用场景 | 初创公司、最小可行产品（MVP） | 规模化场景、大型组织 |
Service Architecture Patterns
服务架构模式
Layered Architecture:
┌─────────────────────────────────────┐
│ Presentation Layer │
├─────────────────────────────────────┤
│ Application Layer │
├─────────────────────────────────────┤
│ Domain Layer │
├─────────────────────────────────────┤
│ Infrastructure Layer │
└─────────────────────────────────────┘Hexagonal Architecture:
┌─────────┐
┌──────│ API │──────┐
│ └─────────┘ │
┌────▼────┐ ┌──────▼──────┐
│ CLI │ │ Database │
└────┬────┘ └──────┬──────┘
│ ┌─────────┐ │
└──────│ Core │──────┘
│ Domain │
┌──────│ │──────┐
│ └─────────┘ │
┌────▼────┐ ┌──────▼──────┐
│ Queue │ │ External │
└─────────┘ │ Service │
└─────────────┘Event-Driven Architecture:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Service A │────▶│ Event │────▶│ Service B │
└─────────────┘ │ Bus │ └─────────────┘
│ │
┌─────────────┐ │ │ ┌─────────────┐
│ Service C │◀────│ │────▶│ Service D │
└─────────────┘ └─────────────┘ └─────────────┘分层架构:
┌─────────────────────────────────────┐
│ Presentation Layer │
├─────────────────────────────────────┤
│ Application Layer │
├─────────────────────────────────────┤
│ Domain Layer │
├─────────────────────────────────────┤
│ Infrastructure Layer │
└─────────────────────────────────────┘六边形架构:
┌─────────┐
┌──────│ API │──────┐
│ └─────────┘ │
┌────▼────┐ ┌──────▼──────┐
│ CLI │ │ Database │
└────┬────┘ └──────┬──────┘
│ ┌─────────┐ │
└──────│ Core │──────┘
│ Domain │
┌──────│ │──────┐
│ └─────────┘ │
┌────▼────┐ ┌──────▼──────┐
│ Queue │ │ External │
└─────────┘ │ Service │
└─────────────┘事件驱动架构:
┌─────────────┐ ┌─────────────┐ ┌─────────────┐
│ Service A │────▶│ Event │────▶│ Service B │
└─────────────┘ │ Bus │ └─────────────┘
│ │
┌─────────────┐ │ │ ┌─────────────┐
│ Service C │◀────│ │────▶│ Service D │
└─────────────┘ └─────────────┘ └─────────────┘Distributed Systems
分布式系统
CAP Theorem
CAP Theorem
- Consistency: All nodes see same data simultaneously
- Availability: Every request receives response
- Partition Tolerance: System continues despite network failures
Choose Two:
- CA: Traditional RDBMS (single node)
- CP: Distributed databases (MongoDB, HBase)
- AP: DNS, Cassandra, DynamoDB
- 一致性: 所有节点同时看到相同的数据
- 可用性: 每个请求都能收到响应
- 分区容错性: 即使网络故障，系统仍能持续运行
三者选其二:
- CA: 传统关系型数据库（单节点）
- CP: 分布式数据库（MongoDB、HBase）
- AP: DNS、Cassandra、DynamoDB
Consistency Patterns
一致性模式
Strong Consistency:
- All reads return most recent write
- Use: Financial transactions, inventory
- Trade-off: Higher latency
Eventual Consistency:
- Reads may return stale data temporarily
- Use: Social media feeds, analytics
- Trade-off: Complexity in application
Causal Consistency:
- Preserves cause-effect relationships
- Use: Collaborative editing, messaging
- Trade-off: Moderate complexity
强一致性:
- 所有读取都返回最新写入的数据
- 适用场景: 金融交易、库存管理
- 权衡点: 更高延迟
最终一致性:
- 读取可能暂时返回过期数据
- 适用场景: 社交媒体信息流、分析系统
- 权衡点: 应用复杂度提升
因果一致性:
- 保留因果关系
- 适用场景: 协同编辑、消息系统
- 权衡点: 中等复杂度
Distributed Transactions
分布式事务
Saga Pattern:
┌─────────────────────────────────────────────────────────┐
│ Choreography Saga │
├─────────────────────────────────────────────────────────┤
│ │
│ Order Inventory Payment Shipping │
│ Service Service Service Service │
│ │ │ │ │ │
│ │──Create────▶│ │ │ │
│ │ │───Reserve────▶│ │ │
│ │ │ │───Charge───▶│ │
│ │ │ │ │──Ship │
│ │◀───────────────────────────────────Complete│ │
│ │
│ Compensation (on failure): │
│ │◀─Release───│◀──Refund─────│◀──Cancel────│ │
│ │
└─────────────────────────────────────────────────────────┘Two-Phase Commit:
Phase 1 (Prepare):
Coordinator → All Participants: "Prepare"
All Participants → Coordinator: "Ready" or "Abort"
Phase 2 (Commit/Abort):
If all Ready:
Coordinator → All Participants: "Commit"
Else:
Coordinator → All Participants: "Abort"Saga模式:
┌─────────────────────────────────────────────────────────┐
│ Choreography Saga │
├─────────────────────────────────────────────────────────┤
│ │
│ Order Inventory Payment Shipping │
│ Service Service Service Service │
│ │ │ │ │ │
│ │──Create────▶│ │ │ │
│ │ │───Reserve────▶│ │ │
│ │ │ │───Charge───▶│ │
│ │ │ │ │──Ship │
│ │◀───────────────────────────────────Complete│ │
│ │
│ Compensation (on failure): │
│ │◀─Release───│◀──Refund─────│◀──Cancel────│ │
│ │
└─────────────────────────────────────────────────────────┘两阶段提交（2PC）:
Phase 1 (Prepare):
Coordinator → All Participants: "Prepare"
All Participants → Coordinator: "Ready" or "Abort"
Phase 2 (Commit/Abort):
If all Ready:
Coordinator → All Participants: "Commit"
Else:
Coordinator → All Participants: "Abort"Scalability Patterns
可扩展性模式
Horizontal Scaling
水平扩容
Load Balancing Strategies:
- Round Robin: Simple rotation
- Least Connections: Route to least busy
- IP Hash: Sticky sessions
- Weighted: Based on server capacity
Stateless Design:
┌─────────────┐ ┌─────────────┐
│ Client │────▶│ Load │
└─────────────┘ │ Balancer │
└──────┬──────┘
┌───────────────┼───────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Server 1 │ │ Server 2 │ │ Server 3 │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
└───────────────┼───────────────┘
▼
┌─────────────────────┐
│ Shared State │
│ (Redis/DB) │
└─────────────────────┘负载均衡策略:
- 轮询法: 简单轮询
- 最少连接数法: 路由至最空闲节点
- IP哈希法: 会话粘滞
- 加权法: 基于服务器容量
无状态设计:
┌─────────────┐ ┌─────────────┐
│ Client │────▶│ Load │
└─────────────┘ │ Balancer │
└──────┬──────┘
┌───────────────┼───────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Server 1 │ │ Server 2 │ │ Server 3 │
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
└───────────────┼───────────────┘
▼
┌─────────────────────┐
│ Shared State │
│ (Redis/DB) │
└─────────────────────┘Caching Strategies
缓存策略
Cache Levels:
┌─────────────────────────────────────────────────────┐
│ L1: Application Cache (in-memory) ~1ms │
├─────────────────────────────────────────────────────┤
│ L2: Distributed Cache (Redis) ~5ms │
├─────────────────────────────────────────────────────┤
│ L3: CDN Cache ~50ms │
├─────────────────────────────────────────────────────┤
│ L4: Database ~100ms │
└─────────────────────────────────────────────────────┘Cache Patterns:
Cache-Aside:
1. Check cache
2. If miss, read from DB
3. Store in cache
4. Return data
Write-Through:
1. Write to cache
2. Cache writes to DB
3. Return success
Write-Behind:
1. Write to cache
2. Return success
3. Cache async writes to DB缓存层级:
┌─────────────────────────────────────────────────────┐
│ L1: 应用层缓存（内存中） ~1ms │
├─────────────────────────────────────────────────────┤
│ L2: 分布式缓存（Redis） ~5ms │
├─────────────────────────────────────────────────────┤
│ L3: CDN缓存 ~50ms │
├─────────────────────────────────────────────────────┤
│ L4: 数据库 ~100ms │
└─────────────────────────────────────────────────────┘缓存模式:
旁路缓存:
1. 检查缓存
2. 若未命中，从数据库读取
3. 存入缓存
4. 返回数据
写穿透缓存:
1. 写入缓存
2. 缓存同步写入数据库
3. 返回成功
写回缓存:
1. 写入缓存
2. 返回成功
3. 缓存异步写入数据库Database Scaling
数据库扩容
Read Replicas:
┌────────────┐
│ Master │◀────── Writes
└─────┬──────┘
│ Replication
├──────────────┬──────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Replica 1│ │ Replica 2│ │ Replica 3│
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
└─────────────┴─────────────┘
│
Reads distributedSharding Strategies:
- Hash-based: Consistent hashing
- Range-based: Date ranges, alphabetical
- Geographic: By region
- Directory-based: Lookup service
只读副本:
┌────────────┐
│ Master │◀────── Writes
└─────┬──────┘
│ Replication
├──────────────┬──────────────┐
▼ ▼ ▼
┌──────────┐ ┌──────────┐ ┌──────────┐
│ Replica 1│ │ Replica 2│ │ Replica 3│
└────┬─────┘ └────┬─────┘ └────┬─────┘
│ │ │
└─────────────┴─────────────┘
│
Reads distributed分片策略:
- 基于哈希: 一致性哈希
- 基于范围: 日期范围、字母顺序
- 基于地域: 按地区划分
- 基于目录: 查询服务
API Design
API设计
REST Maturity Model
REST成熟度模型
Level 0: Single URI, POST everything
Level 1: Multiple URIs, resources
Level 2: HTTP methods (GET, POST, PUT, DELETE)
Level 3: HATEOAS (Hypermedia controls)
Level 0: 单一URI，所有操作使用POST
Level 1: 多URI，面向资源
Level 2: 使用HTTP方法（GET、POST、PUT、DELETE）
Level 3: HATEOAS（超媒体控制）
API Versioning
API版本控制
undefinedundefinedURL Path
URL路径
GET /api/v1/users
GET /api/v1/users
Query Parameter
查询参数
GET /api/users?version=1
GET /api/users?version=1
Header
请求头
GET /api/users
Accept: application/vnd.api+json;version=1
GET /api/users
Accept: application/vnd.api+json;version=1
Content Negotiation
内容协商
GET /api/users
Accept: application/vnd.company.api.v1+json
undefinedGET /api/users
Accept: application/vnd.company.api.v1+json
undefinedRate Limiting
限流
Token Bucket Algorithm:
Bucket Capacity: 100 tokens
Refill Rate: 10 tokens/second
Request arrives:
If tokens > 0:
tokens -= 1
Process request
Else:
Reject (429 Too Many Requests)令牌桶算法:
Bucket Capacity: 100 tokens
Refill Rate: 10 tokens/second
Request arrives:
If tokens > 0:
tokens -= 1
Process request
Else:
Reject (429 Too Many Requests)Reliability Patterns
可靠性模式
Circuit Breaker
断路器模式
States: CLOSED → OPEN → HALF-OPEN → CLOSED
CLOSED:
- Normal operation
- Track failures
- If failure_count > threshold: → OPEN
OPEN:
- Reject all requests immediately
- After timeout: → HALF-OPEN
HALF-OPEN:
- Allow limited requests
- If success: → CLOSED
- If failure: → OPENStates: CLOSED → OPEN → HALF-OPEN → CLOSED
CLOSED:
- 正常运行
- 跟踪失败次数
- 若失败次数超过阈值: → OPEN
OPEN:
- 立即拒绝所有请求
- 超时后: → HALF-OPEN
HALF-OPEN:
- 允许有限请求
- 若成功: → CLOSED
- 若失败: → OPENBulkhead
舱壁模式
┌─────────────────────────────────────────────┐
│ Application │
├─────────────┬─────────────┬─────────────────┤
│ Thread │ Thread │ Thread │
│ Pool A │ Pool B │ Pool C │
│ (Orders) │ (Users) │ (Analytics) │
│ │ │ │
│ [===] │ [===] │ [===] │
│ 10 threads │ 10 threads │ 5 threads │
└─────────────┴─────────────┴─────────────────┘
If Orders service fails, only Pool A exhausted.
Pools B and C continue operating.┌─────────────────────────────────────────────┐
│ Application │
├─────────────┬─────────────┬─────────────────┤
│ Thread │ Thread │ Thread │
│ Pool A │ Pool B │ Pool C │
│ (Orders) │ (Users) │ (Analytics) │
│ │ │ │
│ [===] │ [===] │ [===] │
│ 10 threads │ 10 threads │ 5 threads │
└─────────────┴─────────────┴─────────────────┘
If Orders service fails, only Pool A exhausted.
Pools B and C continue operating.Retry with Backoff
退避重试
python
def exponential_backoff(attempt: int, base: float = 1.0, max_delay: float = 60.0):
delay = min(base * (2 ** attempt), max_delay)
jitter = random.uniform(0, delay * 0.1)
return delay + jitterpython
def exponential_backoff(attempt: int, base: float = 1.0, max_delay: float = 60.0):
delay = min(base * (2 ** attempt), max_delay)
jitter = random.uniform(0, delay * 0.1)
return delay + jitterRetry pattern
Retry pattern
for attempt in range(max_retries):
try:
result = make_request()
break
except TransientError:
if attempt == max_retries - 1:
raise
time.sleep(exponential_backoff(attempt))
undefinedfor attempt in range(max_retries):
try:
result = make_request()
break
except TransientError:
if attempt == max_retries - 1:
raise
time.sleep(exponential_backoff(attempt))
undefinedArchitecture Documentation
架构文档
Architecture Decision Record (ADR)
架构决策记录（ADR）
markdown
undefinedmarkdown
undefinedADR-001: Use PostgreSQL for primary database
ADR-001: 使用PostgreSQL作为主数据库
Status
状态
Accepted
已接受
Context
背景
We need to choose a primary database for our e-commerce platform.
Requirements:
- ACID transactions for orders
- Complex queries for reporting
- Scalability to 10M users
我们需要为电商平台选择主数据库。
需求:
- 订单处理需要ACID事务
- 支持复杂查询用于报表
- 可扩展至1000万用户
Decision
决策
We will use PostgreSQL as our primary database.
我们将使用PostgreSQL作为主数据库。
Consequences
影响
Positive:
- Strong consistency guarantees
- Rich SQL features
- Excellent JSON support
- Large ecosystem
Negative:
- Manual sharding required at scale
- More complex HA setup than managed NoSQL
积极方面:
- 强一致性保障
- 丰富的SQL特性
- 出色的JSON支持
- 庞大的生态系统
消极方面:
- 规模化时需手动分片
- 高可用设置比托管NoSQL更复杂
Alternatives Considered
备选方案
- MongoDB: Better horizontal scaling, but weaker transactions
- CockroachDB: Better scaling, but higher operational complexity
- MySQL: Similar features, but less advanced JSON support
undefined- MongoDB: 水平扩容能力更强，但事务支持较弱
- CockroachDB: 扩容能力更好，但运维复杂度更高
- MySQL: 功能类似，但JSON支持较落后
undefinedC4 Model
C4 Model
Level 1 - System Context:
[User] → [System] → [External Systems]
Level 2 - Container:
[Web App] → [API] → [Database]
↓
[Message Queue] → [Worker]
Level 3 - Component:
API Container:
[Controllers] → [Services] → [Repositories]
Level 4 - Code:
Class diagrams, sequence diagramsLevel 1 - 系统上下文:
[用户] → [系统] → [外部系统]
Level 2 - 容器:
[Web应用] → [API] → [数据库]
↓
[消息队列] → [Worker]
Level 3 - 组件:
API容器:
[控制器] → [服务] → [仓库]
Level 4 - 代码:
类图、序列图Reference Materials
参考资料
- - Architecture patterns catalog
references/design_patterns.md - - Distributed systems guide
references/distributed_systems.md - - Scaling strategies
references/scalability.md - - Architecture documentation
references/documentation.md
- - 架构模式目录
references/design_patterns.md - - 分布式系统指南
references/distributed_systems.md - - 扩容策略
references/scalability.md - - 架构文档
references/documentation.md
Scripts
脚本工具
bash
undefinedbash
undefinedArchitecture diagram generator
架构图生成器
python scripts/arch_diagram.py --config services.yaml --output diagram.png
python scripts/arch_diagram.py --config services.yaml --output diagram.png
Dependency analyzer
依赖分析器
python scripts/dep_analyzer.py --path ./services --output deps.json
python scripts/dep_analyzer.py --path ./services --output deps.json
Capacity planner
容量规划器
python scripts/capacity_plan.py --current 10000 --growth 0.5 --period 12
python scripts/capacity_plan.py --current 10000 --growth 0.5 --period 12
Service mesh analyzer
服务网格分析器
python scripts/mesh_analyzer.py --namespace production
undefinedpython scripts/mesh_analyzer.py --namespace production
undefined