编程即设计，代码即架构。
架构面对的问题是什么
架构，这个词比较神秘，以致于很多程序员望而却步，以为要什么了不得的本事。 确实的，架构设计是一种高远的目标，但千里之行，始于足下。
架构的目标是什么呢？代码，实现所需服务；架构，致力于以更低成本、更高效率、更高质量地实现所需服务。架构，是兼顾质量、效率与成本的魔法。 但架构并不研究如何实现具体服务，—— 它研究的是如何妥善安置那些实现服务的构件，管理依赖、边界和变化。
-
如何确定系统的关键质量因素？如何达成这些关键质量？
-
如何识别系统的核心资产和不变量？ 如何将系统的核心资产与不变量分离出来，沉淀为稳定的组件？
-
如何识别组件所在的边界和上下文？ 如何管理各种边界和上下文 ？ 如何管理组件之间的依赖 ？
-
如何让变化更容易显露和识别 ？ 如何管理多维度的变化 ？
-
如何让变化的实现成本更小？
架构的目标是什么
小问题小设计，大问题大架构。架构听上去高大上，实际上也是为了解决问题的。不过，架构与程序不同，是在不同层次上求解问题。
架构设计是宏观性考量，在整体上理解问题的复杂性，给出方案，并论证方案的可行性，提供一系列准则指导执行。缺乏架构设计而直接着手处理问题，会出现三个严重问题：
-
在遇到实质性难题时，会一筹莫展或反复折腾，一次次返工，耗费大量的人力和成本；
-
缺乏质量的考量，上线后发现无法满足用户的需要；
-
缺乏整体的考虑，在业务发展的时候，原有实现不具扩展性，无法敏捷地支持中期和长远目标。
因此，架构的目标主要有三个：
-
提前识别问题的复杂性和关注点，提供可行的经过论证的解决方案；
-
建立服务质量指标，确定设计方案可以满足指定的质量指标；
-
规划整体设计，提供长远的可扩展性。
要实现架构目标，先要问：要解决的问题是什么？问题的复杂性在哪里？弄清楚目标和靶点，才能一击命中。
关键架构特征
做架构设计，首要的是确定系统的关键架构特征。 比如入侵检测系统的架构特征是：
准确丰富有效
- 准确检测出入侵告警与事件，减少误报，减少无用信息的干扰；
- 提供足够丰富的信息进行入侵事件分析。
性能与及时性
- 能够及时上报入侵事件行为，低延迟。 如果不能及时上报，就会错过最佳处理时机。
- 能够及时阻断恶意行为。
易用性
- 提供有效的方法和建议进行入侵事件分析与处理；
- 用户能够熟练使用系统提供的功能进行入侵检测分析与处理；
- 避免用户误操作影响业务。
稳定性
- 在关键时刻（比如护网期间、黑客发起大量攻击的情形下）能够保证系统的稳定流畅使用。
安全性
- 要保证入侵检测系统本身的安全性。如果入侵检测系统本身被攻陷，那么黑客就可以无所顾忌地干活了。
可扩展能力
- 低成本地添加新入侵告警的检测和响应能力，快速迭代入侵检测能力。低成本指所需要的开发量及开发时间。
高可用与可伸缩能力
- 只要不是所有机器都挂掉了，服务就是可用的；
- 可以方便地扩容，增加系统处理能力，提升及时性。
做架构设计，会面对相当多的非常烧脑的问题。技术问题、设计问题、各种复杂依赖和实现细节交织在一起，必须非常非常有耐心和细致地去攻克难点、解决问题。
记录架构与技术决策
可以使用 ADR 来记录和交流架构决策。比如：
| 编号 | 标题（Title） | 状态（Status） | 语境（Context） | 决策（Decision） | 后果（Consequence） | 遵循方式（Compliance） |
|---|---|---|---|---|---|---|
| 3 | 使用事件组件编排框架来实现入侵检测处理流程 | Accepted | 不同入侵检测流程有很多相似之处，符合模板和编排的特征。 | 将入侵检测包装成检测插件，将检测子流程逻辑包装成流程组件，再使用编排框架来实现入侵事件处理流程 | 对于典型流程，有更强的灵活性，大幅减少开发成本； 对于非典型流程，可以支持自定义流程，使事件处理流程更清晰可维护；可以支持复杂流程。 | 1. 定义入侵检测插件接口，具体检测插件必须实现该接口； 2. 定义流程组件接口，具体流程组件必须实现该接口； 3. 单一事实原则，每个流程组件的职责明晰单一； 4. 增强组件编排能力，而不是硬编码逻辑。 |
如何衡量一个架构设计
如何衡量一个架构设计的实际效果？灵魂拷问来了：
-
是不是有针对性地解决了问题固有的复杂性？ 通过提供渐进稳定的领域模型，让问题理解、描述和求解都更清晰自然了；
-
是不是令需求更快地实现，大幅降低了开发成本？ 比如原来要花时间修改代码、测试、发布系统，后续只要新增配置，测试并刷新配置就搞定了；原来需要5人日，现在只需要 2人时；
-
是不是让系统的依赖更清晰了？比如原来你调我我调你，乱成一团，现在能够清晰地看到数据流在各个模块的流通和流向、脉络；
-
是不是更稳定了？比如原来磕磕碰碰，做百次操作就有一次失败，现在做百万次操作才有一次失败；
-
是不是更容易操作了？比如原来需要ABCDE五步操作，现在一键无忧完成；
-
是不是足够有弹性和灵活性，可以支撑数年的业务发展？ 比如原来遇到新业务就要做许多兼容，现在只要配置一些规则、流程就能适应新业务的发展。对新增开放，对修改关闭。
综上所述，架构设计至少有几个方面可以衡量：
-
识别出问题的关键复杂性，建立稳定有效的领域模型。
-
大幅降低开发与维护成本。 可以落定到人力与时间。
-
系统脉络更清晰。可以绘制出系统模块的依赖图，通过依赖图的节点与节点链接数量来判断。
-
更稳定。操作失败、出现各种问题的比率大幅降低。
-
更容易操作。 操作的步骤数 乘以 操作失败的比率。
-
弹性和灵活性。 支持新业务的难度，以新增代码量和修改代码量来衡量。
小结
好的开始是成功的一半。要开启系统设计之路，就需要从最基本的层面着手和理解。意识到现实问题的复杂性，理解架构设计所面对的问题、目标以及衡量方式，才能真正有效地运用架构手段去解决问题。否则，就很容易设计出看上去漂亮优雅、似乎很可行但实际上却不堪用的架构。
