技术架构师

本skill指导如何从技术架构层面确保系统代码符合架构要求，实现健壮性、扩展性、并发支撑性、伸缩性等目标，推进Explicit Architecture等清晰架构。

何时使用本Skill

当技术架构师需要设计系统架构或审查代码架构时使用，例如：

• "我是技术架构师，需要设计系统架构..."

• "我需要审查这个代码的架构..."

• "请帮我优化系统架构..."

核心职责

1. 系统架构设计

• 设计系统整体架构

• 设计技术选型方案

• 设计部署架构

• 设计数据架构

2. 架构保障

• 确保架构健壮性

• 确保架构扩展性

• 确保架构并发支撑性

• 确保架构伸缩性

3. 代码架构推进

• 推进Explicit Architecture（显式架构）

• 推进六边形架构

• 推进整洁架构（Clean Architecture）

• 推进领域驱动设计（DDD）

4. 代码审查

• 审查代码架构

• 检查代码规范

• 检查设计模式使用

• 检查代码质量

5. 技术难点攻关

• 解决技术难点

• 优化系统性能

• 解决技术瓶颈

关键技能

架构风格与模式

分层架构模式

关注代码组织结构和依赖关系，通过分层实现关注点分离和依赖管理。

分层架构类型：

• 分层架构：经典的N层架构，如表现层、业务层、数据层

• 关注点分离架构：关注点分离，通过领域层、应用层、基础设施层分离业务逻辑和技术细节

清晰架构(Explicit Architecture)：

• 显式定义架构边界、依赖关系和层次结构

• 显式定义职责划分

• 架构可视化

关键原则：

• 依赖倒置原则

• 依赖规则清晰

• 架构可视化

• 代码即文档

实施方法：

• 使用架构注解标记各层代码

• 使用工具检查依赖关系

• 生成架构依赖图

• 定期审查架构符合性

COLA架构(Clean Object-Oriented and Layered Architecture)：

• 阿里巴巴开源的分层架构框架

• 关注点分离，可扩展性好

六边形架构(Hexagonal Architecture)：

• 端口和适配器模式，分离领域逻辑和外部依赖

• 分离领域层和应用层

• 使用端口和适配器模式

• 解耦业务逻辑和外部依赖

层次结构：

• 领域层：业务逻辑、实体、值对象、领域服务

• 应用层：应用服务、用例、领域事件

• 适配器层：接口适配、持久化适配、消息适配

• 基础设施层：外部依赖、框架、工具

依赖方向：外部依赖 → 适配器层 → 应用层 → 领域层

整洁架构(Clean Architecture)：

• 依赖规则明确，业务逻辑独立于框架和数据库

• 业务逻辑独立

• 易于测试和扩展

层次结构：

• 实体层：企业级业务规则

• 用例层：应用特定业务规则

• 接口适配层：数据格式转换

• 框架与驱动层：Web框架、数据库等

依赖规则：外层依赖内层，内层不依赖外层

洋葱架构(Onion Architecture)：

• 同心圆分层架构，内层不依赖外层

适用场景：

• 需要清晰的代码组织和依赖管理

• 业务逻辑复杂，需要隔离业务和技术细节

• 需要支持多种前端和后端实现

• 长期维护的复杂系统

分布式架构模式

关注服务拆分、通信和协同，支持系统的横向扩展和弹性伸缩。

• 微服务架构：服务独立部署、独立扩展的分布式系统架构

• 事件驱动架构：通过事件解耦服务，支持异步通信和最终一致性

• CQRS架构：命令查询责任分离，读写分离提升查询性能

适用场景：

• 需要支持高并发和高可用

• 业务边界清晰，可以独立部署

• 需要快速迭代和独立扩展

• 团队规模较大，需要独立开发

领域驱动设计

以业务领域为中心的软件设计方法论，强调领域模型和通用语言。

• 领域驱动设计(DDD)：以领域模型为核心，通过限界上下文、聚合根、实体、值对象等概念构建复杂业务系统

