软件架构：可能和你想的不太一样——可持续架构（一）

前言

• 很多公司都有架构委员会，这些人很多都与开发无关，要想保证我们的应用软件拥有弹性并且可以持续发展，必须将软件架构的控制权从这些人手中移交至真正实施的人手中：即开发人员。
• 软件架构的重点是做出决策而不是描述静态的结构设计。
• 对于一个敏捷团队来说，架构是整个团队的表现，是每个人的参与付出，这也意味着架构师对于敏捷团队来说并不仅仅是一个个人角色。
• 架构并不是在一开始设计好就是一成不变的，它应该是随着时代与技术的发展，而去不断调整和选择新的技术方案，从而是软件质量不断提升。
• 架构的关键活动就是提出系统将要达到的一系列质量指标的目标，然后根据系统的使用经验去测试系统是否满足这些目标，如果不满足，就需要考虑是否需要调整架构方案，实施完后，继续测试，不断重复调整、测试的流程，直到系统的各个指标达标。
• 架构的关键活动是形成关于系统将如何满足质量属性目标的假设，然后使用经验主义来测试系统是否满足这些假设，然后重复这个循环，直到系统满足其质量目标。

在敏捷开发社区中，软件架构颇具争议。在许多人的固有经验中认为，它会带来许多无意义的会议和文档，浪费时间，对应的架构也被调侃为 “PPT 架构”，他们认为不需要啥架构设计直接按照以往的经验直接开干就行了。相对而言，另一种就是设计架构了，但是架构设计的很糟糕，导致软件越往后迭代将会越履步为艰，最终变得停止迭代，弃用。那么，在这两者之间是否存在一种平衡点？
架构一词最早源于建筑行业，架构师在设计好架构后，工人一旦开始实施，架构就不允许变更了，因为建筑物是静态的，对应的架构也应该是静态的。后来随着软件行业的发展，软件的复杂度逐渐上升，就需要好好的设计，就引入了架构设计，从而也出现了架构师。但是问题就在于，软件并不是一成不变的，它是不断迭代演化的，一旦软件停止变化，也就意味着它步入了死亡的倒计时。因此软件行业的架构应该是随着时代与技术的发展不断变更调整的，叫做敏捷架构和敏捷架构师。
要想更好的理解软件架构一词，我们必须先了解“architect（架构师，建筑师）”这个词的起源：就像上边说的最早起源于建筑行业，但是架构是由建造事物的人创造的，这个意义在建筑师的工作中已经失去，许多架构设计师从未参与过建造，只负责设计，设计与建造是分离的。但是在软件领域不是这样的，软件的架构设计影响着所构建的内容，同样的构建的内容也影响着架构设计。

软件架构是决策而不是结构

建筑的比喻影响了一些软件架构师的思维，他们过分关注结构和行为，而忽略了产生这些结构和行为的决策。并不是说结构和行为不重要，它们是使系统持续演进的一个重要思维过程的结果，而这个思维过程就是决策，决策是必须被保留下来的。知道为什么做某些事和知道做了哪些事是一样重要的，如果我们的代码注释和文档做的足够好，我们做了什么就很容易看到，但是为什么做这些事也就是决策，却常常被忽略。
之所以这样是因为软件中的架构决策很少是清晰的，几乎每个架构决策都是在具有竞争性的替代方案之间进行权衡，而替代方案的优点在其实施并生效之前是很难看出来的。即使不断尝试后失败也不要急，知道失败点在哪往往比知道成功点更重要，每一次失败都是经验的重要积累，好的判断来自于经验，而大部分经验则来自于失败。
这也是软件架构师必须仍然是开发人员的原因之一：他们无法在没有开发和测试的情况下对系统有深入的理解。软件架构师不应该只是从多年开发人员晋升为被组织认可拥有丰富知识的一个荣誉称号，他们的角色应该更具实质性，需要对系统有足够深入的理解，以提出关于系统质量指标的有效假设，并具备编写代码，设计测试的专业技能（或者与其相关人员进行密切合作）。

架构设计是一种技能，架构师不是一个角色

实际上，软件架构师这样的头衔会误导人们对其工作性质的理解。其实许多软件开发人员都在进行架构工作，只是他们没有意识到。每当他们做出关于如何处系统相关质量指标的决定时，他们都在影响系统的架构。一旦意识到隐含决策是如何影响系统实现质量目标的能力，是改进系统架构的第一步。
要提高架构工作的质量，人们需要培养一些技能，包括：

