架构师之路 — 软件架构 — Overview

Posted 2022-02-17 范桂飓

目录

文章目录

• 目录
• 软件架构的定义
• 软件架构的核心要素
• 软件架构的目的
• 软件架构分类
• • 业务架构
  • 应用架构
  • 数据架构
  • 代码架构
  • 系统架构
  • 部署架构
  • 运维架构
• 架构层级

软件架构的定义

IEEE 给出的定义：

架构是环境中该系统的一组基础概念（concepts）和属性（properties），具体表现就是它的元素（elements）、关系（relationships），以及设计与演进的基本原则（principles）。

CMU 软件工程研究院的定义：

架构是用于推演出该系统的一组结构（structures），具体是由软件元素（elements）、元素之间的关系（relationships），以及各自的属性（properties）共同组成。

软件架构的核心要素

从上述软件架构的定义中，我们可以提取出 4 个核心要素：

1. 元素（elements）：将系统拆分为一组元素，例如：模块、组件、结构体、子系统；
2. 关系（relationships）：不同元素之间的关系，例如：交互、依赖 、继承、组合、聚合；
3. 属性（properties）：每个元素具备的属性，例如：名称、职责、接口、实现限制等；
4. 原理（principles）：为什么这么设计，例如：拆分依据、设计原则、决策原因等。

可见，软件架构不仅显示了软件需求和软件结构之间的对应关系，而且指定了整个软件系统的组织和拓扑结构，提供了一些设计决策的基本原理。

软件架构的目的

高级语言的出现，解放了程序员，但好景不长，随着软件的规模和复杂度的大大增加，软件质量低下，质量把控难度高，项目无法如期完成，严重超支等现象。例如，1963 年美国的 水手一号火箭发射失败事故，就是因为一行 FORTRAN 代码错误导致的。

所以，为了解决上面的问题，针对性的提出了解决方法 “软件工程”。虽然 “软件工程” 提出之后也曾被视为软件领域的银弹，但后来事实证明，软件工程同样无法根除软件危机，只能在一定程度上缓解软件危机。

差不多同一时间，“结构化程序设计” 作为另外一种解决软件危机的方案被提了出来。结构化程序设计的主要特点是抛弃 goto 语句，采取 “自顶向下、逐步细化、模块化” 的指导思想。“结构化程序设计” 的本质上还是一种面向过程的设计思想，但通过 “自顶向下、逐步细化、模块化” 的方法，将软件的复杂度控制在一定范围内，从而从整体上降低了软件开发的复杂度。

结构化编程的风靡在一定程度上缓解了软件危机，然而随着硬件的快速发展，业务需求越来越复杂，以及编程应用领域越来越广泛，第二次软件危机很快就到来了。第二次软件危机的根本原因还是在于软件生产力远远跟不上硬件和业务的发展。

1. 第一次软件危机的根源在于软件的 “逻辑” 变得非常复杂；
2. 第二次软件危机主要体现在软件的 “扩展” 变的非常复杂。

结构化程序设计虽然能够缓解软件逻辑的复杂性，但是对于业务变化带来的软件扩展却无能为力。软件领域迫切希望找到新的银弹来解决软件危机，在这种背景下，面向对象的思想开始流行起来。

虽然面向对象开始也被当做解决软件危机的银弹，在一定程度上解决了软件 “扩展” 带来的复杂性。但事实证明，和软件工程、结构化程度设计一样，面向对象也不是银弹，而只是一种新的软件方法而已。

随着软件系统规模的增加，计算相关的算法和数据结构不再构成主要的设计问题。当系统由许多部分组成时，整个系统的组织，也就是所说的 “软件架构”，产生了一系列新的设计问题。比如：

1. 系统规模庞大，内部耦合严重，开发效率低；
2. 系统耦合严重，牵一发动全身，后续修改和扩展困难；
3. 系统逻辑复杂，容易出问题，出问题后很难排查和修复；

可见，第一次软件危机引出了 “结构化编程”，创造了 “模块” 概念；第二次软件危机引出了 “面向对象编程”，创造了 “对象” 概念；直到 “软件架构” 的产生，创造了 “组件” 概念。

“模块”、“对象” 和 “组件” 本质上都是对达到一定规模的软件进行拆分，差别只是在于随着软件的复杂度不断增加，拆分的粒度越来越粗，拆分的层次越来越高。

