概要
背景
- 业务千变万化,技术不断涌现,我们很难找到一套通用的架构模式适用于所有系统。
- 那么,在面对"不确定性"时,我们应如何进行架构设计,以实现系统的稳定性和可靠性呢?
- 本文基于个人实践经验和业界专家分享,概括了一些关于架构设计的简明理解。
- 如果有不妥之处,请随时指出,我将及时进行修正。
架构设计是什么?
架构设计,就是对系统结构进行设计。
那么,系统结构是什么呢?它包括子系统、模块、组件,以及他们之间的协作关系。
架构设计是经过系统性地思考,权衡利弊之后,在现有资源约束下的最合理决策。
架构设计为开发团队提供了一个指导框架,确保系统在不断变化的环境中,能够保持稳定和可靠。
为什么要做架构设计?
我们先来回答一个问题:如果一个系统或业务足够简单,有必要做架构设计吗?
答案很显然:没有必要。
我们再来回答一个问题:什么情况下需要做架构设计呢?
基于上一个问题,我很容易得出答案:一定的复杂性。
复杂性的表现形式有哪些?
- 变更放大: 看似简单的变更需要在许多不同地方进行代码修改。
- 认知负荷: 开发人员需要多少知识才能完成一项任务。一个复杂系统,如果部署简单,架构清晰,其实都是降低完成任务所需的成本。
- 未知的未知: 开发人员必须获得哪些信息才能成功地执行任务。你不知道改动的这行代码是否能让程序正常运转,也不知道这行代码的改动是否又会引发新的问题,这时“未知的未知”就出现了。这也是复杂性中最糟糕的一个表现形式。
复杂性具体体现在哪里?
一般来说,复杂体现在两个方面:业务复杂度和技术复杂度
。
业务复杂度,指业务固有的复杂度,主要体现为难以理解
、难以扩展
。
例如,业务数量多、业务流程长、业务之间关系复杂,等等。
技术复杂度,指技术固有的复杂度,主要体现为编码难度大
,技术能力要求高
,需运用大量技巧去实现
。
例如,高性能、高可用、高可扩展、安全,以及与成本之间的平衡,等等。
如何应对架构复杂度?
复杂度等级 | 业务复杂度 | 技术复杂度 | 架构模式 |
---|---|---|---|
1 | 低 | 低 | 框架,如 LAMP、SpringBoot、SpringCloud等 |
2 | 高 | 低 | DDD、SOA、微服务等 |
3 | 低 | 高 | 集群、缓存、分片、副本等 |
4 | 高 | 高 | 融合所有模式 |
一个复杂系统,随着迭代会逐渐腐化,我们可以通过架构设计让系统变得相对简洁和清晰,从而更容易被理解和扩展。
那么,复杂度它会消失吗?
并不会,因为复杂度无法消除,它只能被转移。它还是存在于某个地方。
因此,我们可以得出结论:架构设计的真正目的,是为了解决系统复杂度带来的问题。
简而言之,架构设计本质上就是控制复杂度。
架构设计的核心要素是什么?
《大型网站技术架构》一书中,提出系统设计的五要素。
其实,在架构设计的过程中,还有一个要素需要考虑,那就是成本。这样就形成了架构设计的六要素。
- 性能
- 可用性
- 扩展性
- 伸缩性
- 安全性
- 成本
一个好的架构设计,要在实现高性能、高可用的同时,满足低成本的目标。
而低成本不是目标,低成本是实现高性能、高可用的一个约束。
这里需要对扩展性和伸缩性做一下说明,因为很多人会把他们当做一回事,但其实他们的侧重点是不同的。
- 扩展性,核心在于系统适应变化的能力,包含可理解和可复用两个部分。
- 伸缩性,核心在于系统通过添加更多资源来提升性能的能力。
架构设计的常见场景有哪些?
在日常工作中,这三种场景可以覆盖80%的架构设计场景。
- 可扩展架构
- 高性能架构
- 高可用架构
本系列后续的章节,将重点围绕这三个架构设计场景进行介绍。
常见的架构类型有哪些?
一般有如下几种常见的架构类型。
业务架构
- 业务架构是战略。
- 核心逻辑是,通过拆解业务战略,进行领域模型设计,把现实的业务转化为抽象的对象,来解决功能性需求。
- 包括当前能力,未来能力,业务模块,业务流程等。上接公司战略,下接技术实施。
应用架构
- 应用架构是战术。
- 核心逻辑是,通过分层和模块划分,确定系统的边界、交互和关系,平衡业务和技术复杂性,确保业务架构落地。
- 包括定义子系统或模块,以及系统之间的交互等。
数据架构
- 数据架构是粮草。
- 核心逻辑是,通过制定数据标准,建立数据模型,管理数据分布等方式,为应用架构提供支撑。
- 包括表结构设计(ER图),表到实体模型的转换设计,以及技术架构中的数据库选型,和部署架构中的数据存储设计(灾备,主从等)。
技术架构
- 技术架构是装备。
- 核心逻辑是,通过选择和组合各种软件和硬件,再结合应用代码,来解决非功能性需求。
- 包括IT基础设施、中间件、网络、部署到硬件的策略等。
- 技术架构是架构设计工作中最难的部分。
物理架构
- 物理架构是战场。
- 核心逻辑是,通过选择合适的硬件,定义硬件的分布,定义软件到硬件的映射,定义数据如何在硬件上保存和传递的,以及考虑软件和硬件的相互影响,为业务、应用、数据、技术这4种架构提供支撑。
- 包括物理机器,网络,存储,硬件设施等。
- 物理架构分为拓扑架构和部署架构。
- 拓扑架构主要指网络拓扑图,主要关注对象是运维。
- 部署架构主要指系统或模块在不同的物理设备上是如何分布的。
小结:业务架构是战略;应用架构是战术;数据架构是粮草;技术架构是装备。
架构设计系列文章
- 架构设计系列:什么是架构设计
- 架构设计系列:几个常用的架构设计原则
- 架构设计系列:高并发系统的设计目标
- 架构设计系列:如何设计可扩展架构
- 架构设计系列:如何设计高性能架构
- 架构设计系列:如何设计高可用架构
- 架构设计系列:如何应对软件变化
- 架构设计系列:常用设计模式的实践