技术架构（Technology Architecture）

定义与目标

技术架构关注支持应用运行的基础设施、平台与通用技术能力，确保系统满足性能、可用性、安全与成本等非功能性要求。

技术架构不是中间件选型清单。它要把业务和应用提出的质量要求翻译成可运行、可扩展、可治理的技术底座，包括容量、性能、稳定性、安全、可观测性、发布和成本。

主要内容

• 计算、存储、网络与云基础设施
• 平台服务（PaaS）：容器、服务网格、消息中间件、缓存、数据库
• 安全架构与零信任（IAM、密钥管理、WAF、SIEM）
• 可观测性平台（日志、指标、追踪）
• 弹性与灾备（多活、容灾、备份恢复）
• 性能与容量规划
• 成本优化与FinOps

关键工件

• 技术标准与基线（OS/中间件/数据库）
• 平台能力目录与SLA/SLO
• 安全策略与合规控制
• 可观测性策略与运维手册
• 弹性与灾备方案

方法与步骤（ADM Phase D）

1. 明确技术约束与原则
2. 评估基线技术架构与平台现状
3. 设计目标技术蓝图与服务目录
4. 非功能性需求与容量规划
5. 安全与合规控制设计
6. 差距分析与迁移路线图

架构风格

• 云原生：容器编排、微服务、服务网格
• 事件驱动与流式处理
• 边缘计算与物联网
• 数据密集型与AI平台

例子：大促下单链路的技术支撑

零售大促场景中，业务目标是承接短时间高并发下单，应用架构里可能已经拆出商城、订单中心、库存中心、支付和物流。技术架构要进一步回答这些系统如何稳定运行。

技术能力	作用	设计关注点
网关与限流	保护后端系统，控制入口流量	用户维度、接口维度、活动维度的限流策略
缓存	降低热点商品、活动配置、会员权益查询压力	缓存一致性、过期策略、热点保护、穿透防护
消息队列	削峰解耦，异步处理库存、通知、积分等链路	幂等、顺序、重试、死信、积压监控
数据库	承载订单、支付、库存等核心状态	分库分表、索引、事务边界、备份恢复
可观测性	快速发现和定位故障	指标、日志、链路追踪、告警和值班机制
安全与审计	保护用户、交易和运营数据	身份认证、权限控制、敏感数据脱敏、操作审计

这里的关键不是“用了 Redis、Kafka、MySQL 就算技术架构完成”，而是说明为什么需要这些能力、它们如何配合、容量如何估算、失败时如何降级和恢复。

容量和并发不是拍脑袋

技术架构中的容量规划通常要从业务指标反推：

1. 预计峰值用户数、访问路径和转化率。
2. 估算核心接口 QPS，例如商品详情、库存查询、下单、支付回调。
3. 区分读多写少、强一致写入、异步处理和离线分析。
4. 根据链路瓶颈设计缓存、限流、队列、数据库拆分和水平扩展。
5. 用压测验证假设，再把压测结果反馈到容量模型。

例如峰值下单 QPS 是 2000，并不代表所有服务都按 2000 等比例扩容。商品详情可能是 10 倍以上读流量，库存锁定需要更严格的一致性，积分发放可以异步，短信通知可以削峰排队。技术架构要把这些差异设计出来。

最佳实践

• 平台化能力复用，提升交付效率
• 自动化与基础设施即代码（IaC）
• 标准化与SLO驱动的运行治理
• 成本、性能、安全三者平衡

总结

技术架构为业务与应用提供可持续的技术底座。它的重点不是列工具，而是把性能、稳定、安全、成本和可运维性落实到平台能力、技术标准、容量模型和治理机制上。