架构设计系列1：什么是架构设计

背景

• 业务千变万化，技术不断涌现，我们很难找到一套通用的架构模式适用于所有系统。
• 那么，在面对"不确定性"时，我们应如何进行架构设计，以实现系统的稳定性和可靠性呢？
• 本文基于个人实践经验和业界专家分享，概括了一些关于架构设计的简明理解。
• 如果有不妥之处，请随时指出，我将及时进行修正。

---

架构设计是什么？

架构设计，就是对系统结构进行设计。

那么，系统结构是什么呢？它包括子系统、模块、组件，以及他们之间的协作关系。

架构设计是经过系统性地思考，权衡利弊之后，在现有资源约束下的最合理决策。

架构设计为开发团队提供了一个指导框架，确保系统在不断变化的环境中，能够保持稳定和可靠。

---

为什么要做架构设计？

我们先来回答一个问题：如果一个系统或业务足够简单，有必要做架构设计吗？

答案很显然：没有必要。

我们再来回答一个问题：什么情况下需要做架构设计呢？

基于上一个问题，我很容易得出答案：一定的复杂性。

复杂性的表现形式有哪些？

• 变更放大： 看似简单的变更需要在许多不同地方进行代码修改。
• 认知负荷： 开发人员需要多少知识才能完成一项任务。一个复杂系统，如果部署简单，架构清晰，其实都是降低完成任务所需的成本。
• 未知的未知： 开发人员必须获得哪些信息才能成功地执行任务。你不知道改动的这行代码是否能让程序正常运转，也不知道这行代码的改动是否又会引发新的问题，这时“未知的未知”就出现了。这也是复杂性中最糟糕的一个表现形式。

复杂性具体体现在哪里？
一般来说，复杂体现在两个方面：业务复杂度和技术复杂度。

业务复杂度，指业务固有的复杂度，主要体现为难以理解、难以扩展。
例如，业务数量多、业务流程长、业务之间关系复杂，等等。

技术复杂度，指技术固有的复杂度，主要体现为编码难度大，技术能力要求高，需运用大量技巧去实现。
例如，高性能、高可用、高可扩展、安全，以及与成本之间的平衡，等等。

如何应对架构复杂度？

复杂度等级	业务复杂度	技术复杂度	架构模式
1	低	低	框架，如 LAMP、SpringBoot、SpringCloud等
2	高	低	DDD、SOA、微服务等
3	低	高	集群、缓存、分片、副本等
4	高	高	融合所有模式

一个复杂系统，随着迭代会逐渐腐化，我们可以通过架构设计让系统变得相对简洁和清晰，从而更容易被理解和扩展。

那么，复杂度它会消失吗？

并不会，因为复杂度无法消除，它只能被转移。它还是存在于某个地方。

因此，我们可以得出结论：架构设计的真正目的，是为了解决系统复杂度带来的问题。

简而言之，架构设计本质上就是控制复杂度。

---

架构设计的核心要素是什么？

《大型网站技术架构》一书中，提出系统设计的五要素。

其实，在架构设计的过程中，还有一个要素需要考虑，那就是成本。这样就形成了架构设计的六要素。

• 性能
• 可用性
• 扩展性
• 伸缩性
• 安全性
• 成本

一个好的架构设计，要在实现高性能、高可用的同时，满足低成本的目标。

而低成本不是目标，低成本是实现高性能、高可用的一个约束。

这里需要对扩展性和伸缩性做一下说明，因为很多人会把他们当做一回事，但其实他们的侧重点是不同的。

• 扩展性，核心在于系统适应变化的能力，包含可理解和可复用两个部分。
• 伸缩性，核心在于系统通过添加更多资源来提升性能的能力。

---

架构设计的常见场景有哪些？

在日常工作中，这三种场景可以覆盖80%的架构设计场景。

• 可扩展架构
• 高性能架构
• 高可用架构

本系列后续的章节，将重点围绕这三个架构设计场景进行介绍。

---

常见的架构类型有哪些？

一般有如下几种常见的架构类型。

业务架构

• 业务架构是战略。
• 核心逻辑是，通过拆解业务战略，进行领域模型设计，把现实的业务转化为抽象的对象，来解决功能性需求。
• 包括当前能力，未来能力，业务模块，业务流程等。上接公司战略，下接技术实施。

应用架构

• 应用架构是战术。
• 核心逻辑是，通过分层和模块划分，确定系统的边界、交互和关系，平衡业务和技术复杂性，确保业务架构落地。
• 包括定义子系统或模块，以及系统之间的交互等。

数据架构

• 数据架构是粮草。
• 核心逻辑是，通过制定数据标准，建立数据模型，管理数据分布等方式，为应用架构提供支撑。
• 包括表结构设计（ER图），表到实体模型的转换设计，以及技术架构中的数据库选型，和部署架构中的数据存储设计（灾备，主从等）。

技术架构

• 技术架构是装备。
• 核心逻辑是，通过选择和组合各种软件和硬件，再结合应用代码，来解决非功能性需求。
• 包括IT基础设施、中间件、网络、部署到硬件的策略等。
• 技术架构是架构设计工作中最难的部分。

物理架构

• 物理架构是战场。
• 核心逻辑是，通过选择合适的硬件，定义硬件的分布，定义软件到硬件的映射，定义数据如何在硬件上保存和传递的，以及考虑软件和硬件的相互影响，为业务、应用、数据、技术这4种架构提供支撑。
• 包括物理机器，网络，存储，硬件设施等。
• 物理架构分为拓扑架构和部署架构。
• 拓扑架构主要指网络拓扑图，主要关注对象是运维。
• 部署架构主要指系统或模块在不同的物理设备上是如何分布的。