很多团队把架构评审当成一次性的闸门：确定服务边界、选定通信方式、画完拓扑图，项目就进入实现阶段。但架构的适配度并不会因此永久保持不变。监管规则会调整，技术栈会升级，市场需求会转向，团队组织也会变化。即使当初没有做错决定，一套曾经合适的设计也可能在一段时间后悄悄失配。
这本小书通过上下文存储、网关和系统拓扑等主题，讨论架构如何成为一种持续进行的社会技术实践。重点不只是“选什么架构”，而是团队如何主动塑造摩擦、适配度和交付流动。
适配度会随时间移动
架构适配度不是一个静态标签。它更像当前环境下的一组约束函数：
- 业务变化：产品从低频后台任务转向实时交互，原有批处理设计可能不再合适。
- 监管变化：数据驻留、审计、隐私或行业合规要求，可能改变数据存储和调用边界。
- 技术变化：基础设施、云服务和开源组件的能力不断变化，原来的自建方案可能变得昂贵。
- 组织变化：团队拆分、合并或职责调整，会改变服务边界和系统所有权。
- 运营变化：流量、故障模式和性能目标变化后，原本简单的同步调用链可能成为瓶颈。
因此，架构决策应该带有时间和上下文。与其记录“系统采用微服务”，不如记录“在当前团队规模、流量、合规要求和交付目标下，为什么采用这些服务边界”。这让团队能够在条件变化时重新评估，而不是把历史决定误认为永恒原则。
让上下文成为架构资产
上下文存储不只是文档目录，也可以是架构决策的可检索记录。它应该回答几个实际问题：
- 当前系统受到哪些业务、技术和监管约束？
- 哪些决策已经确定，哪些仍然是假设？
- 每个关键决策由谁负责，在什么条件下需要重新审视？
- 哪些摩擦是有意保留的，哪些摩擦正在阻碍交付？
可以这样实践：用一份轻量的 YAML 文件维护架构上下文，再让评审或自动化工具检查决策是否过期。下面是一个可直接改造的最小示例。
将内容保存为 architecture-context.yaml，再用 Python 标准库读取它：
system: order-platform
reviewed_at: 2025-01-15
constraints:
- name: data_residency
statement: Customer order data must remain in the EU region.
owner: compliance-team
- name: delivery_speed
statement: Product teams release independently at least weekly.
owner: platform-team
decisions:
- id: api-gateway
choice: Central gateway for authentication, rate limiting, and routing.
rationale: Keep cross-cutting controls consistent while services evolve.
revisit_when:
- service teams need independent edge policies
- gateway changes become a weekly release bottleneck
- id: order-events
choice: Asynchronous events for downstream notifications.
rationale: Avoid coupling order completion to email and analytics latency.
revisit_when:
- consumers require strict read-after-write behavior
- event delivery needs exceed current operational capacity
from pathlib import Path
import yaml
context = yaml.safe_load(Path("architecture-context.yaml").read_text())
print(f"System: {context['system']}")
print(f"Last reviewed: {context['reviewed_at']}")
for decision in context["decisions"]:
print(f"[{decision['id']}] {decision['choice']}")
print(" Revisit when:")
for condition in decision["revisit_when"]:
print(f" - {condition}")
运行前安装 PyYAML：
python -m pip install pyyaml
python inspect_context.py
这个例子的关键不在文件格式，而在于把“重新评估条件”写下来。没有触发条件的架构决策，很容易在团队交接后变成没人敢碰的黑盒。
网关和拓扑：控制摩擦的两个杠杆
网关常被当作统一鉴权、限流和路由的基础设施，但它同时也是组织边界和变更边界。集中式网关可以让安全策略一致，降低重复实现的成本；然而，所有团队都依赖同一个网关时，网关团队可能成为发布瓶颈，或者把本应由业务服务负责的逻辑不断吸收进去。
一种更稳妥的做法是明确网关的职责：
- 适合集中处理：身份验证、基础限流、协议转换、统一可观测性。
- 谨慎集中处理：复杂业务授权、领域编排、面向单个产品的特殊规则。
- 需要持续观察：配置变更速度、故障影响范围、服务团队的独立交付能力。
系统拓扑也不应只是一张静态图。拓扑描述了调用方向、数据流和故障传播路径，而这些内容会随部署方式、团队责任和业务流量改变。评审拓扑时，可以围绕几个问题展开：
- 哪些调用必须同步，哪些可以通过事件解耦？
- 一个下游故障会影响多少上游用户路径？
- 谁负责每条关键链路的容量、告警和恢复？
- 一个小改动需要跨越多少团队和发布队列？
这里的“摩擦”并不总是坏事。审计审批、数据隔离和安全检查会增加变更步骤，但它们可能是必要的控制。真正需要减少的是没有带来风险降低、却持续拖慢反馈的摩擦，例如重复审批、无人维护的共享组件或模糊的服务所有权。
用反馈循环代替架构崇拜
架构治理的目标不是让每个决定都经过更长的审批流程，而是让团队更早看到失配信号。可以建立一组低成本的反馈指标：
- 架构变更从提出到上线需要多久？
- 一次跨团队变更需要协调多少个队列？
- 网关或共享平台故障影响了多少业务路径？
- 关键决策有多久没有被重新验证？
- 线上事故是否反复暴露同一条拓扑或所有权问题？
这些指标不能单独证明某种架构更好，但能帮助团队发现流动性下降的地方。架构评审也可以从“这张图是否漂亮”转向“系统是否仍然支持当前目标”。
落地清单
采用这种演进式视角时，可以从小范围开始：
- 为关键架构决策补充背景、取舍和重新评估条件。
- 每次重大监管、市场或组织变化后，重新检查架构约束。
- 给网关定义明确的职责边界，并监控它是否成为交付瓶颈。
- 把拓扑、调用链、数据流和团队所有权放在同一场评审中讨论。
- 区分必要控制与无效摩擦，不要为了“简化”而删除真正的安全边界。
- 用交付、故障和变更反馈推动架构调整，而不是追逐某种流行拓扑。
好的架构不是永远不需要修改的架构，而是能够在环境变化时被看见、被讨论并逐步调整的架构。把架构当作社会技术实践，意味着同时关注代码、基础设施、规则、团队关系和反馈速度。系统的长期适配度，最终取决于这些因素能否一起演进。