• 加强对质量指标的关注： 良好的架构应该解决关键的横切要求，即质量指标。团队往往更容易关注功能性需求，因为它们往往是系统为用户所做的具体、甚至可见的事情。但系统的质量指标决定了它是否能够长期保持可行性：比如可扩展性、性能、安全性、可支持性和可维护性等。
• 能够概念化和解决系统范围的问题： 质量指标往往由影响整个系统的因素确定，而不仅仅是一个部分。虽然模块化设计和关注点分离对于构建良好的系统至关重要，但也使团队成员更难以全面了解系统。
• 理解系统的完整生命周期： 这不仅需要拥有开发系统的经验，还需要测试、部署、在生产环境中运行、长期维护的能力。理解系统的生命周期以及它如何应对变化，对于做出能够限制技术债务的良好决策至关重要，因为技术债务随着时间的推移可能会威胁到系统的可行性。
• 平衡关注点和妥协： 在架构工作中很少有唯一正确的答案。架构往往涉及在冲突的质量属性要求和约束之间做出妥协。
• 能够从经验中学习和综合新方法： 这涉及到能够从有针对性的尝试中获得结果（进行实验），并将这些学习以原则的形式概括出来，以指导进一步的实验。其中一些原则采取“标准”的形式，这是一个有些误导性的术语，因为标准需要通过实验不断测试，以确定它们何时不再有用。许多开发者在遵循所在组织中的标准时感到难受，因为这些标准可能是过时的。
• 展示领导能力： 提出关切、促进不同观点的讨论，并促进共识，有助于团队应对和克服复杂的架构问题。任何团队成员都可以做到这一点，而任何进行架构设计的人都必须这样做。
  

架构设计意味着不断探索

现代软件应用的架构设计就是一个典型的探索性活动，构建应用程序的团队每天都会遇到新的挑战：前所未有的技术挑战以及为客户提供解决新问题的新方法。这种持续的探索意味着架构不能事先确定，基于过去的经验；团队必须找到新的方法来满足质量需求。
下边是探索对发现架构至关重要的一个例子：假设你是一个团队的一部分，正在开发一个最初设计用于处理结构化的表格数据存储在SQL数据库中的软件系统。现在，这个系统需要增强以处理非结构化数据，包括图像和视频，并且预计系统处理的数据量将大幅增加。你考虑将NoSQL数据库添加到你的技术栈中来处理新的数据类型，但由于你的团队对这项技术没有太多经验，这个时候探索实验对于选择合适的数据库产品来满足新要求就至关重要。
当团队解决这些技术问题时，他们对哪些方法最能满足他们期望的质量属性形成了假设，这些假设也会随着时间而变化。他们构建了解决方案的一部分来测试这些假设，并根据结果做出决定。关于如何满足质量属性的这些决策的累积结果就是系统的架构。团队可以通过不同的方式传达这些决策，包括使用文档和图表，但文档和图表并不是架构，真正重要的是决策及其原因。
这些决策的重要信息包括以下内容：

• 撤销决策的成本： 如果有必要撤销一个决策，了解撤销成本会很有帮助。如果你必须替换一个服务、一个数据库管理系统，甚至是一个框架，知道这可能有多昂贵会很有帮助。在某些情况下，这可能意味着需要重写应用程序。
• 清晰表达任何限制或假设： 帮助你的团队理解你所做的工作的限制和假设，为将来你的团队成员需要修改你的工作内容有利。例如，你在编写代码的时候假设并发度不会超出x qps, 产品用户不会超出多少人，你需要了解这些假设并且清晰的表达出来，将帮助你的未来同事了解如果这个限制被超出，他们可能需要做出哪些改变。
• 如何满足特定的质量属性要求（QAR）： 对于每个质量属性要求，你应该描述你所做的工作，以确保它将被满足，不仅仅是在理论上，还要描述你进行了哪些测试来证明它。链接到具体的测试用例及其相关的自动化测试，这样当质量属性要求发生变化时，你就能够轻松地重新评估系统的架构质量。
• 决策的理由以及考虑的选项： 知道你考虑了什么并且拒绝了什么，通常比知道你做了什么决定更有用；它展示了你的思维过程，并提供了你在做出决定时可能面临的约束的见解。如果这些约束在未来被解除，知道你为什么做出某些决定将帮助未来的开发人员做出更好的决定。
• 有意承担的技术债务：一张关于 QAR，(决策)Decision，（技术债务）Technical Debt 的关系图如下：

一些决定不可避免地会产生技术债务；例如，使用SQL数据库来满足可靠性目标的决定会对技术债务产生一些副作用（参见图1）。如今早已过去的“Y2K问题”是开发人员当时做出的一个有意识的决定，通过不将世纪数据存储为标准日期表示的一部分，降低了数据存储、内存使用和处理时间需求。问题是，他们没有预料到应用程序会持续那么长时间，远远超过了这些约束已经变得无关紧要的时候。如果他们更准确地传达了他们的决定并描述了潜在影响，也许在上个世纪末就不会出现如此大的应对紧急情况。

总结

软件架构作为一门学科，需要进行改革。它的形象受到了许多关于它需要解决什么问题以及如何解决这些问题的陈旧观念的影响。
将软件架构视为一项持续的活动，重点是提出关于系统如何满足质量属性的假设，然后使用经验主义来证明系统是否满足这些假设，这是持续软件架构的本质。
需要改变的另一点是将软件架构从与开发脱节的委员会手中夺回，交给那些真正可以将其变为现实和可执行的人，即开发人员。只有这样，我们才能从今天的应用程序中获得所需的弹性和可持续性。