关于软件架构有许多定义，但在实践中，大多数在架构上具有重要意义的决策都与满足利益相关者对系统质量的需求有关，包括性能、韧性和安全性。架构师以前解决这些复杂问题的方式是进行大量的“前期”设计和思考，但如今架构师们需要更快地行动，更有效地适应变化。许多方法，如持续交付、RCDA和持续架构等，都试图减少前期的架构活动，更多地将架构活动贯穿在交付生命周期中。这样，团队就可以在获得更多信息后再做出重要决策，并支持系统创建过程中出现的变更；但难点在于如何确定自己是否已经完成了足够的架构工作以及是否把时间花在了最重要的事情上，以最大化工作收益。
要做的事情太多，时间总是不够用，因此你需要明智地选择任务，并知道何时停止去解决下一个问题。度量就是解决方案。通过在特定时间点对系统的质量进行度量，而不是凭直觉或遵循僵化的架构方法，你就能了解自己所处的位置。随着时间的推移进行度量，你就能看到趋势，并根据这些质量属性的演变来确定你的方向。以这种方式使用度量，可以指导你的架构活动，并最大限度地发挥其价值。拥有可靠且经济高效的度量方法非常重要。在本文接下来的部分，我们将介绍软件架构中，度量的五种方法。
正如Cindy Sridharan在Distributed Systems Observability（O'Reilly，2018）一书中所指出的，目前可用的度量机制一般有三种：日志、跟踪和指标。- 日志为我们提供了一系列带有时间发的事件记录，以显示某个技术组件在一段时间内发生了什么。
- 跟踪则是对这一理念的延伸，它是直接相关事件的集合，记录了软件内端到端跨组件场景，如请求处理。
- 指标是对一段时间内系统特性的直接数字度量，例如虚拟机的CPU使用率或图像存储器的存储大小。
我们可以从系统基础架构和应用程序本身收集日志、跟踪和指标。通常情况下，从基础架构设施访问日志、跟踪和指标更简单，因为大多数基础架构设施环境（如公共云平台）都有复杂且功能齐全的信息收集系统，无须进行太多工作即可提供这三种信息。应用程序日志、跟踪和指标通常需要更多的工作，因为你必须自己直接或通过重用度量机制（如应用程序性能管理（APM）工具）来实现它们。不过，应用程序度量是针对具体情况的，这可以为利益相关者真正关心的特性（如产生的收入等业务指标，而不仅仅是纯粹的技术指标）提供更多见解。俗话说：“代码不会说谎。”代码一经编写，就可以成为丰富的度量来源。静态代码分析是一个高度发展的领域，有各种功能强大的工具，然而，它仅限于度量常见的编程错误和代码结构特征（如复杂性或耦合性）。这对于评估维护性和可扩展性以外的许多架构质量特性没有帮助。不过，对于评估质量（例如安全性），代码分析度量（如发现的奖符漏洞数量）可以作为一种有用的替代度量方法。代码分析的明显问题是，在代码编写完成之前，你无法使用它，因此它只能提供回顾性而非预测性的度量结果。而在实现之前捕捉设计的某些方面，就可以使用设计分析来创建预测性度量，如是否符合标准，或可能的架构质量，如可伸缩性。我不建议制作老式的详细设计文档，因为这些文档一完成就会过时，但在实施前捕捉一些最基本但准确的设计表述，可以对可能的系统特性提供有洞察力的估算，从而指导你的工作。使用模型和估算来创建预测性度量，可以在交付周期的早期，编写大量代码之前指导架构工作。你可以利用自己以前的经验、对其他类似系统的度量结果以及已公布的基准或测试结果来创建数学模型，通常是在电子表格中创建。这些模型试图捕捉运行参数（如数据库大小、请求量、请求类型、服务器数量和内存大小）与由这些参数产生的质量属性值之间的基本关系。这种预测性度量存在一些问题。首先，它最适用于易于用数字表示的架构特性，如可扩展性和性能。而对于安全性这样的特性，则比较难以使用这种方法。其次，除了最简单的系统外，要创建一个简单易懂、结果可靠的模型也非常困难（而且昂贵）。最后，在系统建成之前，也很难验证此类模型的预测能力，此时你只需对其进行度量即可。确保你创建的是真正有用的东西。Neil Ford、Rebecca Parsons和Patrick Kua在Building Evolutionary Architectures（O"Reilly，2017）一书中提出了用于质量属性度量的“适应度函数”。与其说适应度函数是一种新的度量机制，不如说它是一种利用度量来监控系统质量属性并确保其保持在可接受范围内的机制。适应度函数为一个或多个质量属性定义了一个或一组可接受的值，以及如何检查系统是否至少达到了这些质量属性数值的方法。理想情况下，适应度函数应作为自动化流程来实施，但许多有用的适应度函数无法自动化，因此手动的适应度函数（如电子表格计算）仍然很有价值。举个简单的例子，如果你知道某一特定类型的所有请求都应在100毫秒内处理完毕，那么你就可以在运行环境中创建一个自动化的适应度函数，用于监控请求处理时间，并在请求处理时间超长时发出警报。适应度函数并不能使质量属性度量变得更容易。你仍然需要使用本节中概述的技术。但它们可以帮助你使用度量数据来引导和聚焦你的架构工作。总结
本文从常用度量方法的角度介绍了如何在软件架构中使用度量。每种重要质量（如性能、可扩展性、可用性和安全性等）在度量时都有自己的特点，需要结合这些特点使用不同的度量方法。如果您对软件的度量指标感兴趣，想要进一步了解其在软件架构中的具体应用，推荐您阅读《软件架构指标：度量软件系统的性能和架构质量》一书。- Christian Ciceri，一名软件架构师，也是Apiumhub的联合创始人。
Dave Farley，持续交付、DevOps和软件开发领域的思想领袖。
Neal Ford，Thoughtworks的总监、软件架构师和文化塑造师。
Andrew Harmel-Law，Thoughtworks的技术主管。
Carola Lilienthal，博士，Workplace Solutions GmbH的总经理。
Michael Keeling，一位经验丰富的软件架构师、敏捷实践者和程序员。
João Rosa，Xebia的首席顾问。
Alexander von Zitzewitz，hello2morrow的创始人之一。
Rene Weiss，Finabro的首席技术官。
Eoin Woods，Endava的首席技术官。
本文摘编自《软件架构指标：度量软件系统的性能和架构质量》，经出版方授权发布，转载请保留文章来源。
推荐理由：本书通过10位杰出实践者的贡献，分享了关键的软件架构指标，帮助你设定正确的关键绩效指标并衡量结果。软件架构指标是软件项目的可维护性和架构质量的关键，它们可以在项目早期向你发出警告，提醒你注意架构和技术债务的积累。本书不是一本关于理论的书。它更多的是关于实践，关于已经尝试过并行之有效的方法。本书面向渴望探索成功案例的软件架构师和软件开发人员，旨在帮助读者进一步了解决策和测量的有效性。
