# 架构师

> 所属公司：瑞来兹软件技术有限公司
> 更新日期：2026-05-04

---

## 一、角色定义

架构师（Architect）是技术方向的掌舵者，负责系统架构设计、技术选型、非功能需求保障（性能/安全/可扩展性），并在关键决策上提供技术判断力。按领域可细分为：系统架构师、应用架构师、数据架构师、安全架构师、解决方案架构师。

---

## 二、主要职责

### 2.1 架构设计
- 设计系统整体架构（微服务/单体/混合），产出架构图
- 定义模块边界、服务拆分、接口契约（API 设计）
- 制定技术选型标准（语言、框架、中间件、数据库）
- 设计数据架构：数据模型、分库分表策略、读写分离
- 设计部署架构：K8s 集群规划、网络拓扑、容灾方案

### 2.2 技术规范
- 制定编码规范、分支管理策略（Git Flow / Trunk-Based）
- 定义 API 设计规范（RESTful / GraphQL / gRPC）
- 建立技术雷达（Tech Radar），跟踪新兴技术
- 制定安全编码规范（OWASP Top 10 防护）
- 编写架构决策记录（ADR）

### 2.3 非功能需求保障
- 性能优化：系统吞吐量、响应时间、并发能力
- 高可用设计：多活/主备、故障转移、降级熔断
- 安全架构：认证授权（OAuth2.0/OIDC）、数据加密、审计日志
- 可扩展性：水平扩展策略、CQRS、事件驱动
- 可观测性：日志、指标、链路追踪（OpenTelemetry）

### 2.4 技术评审与治理
- 主持技术方案评审会，评估方案可行性
- 核心模块代码审查，确保架构一致性
- 识别技术债务，制定偿还计划
- 参与技术委员会，制定长期技术战略

### 2.5 团队赋能
- 指导高级开发工程师，提升团队技术水位
- 定期组织技术分享会（Tech Talk）
- 编写架构文档，降低系统认知负荷
- 帮助团队攻克技术难题（攻关）

---

## 三、常用平台与工具

| 分类 | 工具 | 用途 |
|------|------|------|
| **架构设计** | Draw.io | 架构图、流程图、网络拓扑 |
| | PlantUML | 代码生成 UML 图 |
| | C4 Model / Structurizr | 分层架构可视化 |
| | Excalidraw | 手绘风格架构草图 |
| | ArchiMate | 企业架构建模 |
| **技术文档** | Confluence / Notion | 架构文档协作 |
| | ADR Tools | 架构决策记录管理 |
| | Markdown + Git | 轻量文档版本管理 |
| **中间件与基础设施** | Kubernetes (K8s) | 容器编排 |
| | Istio / Linkerd | 服务网格 |
| | Nacos / Consul | 服务注册与配置 |
| | Redis | 缓存 / 分布式锁 |
| | Kafka / RocketMQ / RabbitMQ | 消息队列 |
| | Nginx / APISIX / Kong | API 网关 |
| | Elasticsearch | 搜索与分析引擎 |
| **数据库** | MySQL / PostgreSQL | 关系型数据库 |
| | MongoDB | 文档型 NoSQL |
| | TiDB / CockroachDB | 分布式 SQL |
| | ClickHouse / Doris | OLAP 分析 |
| **监控与可观测** | Prometheus + Grafana | 监控与可视化 |
| | ELK（Elasticsearch + Logstash + Kibana） | 日志管理 |
| | SkyWalking / Jaeger / Zipkin | 链路追踪 |
| | Sentry | 错误追踪 |
| **CI/CD** | Jenkins / GitLab CI / GitHub Actions | 流水线 |
| | ArgoCD | GitOps 部署 |
| | Docker / Containerd | 容器化 |
| **安全** | SonarQube | 代码安全扫描 |
| | Vault | 密钥管理 |
| | OWASP ZAP | 安全测试 |

---

## 四、架构设计原则

```
1. KISS（Keep It Simple, Stupid）—— 简单优于复杂
2. YAGNI（You Aren't Gonna Need It）—— 不为未来过度设计
3. 高内聚低耦合 —— 模块内紧密关联，模块间松散依赖
4. 关注点分离（Separation of Concerns）
5. 面向失败设计（Design for Failure）
6. 无状态优先 —— 有状态服务需特殊设计
7. 数据一致性权衡 —— CAP 取舍、最终一致性
8. API First —— 先定义接口，再实现
9. 12-Factor App —— 云原生应用方法论
10. 安全左移（Shift Left on Security）
```

---

## 五、能力模型

| 能力 | 要求 |
|------|------|
| 系统设计 | 分布式系统、微服务、领域驱动设计（DDD） |
| 技术广度 | 多语言/多框架/多数据库经验 |
| 抽象思维 | 从业务需求抽象架构模型 |
| 决策能力 | 技术选型与权衡（Trade-off）分析 |
| 沟通表达 | 能用图/文档清晰传达架构意图 |
| 业务理解 | 理解业务战略，支撑业务扩展 |
| 领导力 | 技术驱动，不依赖职级 |

---

## 六、产出物清单

| 产出物 | 交付节点 |
|--------|----------|
| 系统架构设计文档 | 项目启动阶段 |
| 技术选型报告 | 方案评审 |
| API 设计规范 | 编码前 |
| 数据库 ER 图与表设计 | 编码前 |
| 部署架构图 | 上线前 |
| 架构评审记录 | 每次评审 |
| ADR（架构决策记录） | 关键决策时 |
| 性能压测报告 | 上线前 |
| 技术雷达 | 季度 |
