软件架构师速成指南

第 II 部分. 建筑学

定义架构并非易事-- ，IT 架构的定义似乎和从业架构师的人数一样多。

超越软件架构

大多数软件架构定义都列举了系统的元素和组件以及它们之间的相互关系。 在我看来，这只涵盖了架构的一个方面。首先，IT 架构远不止软件架构：除非你把所有的 IT 基础设施都外包给公共云，否则你需要架构网络、数据中心、计算基础设施、存储等等。即便如此，你仍然需要部署架构、数据架构和安全架构。其次，定义您要关注的 "组件 "是架构的一个重要方面。

备注

一位经理曾表示，尽管所有的网络东西都 "在那里"，但他还是无法理解许多网络问题。他的观点是物理观点：以太网电缆插入服务器和交换机。而网络架构的复杂性在于虚拟网络隔离、路由选择、地址转换等等。不同的利益相关者会看到架构的不同部分。

三种建筑

在谈到架构时，人们通常会提到三个截然不同的概念，它们都与信息技术有关，但性质却大相径庭：

1. 系统架构，由其结构定义，如"微服务 架构"。

2. 定义系统结构的行为，如 "架构委员会"。

3. 参与定义架构的团队，如 "我们正在建立企业架构"。

因此，虽然每个系统都有一个架构，但并不是每个组织都有一个架构（单位），即使有，他们也未必能完成多少架构工作。

为了减少混淆，当我提到 "架构 "时，我一般指的是系统的属性。至于组织方面，我指的是 "架构师"--毕竟它是以人类为基础的。

总有一种建筑

在谈到系统架构时，值得指出的是，所有系统都有一个架构。你不可能用几块没有任何结构的碎片来构建任何东西。一旦我们意识到这一点，类似 "我们没有时间搞架构 "这样的说法就没有什么意义了。问题只在于你是有意识地选择自己的架构，还是任其发展。历史表明，后一种做法总是导致 臭名昭著的大泥球¹架构，也被称为棚户区。虽然这种建筑确实可以在没有中央规划或专业技能的情况下快速实施，但它也缺乏关键的基础设施，并不适合居住。宿命论并不是一个好的企业架构策略，所以我建议你选择自己的架构。

建筑的价值

因为 ，架构总是存在的，所以组织应该明确它对设立架构职能的期望。建立一个架构团队，然后不让它开展工作--例如，经常让架构决策服从管理决策--实际上比故意让事情发展成一个大泥球还要糟糕：你假装定义了你的架构，但实际上你并没有定义。更糟糕的是，优秀的建筑师不希望自己所在的公司把建筑设计当作一种娱乐。如果你不认真对待建筑，你就无法吸引和留住认真的建筑师。

IT 管理人员通常认为，"架构 "是一项长期投资，只有在未来很长时间内才能得到回报。尽管这在某些方面是正确的--例如，管理系统随时间的演进--但架构也能在短期内带来回报，例如，当你能在开发周期的后期满足客户的需求时，当你因为避免了锁定而在供应商谈判中获得优势时，或者当你能轻松地将系统迁移到新的数据中心位置时。 良好的架构还能通过允许组件的并行开发和测试来提高团队的工作效率。一般来说，良好的架构可以为你赢得灵活性。在瞬息万变的世界里，这似乎是一项明智的投资。

原则驱动决策

架构 是一个权衡问题：很少有单一的 "最佳 "架构。例如，选择将应用程序迁移到 Cloud 可能会增加成本和复杂性。因此，架构师在做出架构决策时必须考虑到上下文，因为上下文将帮助他们权衡利弊。

架构师还应努力实现概念的完整性，即系统设计的统一性。要做到这一点，最好的办法是选择一套定义明确的架构原则，并始终如一地应用到架构决策中。 这些原则来自于已宣布的架构战略，可确保决策支持该战略。

垂直凝聚力

良好的架构不仅要在各系统间保持一致，还要考虑到软件和硬件堆栈的所有层级。研究新型的横向扩展计算硬件或软件定义的 ...