• 以领域为中心

• 领域模型驱动设计

• 通用语言（Ubiquitous Language）

核心概念：

• 领域（Domain）：问题空间

• 子域（Subdomain）：领域的细分

• 限界上下文（Bounded Context）：上下文边界

• 聚合（Aggregate）：一致性边界

• 实体（Entity）：有唯一标识的对象

• 值对象（Value Object）：无唯一标识的对象

适用场景：

• 业务逻辑复杂，规则多且变化快

• 需要业务专家和开发者协作

• 长期演进的核心业务系统

• 需要准确表达业务概念和规则

设计模式

• GoF设计模式(23种)

设计原则

面向对象设计原则

SOLID设计原则：

• 单一职责原则 (SRP, Single Responsibility Principle)：一个类应该只有一个引起它变化的原因，职责分离

• 开放封闭原则 (OCP, Open-Closed Principle)：软件实体对扩展开放，对修改关闭

• 里氏替换原则 (LSP, Liskov Substitution Principle)：子类可以替换父类出现的地方，而不影响程序正确性

• 接口隔离原则 (ISP, Interface Segregation Principle)：客户端不应该依赖它不需要的接口

• 依赖反转原则 (DIP, Dependency Inversion Principle)：高层模块不应依赖低层模块，两者都应依赖抽象

代码质量原则

• KISS原则 (Keep It Simple, Stupid)：保持简单愚蠢，避免不必要的复杂性

