这篇文章接着初步了解软件系统架构设计,内容整理自从 0 开始学架构 的 8 ~ 13 篇。如标题所示,这部分主要讲述架构设计的三个原则和架构设计流程的四大步骤。

Architecture

原则

架构设计的主要原则有三条:

  1. 合适原则
  2. 简单原则
  3. 演化原则

合适原则

合适优于业界领先

这一点无须多讲,适合自己业务的,才是好的。

简单原则

简单优于复杂

能用简单的设计,就不要追求复杂的。“复杂”本身就是个问题。前面几节已经讨论了很多关于软件系统复杂度的话题,架构设计的主要目的就是应对系统的复杂度。

结构复杂

这类系统的组件数量多,组件之间的关系复杂。整个系统出故障的概率大,组件改动影响大,定位问题困难。

逻辑复杂

与结构复杂相对应,这类系统的一个典型特征是单个组件内部功能太复杂。这种复杂的组件,会越来越难以修改、维护,定位问题。

因为业务需求是变动的,系统是要不断修改的,复杂性就会带来各种问题。

演化原则

演化优于一步到位

软件架构和建筑结构有类似之处,但是有个巨大的差异:建筑基本不变,软件要不断变化。例如 Windows 1.0 演化到 Window 10 已经不算是一个系统了。

不要试图设计一个不变的架构,去应对一直变化的业务需求。

软件架构要满足当前的业务需求,要在实际应用过程中持续迭代,完善,随着业务变化演化架构


即使是现在非常复杂、非常强大的架构,也并不是一开始就进行了复杂设计,而是首先采取了简单的方式(简单原则),满足了当时的业务需求(合适原则),随着业务的发展逐步演化而来的(演化原则)。


流程

架构设计的流程包括:

  1. 识别复杂度
  2. 设计备选方案
  3. 评估和选择备选方案
  4. 详细设计方案

识别复杂度

架构的主要目的就是解决软件系统的复杂性,所以架构设计的第一步就是找出系统中哪里复杂,根据之前讲的“高可用”、“高性能”、“可扩展性”等,分析系统的复杂性体现在什么地方。

假设接手了一个在各个方面复杂度都出现问题的系统,对这个系统做架构设计,正确的做法是将主要的复杂度问题列出来,然后根据业务、技术、团队等综合情况进行排序,优先解决当前面临的最主要的复杂度问题

以一个假想的“前浪微博”为例,要给几个子系统间作一个消息队列,对这个消息队列作架构设计,首先针对“高性能”、“高可用”、“扩展性”三个方面进行复杂度分析,得到的结果是消息队列的复杂性主要体现在:高性能消息读取、高可用消息写入、高可用信息存储、高可用消息读取。

设计备选方案

在设计架构方案这一步,有几种常见的错误。

  • 设计最优秀的方案。要根据“合适原则”和“简单原则”,结合业务需求、团队、技术能力,进行架构设计。
  • 只做一个方案。
    • 很可能思考不够全面,甚至错误。
    • 为了避免思维狭隘、考虑不周,通常应该设计 3 ~ 5 个备选方案,更多则会耗费大量精力和时间。
    • 备选方案之间的差异要明显,差异太小的方案不能算作两个不同的方案。设计备选方案时不要只局限于已经熟悉的技术。
  • 备选方案过于详细。
    • 耗费大量时间和精力。
    • 太注重细节,忽略了整体设计,导致备选方案不多或者差异不大。
    • 对方案进行评审时,太多的细节让评审效果很差。
    • 正确的做法是备选阶段关注技术选型,技术选型的差异要明显,而不必关注技术细节。

仍然以“前浪微博”为例,设计了三个备选方案

  1. 采用开源的 kafka
  2. 集群 + MySQL 存储
  3. 集群 + 自研存储方案

评估和选择备选方案

这一步要在不同的场景采取不同的方式,用 360 度环评的方法来评估和选择备选方案:列出需要关注的质量属性点,然后分别从这些属性的维度去评估每个方案,再综合挑选适合当时情况的最优方案。

360 环评之后,可以清晰地看到各个方案地优劣点,根据这些信息,做出最终的选择。做这个选择时,简单的按照各个方案优劣点的个数来选择,或者用加权法(无法客观地给出每个质量属性的权重得分),都是错误的。正确的做法是按优先级选择。

架构师综合当前的业务发展情况、团队人员规模和技能、业务发展预测等因素,将质量属性按照优先级顺序,首先挑满足第一优先级的,如果方案都满足,那就再看第二优先级……以此类推。

以前面给“前浪微博”做的三个备选方案为例,进行 360 度环评后得到地结果大概是这样:

质量属性 引入 Kafka MySQL 存储 自研存储
性能
复杂度
硬件成本
可运维性
可靠性
人力投入

最终选择方案 2,MySQL 存储。因为业务可运维性比较重要,排除方案 1,因为人力有限,排除方案 3。业务需要地性能并不是很高,方案 2 的主要缺点就是成本高,可以通过让备机与其他系统混合部署再同一台机器上,来节省成本。

详细方案设计

选中确定的备选方案后,要对方案进行细化,将方案涉及的关键技术细节确定下来,让备选方案变成可以落地的设计方案。

这一步的技术方案选择比较“轻量级”,不需要像备选方案阶段那样操作。

架构师不但设计备选方案,还需要对备选方案的关键细节有深入理解,不做“PPT架构师”。

针对“前浪微博”消息队列这个假想的项目,使用 MySQL 存储的方案,有以下需要细化的点:

  1. 数据库表如何设计
  2. 数据如何复制
  3. 主备服务器如何倒换
  4. 业务服务器如何写入消息
  5. 业务服务器如何读取消息
  6. 业务服务器和消息队列服务器之间的通信协议如何设计
  7. ……