架构设计开篇:架构设计的目标与衡量

编程即设计,代码即架构。架构面对的问题是什么 架构,这个词比较神秘,以致于很多程序员望而却步,以为要什么了不得的本事。 确实的,架构设计是一种高远的目标,但千里

编程即设计,代码即架构。

架构面对的问题是什么

架构,这个词比较神秘,以致于很多程序员望而却步,以为要什么了不得的本事。 确实的,架构设计是一种高远的目标,但千里之行,始于足下。

架构的目标是什么呢?代码,实现所需服务;架构,致力于以更低成本、更高效率、更高质量地实现所需服务。架构,是兼顾质量、效率与成本的魔法。 但架构并不研究如何实现具体服务,—— 它研究的是如何妥善安置那些实现服务的构件,管理依赖、边界和变化。

  • 如何确定系统的关键质量因素?如何达成这些关键质量?

  • 如何识别系统的核心资产和不变量? 如何将系统的核心资产与不变量分离出来,沉淀为稳定的组件?

  • 如何识别组件所在的边界和上下文? 如何管理各种边界和上下文 ? 如何管理组件之间的依赖 ?

  • 如何让变化更容易显露和识别 ? 如何管理多维度的变化 ?

  • 如何让变化的实现成本更小?


架构的目标是什么

小问题小设计,大问题大架构。架构听上去高大上,实际上也是为了解决问题的。不过,架构与程序不同,是在不同层次上求解问题。

架构设计是宏观性考量,在整体上理解问题的复杂性,给出方案,并论证方案的可行性,提供一系列准则指导执行。缺乏架构设计而直接着手处理问题,会出现三个严重问题:

  • 在遇到实质性难题时,会一筹莫展或反复折腾,一次次返工,耗费大量的人力和成本;

  • 缺乏质量的考量,上线后发现无法满足用户的需要;

  • 缺乏整体的考虑,在业务发展的时候,原有实现不具扩展性,无法敏捷地支持中期和长远目标。


因此,架构的目标主要有三个:

  • 提前识别问题的复杂性和关注点,提供可行的经过论证的解决方案;

  • 建立服务质量指标,确定设计方案可以满足指定的质量指标;

  • 规划整体设计,提供长远的可扩展性。

要实现架构目标,先要问:要解决的问题是什么?问题的复杂性在哪里?弄清楚目标和靶点,才能一击命中。


关键架构特征

做架构设计,首要的是确定系统的关键架构特征。 比如入侵检测系统的架构特征是:

准确丰富有效

  • 准确检测出入侵告警与事件,减少误报,减少无用信息的干扰;
  • 提供足够丰富的信息进行入侵事件分析。

性能与及时性

  • 能够及时上报入侵事件行为,低延迟。 如果不能及时上报,就会错过最佳处理时机。
  • 能够及时阻断恶意行为。

易用性

  • 提供有效的方法和建议进行入侵事件分析与处理;
  • 用户能够熟练使用系统提供的功能进行入侵检测分析与处理;
  • 避免用户误操作影响业务。

稳定性

  • 在关键时刻(比如护网期间、黑客发起大量攻击的情形下)能够保证系统的稳定流畅使用。

安全性

  • 要保证入侵检测系统本身的安全性。如果入侵检测系统本身被攻陷,那么黑客就可以无所顾忌地干活了。

可扩展能力

  • 低成本地添加新入侵告警的检测和响应能力,快速迭代入侵检测能力。低成本指所需要的开发量及开发时间。

高可用与可伸缩能力

  • 只要不是所有机器都挂掉了,服务就是可用的;
  • 可以方便地扩容,增加系统处理能力,提升及时性。

做架构设计,会面对相当多的非常烧脑的问题。技术问题、设计问题、各种复杂依赖和实现细节交织在一起,必须非常非常有耐心和细致地去攻克难点、解决问题。


记录架构与技术决策

可以使用 ADR 来记录和交流架构决策。比如:

编号 标题(Title) 状态(Status) 语境(Context) 决策(Decision) 后果(Consequence) 遵循方式(Compliance)
3 使用事件组件编排框架来实现入侵检测处理流程 Accepted 不同入侵检测流程有很多相似之处,符合模板和编排的特征。 将入侵检测包装成检测插件,将检测子流程逻辑包装成流程组件,再使用编排框架来实现入侵事件处理流程 对于典型流程,有更强的灵活性,大幅减少开发成本; 对于非典型流程,可以支持自定义流程,使事件处理流程更清晰可维护;可以支持复杂流程。 1. 定义入侵检测插件接口,具体检测插件必须实现该接口; 2. 定义流程组件接口,具体流程组件必须实现该接口; 3. 单一事实原则,每个流程组件的职责明晰单一; 4. 增强组件编排能力,而不是硬编码逻辑。

如何衡量一个架构设计

如何衡量一个架构设计的实际效果?灵魂拷问来了:

  • 是不是有针对性地解决了问题固有的复杂性? 通过提供渐进稳定的领域模型,让问题理解、描述和求解都更清晰自然了;

  • 是不是令需求更快地实现,大幅降低了开发成本? 比如原来要花时间修改代码、测试、发布系统,后续只要新增配置,测试并刷新配置就搞定了;原来需要5人日,现在只需要 2人时;

  • 是不是让系统的依赖更清晰了?比如原来你调我我调你,乱成一团,现在能够清晰地看到数据流在各个模块的流通和流向、脉络;

  • 是不是更稳定了?比如原来磕磕碰碰,做百次操作就有一次失败,现在做百万次操作才有一次失败;

  • 是不是更容易操作了?比如原来需要ABCDE五步操作,现在一键无忧完成;

  • 是不是足够有弹性和灵活性,可以支撑数年的业务发展? 比如原来遇到新业务就要做许多兼容,现在只要配置一些规则、流程就能适应新业务的发展。对新增开放,对修改关闭。


综上所述,架构设计至少有几个方面可以衡量:

  • 识别出问题的关键复杂性,建立稳定有效的领域模型。

  • 大幅降低开发与维护成本。 可以落定到人力与时间。

  • 系统脉络更清晰。可以绘制出系统模块的依赖图,通过依赖图的节点与节点链接数量来判断。

  • 更稳定。操作失败、出现各种问题的比率大幅降低。

  • 更容易操作。 操作的步骤数 乘以 操作失败的比率。

  • 弹性和灵活性。 支持新业务的难度,以新增代码量和修改代码量来衡量。


小结

好的开始是成功的一半。要开启系统设计之路,就需要从最基本的层面着手和理解。意识到现实问题的复杂性,理解架构设计所面对的问题、目标以及衡量方式,才能真正有效地运用架构手段去解决问题。否则,就很容易设计出看上去漂亮优雅、似乎很可行但实际上却不堪用的架构。


参考资料

您可能有感兴趣的文章
【架构】架构设计的三原则

软件设计入门1 架构设计

好的软件架构设计

架构设计(一)基本概念

架构设计原则