简而言之，软件架构的目的就是描述系统实现的蓝图（Blueprints），本质是为了管理软件的复杂性。其价值应该只围绕一个核心命题：控制复杂性，效率最大化。

软件架构分类

业务架构

由业务架构师负责，也可以称为业务领域专家、行业专家。

业务架构属于顶层设计，其对业务的定义和划分会影响组织结构和技术架构。包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象。

一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓。

所有问题的前提要搞清楚我们今天面临的业务量有多大，增长走势是什么样，而且解决高并发的过程，一定是一个循序渐进逐步的过程。合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。

例如，阿里巴巴在没有中台部门之前，每个业务部门的技术架构都是烟囱式的，淘宝、天猫、飞猪、1688 等各有一套体系结构。而后，成立了共享平台事业部，打通了账号、商品、订单等体系，让商业基础实施的复用成为可能。

应用架构

由应用架构师负责，需要根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等，包括抽象层和编程接口，并尽量将应用的复杂度控制在一个可以接受的水平。

简而言之，应用架构定义系统有哪些应用、以及应用之间如何分工和合作。应用作为独立可部署的单元，为系统划分了明确的边界，深刻影响系统功能组织、代码开发、部署和运维等各方面。

应用架构和业务架构是相辅相成的关系，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维护性的同时，确保应用满足非功能属性要求（性能、安全、稳定性等）。业务架构的每一部分都有应用架构。

应用架构图关键有 2 点：

1. 职责划分：明确应用（各个逻辑模块或者子系统）边界。
   1. 逻辑分层；子系统、模块定义；关键类。
2. 职责之间的协作。
   1. 接口协议：应用对外输出的接口。
   2. 协作关系：应用之间的调用关系。

应用分层有 2 种方式：

1. 一种是水平分（横向），按照功能处理顺序划分应用，比如：把系统分为 Web前端、中间服务、后台任务，这是面向业务深度的划分。
2. 另一种是垂直分（纵向），按照不同的业务类型划分应用，比如：进销存系统可以划分为三个独立的应用，这是面向业务广度的划分。

应用架构应该反映应用之间如何协作，共同完成复杂的业务流程，主要体现在应用之间的通讯机制和数据格式，通讯机制可以是同步调用、异步消息、共享 DB 访问等，数据格式可以是 TEXT、XML、JSON、二进制等。

系统采用什么样的应用架构，受业务复杂性影响，包括企业发展阶段和业务特点；同时受技术复杂性影响，包括 IT 技术发展阶段和内部技术人员水平。业务复杂性（包括业务量大）必然带来技术复杂性，应用架构目标是解决业务复杂性的同时，避免技术太复杂，确保业务架构落地。

数据架构

对于规模大一些的公司，数据治理是一个很重要的课题。如何对数据收集、数据处理提供统一的服务和标准，是数据架构需要关注的问题。其目的就是统一数据定义规范，标准化数据表达，形成有效易维护的数据资产，搭建统一的大数据处理平台，形成数据使用闭环。

数据架构指导数据库的设计，不仅仅要考虑开发中涉及到的数据库，实体模型，也要考虑物理架构中数据存储的设计。

代码架构

代码架构主要为开发人员提供切实可行的指导，如果代码架构设计不足，就会造成影响全局的架构设计。比如公司内不同的开发团队使用不同的技术栈或者组件，结果公司整体架构设计就会失控。

代码架构主要定义：

1. 代码单元：
   1. 配置设计；
   2. 框架、类库。
2. 代码单元组织：
   1. 编码规范，编码的惯例；
   2. 项目模块划分；
   3. 顶层文件结构设计。
   4. 依赖关系。

系统架构

分布式系统基本是稍具规模业务的必选项。它需要解决服务器负载，分布式服务的注册和发现，消息系统，缓存系统，分布式数据库等问题，同时架构师要在 CAP（Consistency，Availability，Partition tolerance）之间进行权衡。

部署架构

部署架构关注软件元件是如何放到硬件上的，包括机房搭建、网络拓扑结构，网络分流器、代理服务器、Web 服务器、应用服务器、报表服务器、整合服务器、存储服务器和主机等。

还包括系统部署了几个节点，节点之间的关系，服务器的高可用，网路接口和协议等，决定了应用如何运行，运行的性能，可维护性，可扩展性，是所有架构的基础。

运维架构

负责运维系统的规划、选型、部署上线，建立规范化的运维体系。

架构层级