规划 IT 架构：减少依赖，明确决策

架构既描述系统，也明确责任

架构决定数据存放在哪里、应用如何通信，以及发生故障时如何处理。这些选择决定了新功能能否直接实现，还是必须先协调五家供应商和三套数据。堆满流行产品名称的架构图，并不能回答这些问题。

简单不等于只用一台服务器，也不等于不计代价地减少技术。增加备份或第二台应用服务器可能有充分理由。复杂性真正成为问题，是在收益不明确、无人维护，或直到事故发生才暴露依赖关系的时候。

从三个具体业务流程入手

梳理咨询处理、订单履行和发票开具等流程，追踪涉及的应用、身份认证、存储及外部接口。也要纳入邮件附件、电子表格和人工转录；仅有服务器清单会遗漏这些造成延迟的环节。

把要求说具体：维护期间，咨询能否等待十分钟？断网时员工是否必须继续工作？预计同时在线多少用户？哪些信息可以稍后到达？这些答案比一律“全部上云”或“全部放在办公室”的规则，更有助于规划托管、同步和冗余。

什么情况下新增组件值得其运维成本

每个组件都需要可衡量的启用条件和运维负责人。如果缓存只节省几毫秒，却因过期内容反复带来支持工作，就应重新评估。如果某项数据导入会在办公时间阻塞整个应用，将其分离出来便可能有明确收益。

• 缓存：应由重复读取造成的实测延迟来证明必要性；明确有效期、刷新机制和故障处理方式。
• 队列：避免缓慢的后台任务阻塞请求；处理重试、顺序和失败任务。
• 独立服务：适用于独立发布或容量需求显著不同的情况；明确其接口、数据和监控责任。
• 第二站点：用于满足单个站点失效后业务仍可运行的要求；定期测试复制、故障切换和切回。

单体和微服务不是质量等级

模块化应用可以拥有清晰的业务边界，并作为一个整体部署。分布式系统也可能高度耦合。正如 Microsoft 的架构比较所说明，微服务支持独立开发和扩缩容，但也增加通信、一致性和运维要求。

一起发布的小团队，可能更适合模块化单体，在客户、订单和计费之间保持清楚的接口。当图片处理的负载独立增长时，再引入单独的图片处理服务。容器可以打包这两种架构；采用容器并不意味着必须把应用拆成微服务。

示例：客户门户、库存系统和财务系统

让新门户直接写入库存和财务数据库，虽然看似省事，却会让它的发布依赖两套外部数据结构。任一产品更新，都可能意外中断客户流程。

更清楚的设计，是指定库存系统管理日常业务客户记录，财务系统管理已入账单据，门户管理登录数据和显示偏好。通过约定接口传递必要信息。有需要时显示数据更新时间，而不是承诺实际上无法保证的实时数据。

这样的分离也需要投入：维护接口版本、及时呈现传输失败，并明确处理重试。对于小型内部工具，较简单且有文档的只读接口可能已经足够。应根据变更需求、故障后果和团队能力决定。

记录决策，并比较完整运维成本

架构决策记录（ADR）记载一项决策、背景、备选方案和后果，并应允许明确地被新决策取代。AWS 的 ADR 流程描述了这一生命周期；保留决策理由比文档篇幅更重要。

门户的决策记录可以说明：客户资料仍由库存系统管理，因为其员工负责维护权威记录；门户只显示有约定延迟的同步只读视图。当客户需要自行提交具有约束力的变更时，再重新审视这一选择。

在相同期间和要求下，比较实施、基础设施、许可证、支持、入职培训和退出成本。如果每次调整都需要稀缺专家，廉价托管也可能十分昂贵。托管平台可以减少工作，但可能引入合同和数据导出方面的依赖。

用具体证据开展架构评审

先准备三个视图：跨系统的用户流程、重要数据的责任归属，以及跨站点或供应商的部署关系。标明每条连接的目的和方向。对未知的交接环节明确提出问题，不要用一张貌似完整的架构图掩盖知识缺口。

补充近期相关变更和事故：哪个依赖让团队措手不及？哪些地方需要多个团队同时行动？什么造成了反复的人工工作？据此确定少量理由充分的改进，而不是凭个人技术偏好替换整个环境。

用三个演示验证目标方案

验证可变更性时，追踪一项典型业务变更经过的组件、人员、人工步骤和审批时间。验证恢复能力时，在合适环境中测试重要流程的预期降级或恢复方式。验证交接时，让第二个人只依靠文档完成一项日常任务。

先约定成功标准，例如响应时间、恢复窗口，或无需询问原开发者即可完成发布。标准必须符合业务情况。目标是针对已经观察到的约束取得进展，而不是获得某种通用架构评分。

制定带有触发条件的路线图

不必立刻实现所有可能的扩展。先保障稳定运行，再将后续投入与可测量的条件关联。后台任务反复超过响应时间目标时，将其分离；即便流量不高，只要流程要求能够承受站点失效，就应考虑第二站点。

为每项决策指定负责人和复审触发条件：营业时间变化、用户显著增加、新增数据类别、合同即将到期，或事故反复发生。这些条件比任意规定每隔几年全部重做，更能说明投资理由并保留未来选择。