你是一名软件架构师,并且经常发现在你的团队中很难做出架构决策吗?这篇文章告诉你如何使用架构原则在你的团队中做出有效的决定。
什么是架构原则?
如果我们询问Eoin Woods(他是《软件系统架构》、《实践中的持续架构》、《软件架构度量》等书的作者)什么是架构原则,他对架构原则的解释如下:
为了指导架构设计决策,以实现一个系统的一个或多个品质而做出的声明性陈述。
如果我们仔细看一下这个定义,我们会发现这个定义中有几个有趣的部分:
"[......]指导架构设计决策的意图[......]"
作为一个软件架构师或一个软件工程师团队,你必须处理和决定许多架构问题。
但你是如何决策这些问题的呢?直觉吗?-)
这可能不是正确的方法。
有一些质量目标是架构的驱动力。
质量目标是定义软件架构玩法的一个重要部分。
这里Eoin提到了质量目标与部分:
"[...]为了实现系统的一个或多个质量"。
但是,将质量目标推导到架构决策上并不总是容易的。
所以这就是架构原则发挥作用的地方,作为架构决策的灯塔。
架构原则在与关键利益相关者谈判和沟通决策时非常有价值。如果利益相关者或团队成员不理解某个架构决策的整个推导过程,你可以指出具体的架构原则。
在你的团队或与你的关键利益相关者,当原则被违反时,你可以进行有效的对话,以突出未来的问题。
架构原则是软件架构师最广泛使用的准则类型。
好的架构原则的基本特征是什么?
一个架构学原则应该具有以下特性,使其成为一个好的原则:
1、可理解的和清晰的
该原则应该是合理的、有逻辑的和一致的。
架构原则应该像营销口号一样。
架构原则应该像营销口号一样。它们应该是简单易懂的,对每个人来说都很容易记住。
2、提供指导
当你做决定时,你可以很容易地使用原则作为指导。它为你的决策过程带来效率。
3、可测试
原则应该是可检验的,工作是否按照原则进行,哪里出现了例外。
4、原子性
该原则不需要进一步的背景或上下文知识来理解。
总之,架构原则的编写应该使团队能够做出决定:它们是清晰的,提供决策支持,并且是原子性的。
创建架构原则的误区是什么?
你对以下原则有什么看法?
"所有的软件都应该以可扩展的方式来编写"。
IMHO这是一个架构原则的坏例子。
哪个软件工程师创造的软件是明确的不可扩展的?没有。
架构原则太笼统,无法验证
上述原则过于笼统,无法验证。它也没有为具体的决定提供指导。
正如你所看到的,在处理架构原则时,有一些陷阱是你可能会陷入的。
1、架构原则涵盖所有的意外情况
另一种不好的做法是创建一套完整的原则,涵盖所有的可能性。这通常会导致一长串原则,写得非常详细,通常需要长时间的编辑。然而,这些原则往往并没有嵌入到做出实际架构决策的团队的思维过程中。
2、确保只有一小套架构原则。
如果这些原则被一个团队完全接受并影响他们的决策,那么这一小套原则就非常有价值。产品团队中的每个人都应该在任何时候和日常工作中记住既定的原则!
现实世界中的架构原则的例子
让我们讨论一下我实践中的一些架构原则。
例子1:"如果可以接受锁定某个特定的供应商,就使用云服务"。
如果你使用云服务,你就事实上被绑在了一个特定的供应商身上。因此,使用管理服务应该谨慎选择。
这就是为什么我们在一个产品团队中采用了以下的架构原则。
"如果锁定某个特定的云供应商是可以接受的,就使用云服务。"
这种供应商锁定是否可以接受,取决于几个标准:
- 替换该管理服务所需的努力
- 提供替代品的可接受的准备时间。
让我们来看看我们过去不得不做的一个技术决定的例子:
我们需要为我们的SaaS产品评估一个集中的身份和访问管理解决方案:
- Keycloak (自我托管)
- Auth0 (管理型,云服务)
遵循 "如果锁定某个特定的云供应商是可以接受的,就使用云服务。"的定义原则,我们得出结论,集中式IAM系统应该是自我管理的,而不是由第三方供应商管理的,因为更换一个管理的IAM产品是一个巨大的努力,因此没有合理的准备时间来部署替代方案。
总之,在这种情况下,供应商锁定是我们不能接受的。所以这个原则有效地指导我们做出了正确的决定。
例2:"优先选择标准数据格式,而不是第三方和自定义格式"
下一个原则是关于服务通信的协议选择。
"优先选择标准数据格式而不是第三方和自定义格式"
如果你有多个需要相互通信的服务,就会出现协议和格式的问题。
在协议生态系统中,有一个相当新的孩子:gRPC
gRPC(gRPC远程过程调用)是一个跨平台、开源、高性能的远程过程调用协议。gRPC最初由谷歌开发,用于连接大量的微服务。
所以在我们的团队中,问题是:RESTful HTTP vs. gRPC?
gRPC vs. RESTful HTTP
因此,协议的选择在很大程度上取决于相关服务的质量和变化情况。
但是,如果你能用两种选择来满足质量目标和基本要求,比如RESTful HTTP与gRPC,那么请认为自己很幸运,有这样的原则。
这个原则帮助我们选择了RESTful HTTP而不是gRPC,因为RESTful HTTP是一种被广泛接受的标准数据格式,而gRPC则更像是一种第三方格式。
所以在这里,这个原则加速了我们的决策,这并不意味着我们在某些情况下不依赖gRPC。