• DRY原则 (Don't Repeat Yourself)：不要重复自己，避免代码重复

• YAGNI原则 (You Aren't Gonna Need It)：不要过度设计，只实现当前需要的功能

• 迪米特法则 (LoD, Law of Demeter)：最少知识原则，对象之间应保持最少交互

• SoC原则 (Separation of Concerns)：关注点分离，将不同关注点分离到不同模块

架构设计原则

• 高内聚 (Maximize Cohesion)：相关的功能应该组织在一起，模块内部元素紧密相关

• 低耦合 (Minimize Coupling)：模块之间依赖关系最小化，降低相互影响

• 隐藏实现细节 (Hide Implementation Details)：通过接口暴露功能，隐藏实现细节

• 为维护者编码 (Code for the Maintainer)：代码应易于理解和维护，不仅是让机器运行

设计决策原则

• 最小惊讶原则 (POLA, Principle of Least Astonishment)：设计应符合用户预期，避免意外行为

• 最小努力原则 (POLE, Principle of Least Effort)：选择最简单有效的解决方案

• 最后责任时刻 (LRM, The Last Responsible Moment)：尽可能推迟不可逆转的决策，在必须做决策时才做

• 童子军原则 (BSR, Boy-Scout Rule)：离开时比来时更干净，留下比发现时更好的代码

优化原则

• 过早优化是万恶之源 (POITROAE, Premature Optimization Is the Root of All Evil)：优先保证正确性和可读性，性能问题在必要时再优化

• Curly's Law：命名即解释，变量和方法名应该清楚地表达其意图

架构描述

能够清晰、准确地描述和表达架构设计，是技术架构师的核心能力之一。

关键技能：

架构视图：使用多种视图全面描述架构（如4+1视图、C4模型）

• 逻辑视图：功能和业务流程

• 开发视图：代码组织和依赖关系

• 进程视图：运行时行为和并发

• 物理视图：部署和基础设施

• 场景视图：用例和场景

架构建模：使用标准建模语言和工具

• UML（Unified Modeling Language）：类图、组件图、部署图、时序图等

• C4模型：Context、Container、Component、Code 四层视图

• Mermaid：文本转图表，支持多种图表类型

• ArchiMate：企业架构建模语言

架构图绘制：创建清晰的架构可视化

• 系统架构图：展示系统整体结构和关系

• 组件图：展示模块和组件的交互

• 部署图：展示物理部署和基础设施

• 数据流图：展示数据在系统中的流动

• 时序图：展示组件间的时序交互

架构文档编写：编写完整的架构设计文档

• 架构概述和设计原则

• 系统层次结构和模块划分

• 关键技术选型和决策

• 接口定义和数据模型

• 数据流和交互关系

架构决策记录（ADR）：记录重要架构决策

• 决策背景和上下文

• 决策内容

• 决策理由和权衡

• 决策后果和影响

工具和方法：

• 绘图工具：Draw.io、Lucidchart、PlantUML、Mermaid

• 建模工具：Enterprise Architect、Visual Paradigm、StarUML

• 文档工具：Confluence、Notion、Markdown + Diagrams

• 版本控制：Git + 图表版本管理

最佳实践：

• 一图胜千言：优先使用图表而非纯文字

• 多层视图：使用不同视图满足不同受众需求

• 持续更新：架构文档与代码保持同步

• 版本管理：架构图纳入版本控制

• 可视化依赖：清晰的依赖关系图，帮助理解架构

质量标准

按质量属性维度

运行时质量

• ✅ 性能（Performance）: 满足要求（响应时间、吞吐量、资源利用率达标）

• ✅ 可扩展性（Scalability）: 支持业务增长（水平扩展、垂直扩展能力具备）

• ✅ 可用性（Availability）: 达到SLA标准（服务可用率、故障恢复时间符合预期）

• ✅ 可靠性（Reliability）: 满足容错和恢复要求（错误处理、熔断、重试机制完善）

• ✅ 安全性（Security）: 符合安全规范（认证、授权、加密、防护措施到位）

• ✅ 可观测性（Observability）: 监控体系完善（监控、日志、链路追踪完备）

开发时质量

• ✅ 可维护性（Maintainability）: 代码整洁（可读性、模块化、可重构）

• ✅ 可测试性（Testability）: 测试覆盖率达标（单元测试、集成测试充分）

• ✅ 可扩展性（Extensibility）: 可插拔（插件化、配置化设计合理）

• ✅ 兼容性（Compatibility）: 向后兼容、接口兼容、版本管理规范

业务质量

• ✅ 数据一致性（Consistency）: 符合业务规则（强一致性或最终一致性满足需求）

• ✅ 幂等性（Idempotency）: 保障重复操作安全（分布式操作幂等实现）

• ✅ 事务完整性（Transaction Integrity）: 保证业务准确（ACID特性、补偿机制完善）

• ✅ 可追溯性（Traceability）: 支持审计追踪（操作日志、数据追踪完整）

运维质量

• ✅ 可部署性（Deployability）: 支持持续交付（版本管理、回滚机制、CI/CD流程）

• ✅ 可运维性（Operability）: 运维友好（故障诊断、自动化运维、运维文档完善）

• ✅ 可伸缩性（Elasticity）: 支持弹性伸缩（自动扩缩容、负载均衡配置合理）

• ✅ 可监控性（Monitorability）: 运维监控完善（监控指标、报警阈值、运维告警完善）

按架构层次划分

基础设施层关注点

• ✅ 性能优化（Performance）

• ✅ 资源利用率（Resource Utilization）

• ✅ 可伸缩性（Scalability）

• ✅ 可观测性（Observability）

应用层关注点

• ✅ 可扩展性（Scalability）

• ✅ 可维护性（Maintainability）

• ✅ 可测试性（Testability）

• ✅ 可部署性（Deployability）

领域层关注点

• ✅ 业务正确性（Business Correctness）

• ✅ 数据一致性（Data Consistency）

• ✅ 事务完整性（Transaction Integrity）

• ✅ 可追溯性（Traceability）

适配器层关注点

• ✅ 兼容性（Compatibility）

• ✅ 互操作性（Interoperability）

• ✅ 隔离性（Isolation）

跨层关注点

• ✅ 安全性（Security）

• ✅ 可用性（Availability）

• ✅ 可靠性（Reliability）

• ✅ 可运维性（Operability）

技术选型

评估和选择合适的技术栈，为项目提供最优的技术方案。

关键技能：

多技术栈了解：广泛了解多种技术栈和框架

• 前端技术：React、Vue、Angular、Svelte等

• 后端技术：Spring Boot、Node.js、Django、Go等

• 数据库：MySQL、PostgreSQL、MongoDB、Redis等

• 消息队列：Kafka、RabbitMQ、RocketMQ等

• 容器和编排：Docker、Kubernetes、Docker Compose等

技术评估能力：客观评估技术的优缺点和适用场景

• 成熟度评估：技术成熟度、社区活跃度、生态系统

• 性能评估：性能指标、资源消耗、扩展能力

• 兼容性评估：与现有系统的兼容性、集成复杂度

• 成本评估：学习成本、开发成本、运维成本

技术决策能力：基于评估结果做出合理的技术选择

• 需求匹配：技术与业务需求、技术需求的匹配度

• 风险评估：技术风险、实施风险、维护风险

• 团队能力：团队技术能力、学习曲线、培训成本

• 长期规划：技术演进性、可维护性、可扩展性

选型流程：

• 需求分析：明确技术需求和非功能需求

• 技术调研：收集候选技术方案信息

• 评估对比：多维度评估和对比技术方案

• POC验证：关键技术的概念验证（Proof of Concept）

• 决策评审：与团队评审和讨论，达成共识

• 技术选型报告：输出选型决策和理由

评估维度：

• 功能性：是否满足业务需求

• 性能：性能指标是否达标

• 可靠性：稳定性和可用性

• 易用性：开发体验和运维便捷性

• 可维护性：代码质量、文档完整性、社区支持

• 成本：TCO（总体拥有成本）

• 风险：技术风险、法律风险、供应商风险

代码审查

• 代码架构审查

• 代码质量审查

• 设计模式审查

工作流程

• 架构设计：根据产品需求进行系统架构设计

• 技术选型：评估和选择适合的技术方案

• 架构规范制定：制定架构规范和编码标准

• 代码审查：对开发代码进行架构层面的审查

• 架构优化：根据问题提出架构优化方案

• 风险评估：评估技术方案的风险和可行性

• 性能优化：优化系统性能和资源利用

• 架构文档：编写架构设计文档和决策记录

工作流程图

graph LR A[产品规格] -->|架构分析| B[架构设计] B -->|技术评估| C[技术选型] C -->|方案决策| D[架构方案] D -->|规范制定| E[架构规范] E -->|代码审查| F{架构符合?} F -->|是| G[性能优化] F -->|否| H[提出改进] H -->|调整实现| I[重新审查] I -->|符合要求| G G -->|风险评估| J[评估报告] J -->|文档编写| K[架构文档] K -->|决策记录| L[ADR文档]

• 向上对接：产品专家

• 向下对接：前端工程师、后端工程师

• 平行对接：需求分析师、测试人员

输入物

• 产品功能清单

• 功能规格说明

• 业务领域模型

• 性能要求

交付物

设计阶段交付物

系统架构设计文档：包含系统整体架构、技术选型、部署架构、数据架构

• 架构概述和设计原则

• 系统层次结构图

• 组件和模块说明

• 数据流和交互关系

• 接口定义和数据模型

技术选型报告：包含技术栈选择及其理由

• 候选技术方案对比

• 选型决策依据

• 技术风险评估

• 团队技术能力匹配度

架构决策记录（ADR, Architecture Decision Records）：记录重要架构决策

• 决策背景和上下文

• 决策内容

• 决策理由和权衡

• 决策后果和影响

部署架构设计文档：说明部署方案和环境要求

• 部署拓扑结构

• 环境配置（开发、测试、生产）

• 网络和安全配置

• 扩容和容灾方案

数据架构设计文档：说明数据存储和处理方案

• 数据模型设计

• 数据库选型和分库分表策略

• 缓存策略

• 数据备份和恢复方案

规范阶段交付物

架构规范：定义架构标准和设计规范

• 分层架构规范

• 模块划分和依赖规则

• 接口设计规范

• 数据访问规范

代码规范：定义编码标准和最佳实践

• 编码风格规范

• 命名规范

• 设计模式使用规范

• 测试编写规范

技术债务清单：识别和跟踪技术债务

• 债务描述和类型

• 影响评估和优先级

• 偿还计划和时间表

评估阶段交付物

架构审查报告：定期审查架构的符合性和质量

• 绘制项目架构图

• 架构质量符合性检查结果

• 发现的问题和风险

• 改进建议和行动计划

• 审查结论和下一步行动

代码审查报告：审查代码的架构符合性和质量

• 代码架构符合性检查

• 代码质量评估

• 设计模式使用情况

• 问题清单和改进建议

技术风险评估：评估技术风险并制定应对策略

• 技术风险识别

• 风险影响和概率评估

• 风险应对策略

• 风险监控机制

性能测试报告：验证系统性能指标

• 测试场景和目标

• 测试结果和性能指标

• 性能瓶颈分析

• 优化建议

交付物说明：

• 设计阶段交付物在架构设计完成后产出

• 规范阶段交付物在架构评审通过后产出

• 评估阶段交付物在开发和运行过程中定期产出

• 所有交付物应版本化并纳入文档管理## 工作流程

• 需求接收：接收产品功能清单、功能规格说明、业务领域模型

• 需求分析：分析技术要求和性能要求

• 架构设计：设计系统整体架构

• 技术选型：选择合适的技术栈

• 架构评审：评审架构设计方案

• 架构规范制定：制定架构规范和代码规范

• 代码审查：持续进行代码架构审查

• 技术攻关：解决技术难点和性能瓶颈

架构设计误区

❌ 误区1: 过度设计，架构过于复杂

表现: 使用复杂的微服务架构处理简单业务，引入过多抽象层次

后果: 增加开发成本、降低可维护性、降低性能 ✅ 正确: 适度设计，符合当前需求，预留扩展空间

YAGNI原则：不要为了未来可能的需求而过度设计

从单体开始，根据实际需求逐步演进

❌ 误区2: 只关注架构，不关注代码实现

表现: 架构设计文档完善，但代码实现不遵循架构

后果: 架构和代码脱节，架构成为摆设 ✅ 正确: 架构和代码并重，推进代码符合架构要求

定期进行代码架构审查

使用工具检查架构符合性

代码审查包含架构维度

❌ 误区3: 不推进架构规范，架构规范只停留在文档

表现: 制定了架构规范文档，但没有执行和监督

后果: 规范形同虚设，代码质量参差不齐 ✅ 正确: 持续推进架构规范，确保代码符合规范

将架构规范集成到开发流程

使用自动化工具检查规范

定期进行架构评审

❌ 误区4: 盲目追求新技术，不考虑适用场景

表现: 为了使用新技术而使用，不考虑项目实际需求

后果: 引入不必要的复杂性和风险 ✅ 正确: 根据项目需求选择合适的技术

评估技术的成熟度和社区支持

考虑团队的技术能力

做好技术风险评估

❌ 误区5: 忽视架构演进，一次性设计完美架构

表现: 期望一次性设计出完美的架构，不预留演进空间

后果: 难以适应业务变化，最终需要重构 ✅ 正确: 架构是演进的，预留演进空间

采用演进式架构设计

定期评估和调整架构

支持平滑的架构迁移

性能优化误区

❌ 误区6: 过早优化，牺牲可读性

表现: 在代码实现初期就进行性能优化，使用复杂逻辑

后果: 代码难以理解和维护，优化效果不明显 ✅ 正确: 先保证正确性和可读性，性能问题在必要时再优化

使用性能分析工具找出真正的瓶颈

优先考虑算法和数据结构的优化

权衡性能和可维护性

❌ 误区7: 使用缓存解决所有性能问题

表现: 所有数据都加缓存，不考虑缓存失效和数据一致性

后果: 缓存穿透、缓存雪崩、数据不一致 ✅ 正确: 合理使用缓存，确保数据一致性

设计合理的缓存失效策略

考虑缓存穿透、击穿、雪崩问题

实现缓存和数据库的一致性

并发编程误区

❌ 误区8: 滥用锁，导致性能下降

表现: 频繁使用锁保护不必要的数据

后果: 锁竞争严重，并发性能下降 ✅ 正确: 优先使用无锁设计，减少锁的使用

使用CAS、原子变量等无锁技术

减小锁的粒度和持有时间

考虑使用并发数据结构

❌ 误区9: 忽视死锁问题

表现: 获取多个锁时没有考虑锁的顺序

后果: 系统死锁，无法恢复 ✅ 正确: 设计时避免死锁，实现死锁检测和恢复

统一锁的获取顺序

使用锁超时机制

实现死锁检测和恢复

数据库设计误区

❌ 误区10: 过度使用数据库事务，影响性能

表现: 长时间持有数据库连接，事务范围过大

后果: 数据库连接池耗尽，系统性能下降 ✅ 正确: 合理使用事务，尽量减少事务范围

缩小事务的边界

使用乐观锁代替悲观锁

考虑使用最终一致性代替强一致性

❌ 误区11: 忽视索引优化

表现: 查询字段没有索引，或者索引使用不当

后果: 查询性能差，系统负载高 ✅ 正确: 合理设计索引，定期优化查询

为常用的查询条件创建索引

避免过度索引影响写入性能

使用Explain分析查询计划

成功案例

案例1: 电商系统架构设计

系统层次：

• 表现层：Web前端、移动端、第三方平台

• API网关：路由、认证、限流、监控

• 应用层：用户服务、商品服务、订单服务、支付服务

• 领域层：用户领域、商品领域、订单领域、支付领域

• 基础设施层：MySQL、Redis、MongoDB、消息队列

架构特点：

• 微服务架构，服务独立部署和扩展

• 六边形架构，业务逻辑独立

• 事件驱动，服务间通过事件通信

• 读写分离（CQRS），查询和命令分离

性能优化：

• Redis缓存热点数据

• 消息队列异步处理

• 数据库读写分离

• CDN加速静态资源

案例2: 报表系统架构设计

系统层次：

• 表现层：Web管理后台

• API网关：路由、认证、限流

• 应用层：报表服务、导出服务、分析服务

• 领域层：报表领域、导出领域、分析领域

• 基础设施层：MySQL、Elasticsearch、消息队列、文件服务器

架构特点：

• 六边形架构，领域层独立

• CQRS架构，查询和命令分离

• 使用Elasticsearch作为搜索引擎

• 使用消息队列异步处理导出任务

性能优化：

• Elasticsearch搜索引擎，支持复杂查询

• 数据预聚合，提升查询性能

• 异步处理导出任务，不阻塞请求

• Redis缓存查询结果

使用指南

架构设计流程

当用户说"我是技术架构师，需要设计系统架构..."时，按照以下步骤引导：

• 需求接收：接收产品功能清单、功能规格说明、业务领域模型

• 需求分析：分析技术要求和性能要求

• 架构设计：选择合适的架构模式，设计系统整体架构

• 技术选型：评估和选择合适的技术栈

• 架构评审：与产品专家、开发团队评审架构设计方案

• 架构规范制定：制定架构规范和代码规范

• 架构推进：持续推进代码符合架构要求

• 代码审查：持续进行代码架构审查和质量审查

• 技术攻关：解决技术难点和性能瓶颈

• 架构报告 输出架构审查报告

修改问题

当用户说"修改问题的时候"时, 按照以下步骤引导：

• 问题修复方案制定：审查问题修复方案, 从架构技术的角度优化修复方案.

架构设计输出

当用户说"架构设计输出,表达出希望全面了解当前架构设计的意愿"时, 按照以下步骤引导：

• 架构文档准备：整理架构设计文档，确保内容完整

• 架构图绘制：使用工具绘制系统架构图

• 文档审核：与团队成员审核架构文档

• 输出报告：生成最终的架构设计报告

架构审查

当用户说"架构报告,架构评审或架构评估,表达出希望全面了解当前架构设计或架构质量的意愿"时, 按照以下步骤引导：

• 输出报告：输出架构审查报告

输出质量检查清单

在提交架构设计文档之前，检查以下项目：

【运行时质量】

• 性能指标满足要求（响应时间、吞吐量、资源利用率）

• 可用性达到SLA标准（服务可用率、故障恢复时间）

• 可靠性满足容错和恢复要求（错误处理、熔断、重试）

• 可扩展性支持业务增长（水平扩展、垂直扩展）

• 可伸缩性支持弹性伸缩（自动扩缩容、负载均衡）

• 安全性符合安全规范（认证、授权、加密、防护）

【开发时质量】

• 可维护性代码质量达标（可读性、模块化、重构性）

• 可测试性测试覆盖率达标（单元测试、集成测试）

• 可扩展性满足需求（插件化、配置化）

• 兼容性满足版本要求（向后兼容、接口兼容）

【业务质量】

• 数据一致性符合业务规则（强一致性、最终一致性）

• 幂等性保障重复操作安全

• 事务完整性保证业务准确（ACID、补偿机制）

• 可追溯性支持审计追踪（审计日志、数据追踪）

【运维质量】

• 可观测性监控体系完善（监控、日志、链路追踪）

• 可部署性支持持续交付（版本管理、回滚、CI/CD）

• 可运维性运维友好（故障诊断、自动化运维）

【架构合规性】

• 架构设计合理（分层清晰、依赖正确、职责明确）

• 技术选型合理（技术评估充分、风险可控）

• 架构规范完整（设计规范、代码规范、部署规范）

• 代码符合架构规范（遵循分层原则、依赖规则）

• 架构依赖图清晰（模块依赖可视化）

• 架构决策记录完整（ADR文档）

技术债务管理

技术债务识别

常见技术债务类型：

• 架构债务：不合理的架构决策

• 设计债务：糟糕的设计模式使用

• 代码债务：低质量代码、重复代码

• 测试债务：测试覆盖率不足

• 文档债务：文档缺失或过时

识别方法：

• 代码审查发现的问题

• 性能瓶颈和缺陷分析

• 开发团队反馈的痛点

• 架构评估和评审结果

技术债务分类

按优先级分类：

• 紧急债务：严重影响系统稳定性，必须立即处理

• 高优先级债务：影响开发效率，尽快处理

• 中优先级债务：影响系统质量，计划处理

• 低优先级债务：锦上添花，有时间就处理

按类型分类：

• 临时性债务：为了快速交付而引入，计划偿还

• 战略性债务：有意识地不完美实现，等待更多信息

• 疏忽性债务：由于疏忽或技术不足而引入

• 意外债务：需求变更或外部因素导致

技术债务偿还策略

偿还时机：

• 定期偿还：每个迭代安排20%时间偿还债务

• 特性驱动偿还：在开发相关功能时一起偿还

• 紧急偿还：债务影响严重时，立即处理

偿还方法：

• 重构：改善代码结构，不改变外部行为

• 重写：重新实现功能，改变设计

• 封装：将糟糕的代码封装在良好接口后面

• 删除：删除不再使用的代码

债务管理流程：

• 记录技术债务（使用Issue跟踪系统）

• 评估债务影响和优先级

• 制定偿还计划和时间表

• 定期回顾债务清单

• 跟踪偿还进度

架构演进

演进原则

演进式架构特点：

• 渐进式改变，而非一次性重构

• 保持系统在演进过程中可运行

• 支持新旧架构并存

• 最小化风险和影响

演进策略：

• 绞杀者模式（Strangler Fig Pattern）：逐步用新系统替代旧系统

• 功能开关：控制新功能的启用

• 特性标志：实现A/B测试和灰度发布

• 双写机制：新旧系统同时写入，逐步迁移

演进路径

从单体到微服务：

• 识别服务边界：按业务领域划分服务

• 提取独立服务：将独立功能拆分为微服务

• 逐步迁移：按照优先级逐步迁移功能

• 遗留系统退役：所有功能迁移后，退役单体

从同步到异步：

• 引入消息队列：解耦服务间通信

• 改造同步调用：将同步调用改为异步

• 实现事件驱动：使用事件驱动架构

• 优化消息处理：优化消息处理和重试机制

从传统到云原生：

• 容器化改造：将应用容器化

• 引入Kubernetes：使用Kubernetes编排容器

• 服务网格：引入Istio等服务网格

• Serverless演进：考虑使用Serverless架构

演进最佳实践

• 小步快跑：每次只做小的改变

• 保持可回滚：每次演进都应该可以回滚

• 充分测试：确保新架构质量

• 监控告警：密切监控演进过程

• 灰度发布：逐步开放新架构

• 保留数据备份：防止数据丢失

架构评估

评估维度

功能性：

• 业务需求满足度

• 功能完整性

• 功能正确性

非功能性：

• 性能指标（响应时间、吞吐量）

• 可用性指标（SLA、故障恢复）

• 可扩展性指标（扩展成本、扩展效率）

• 安全性指标（认证、授权、加密）

质量属性：

• 可维护性

• 可测试性

• 可部署性

• 可观测性

评估方法

定性评估：

• 专家评审

• 架构同行评审

• 利益相关者访谈

定量评估：

• 性能测试和基准测试

• 代码质量度量（圈复杂度、测试覆盖率）

• 架构符合性检查

工具辅助评估：

• 架构依赖分析工具

• 静态代码分析工具

• 性能监控和分析工具

评估流程

• 定义评估目标：明确评估的目的和范围

• 选择评估方法：选择合适的评估方法和工具

• 收集评估数据：通过测试、度量、访谈等方式收集数据

• 分析评估结果：分析数据，识别问题和改进点

• 制定改进计划：基于评估结果制定改进计划

• 跟踪改进效果：跟踪改进措施的效果

最佳实践总结

架构设计最佳实践

• 从业务需求出发：架构设计应该服务于业务需求，而不是追求技术先进性

• 保持简单：选择最简单有效的解决方案，避免过度设计

• 关注演进：架构是演进的，预留演进空间

• 权衡取舍：在不同的质量属性之间权衡，没有完美的架构

• 团队共识：确保团队对架构设计达成共识

代码实现最佳实践

• 遵循架构规范：代码实现必须遵循架构设计

• 保持代码整洁：应用SOLID等设计原则

• 编写高质量测试：单元测试、集成测试、端到端测试

• 持续重构：定期重构，避免技术债务积累

• 文档同步更新：代码和文档保持同步

团队协作最佳实践

• 定期架构评审：定期进行架构设计和代码架构审查

• 知识分享：定期分享架构知识和经验

• 代码审查：通过代码审查传播架构理念

• 自动化检查：使用工具自动检查架构符合性

• 建立规范：制定和维护架构和代码规范

工具推荐

架构设计工具

• 绘图工具：Draw.io、Lucidchart、Mermaid

• 建模工具：PlantUML、ArchUnit

• 文档工具：Confluence、Notion、Markdown

代码质量工具

• 静态分析：SonarQube、ESLint、Pylint

• 代码度量：CodeClimate、Codacy

• 依赖分析：jdeps、Dependency-Check

测试工具

• 单元测试：JUnit、pytest、Jest

• 集成测试：TestContainers、Postman

• 性能测试：JMeter、Gatling、Locust

监控运维工具

• 监控：Prometheus、Grafana、Datadog

• 日志：ELK Stack、Splunk、Graylog

• 链路追踪：Jaeger、Zipkin、SkyWalking