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

目录

文章目录

目录

软件架构的定义

软件架构的核心要素

软件架构的目的

软件架构分类

业务架构

应用架构

系统架构

数据架构

部署架构

运维架构

软件架构的定义

IEEE 给出的定义：

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

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

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

软件架构的核心要素

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

元素（elements）：将系统拆分为一组元素，例如：模块、组件、结构体、子系统；

关系（relationships）：不同元素之间的关系，例如：交互、依赖 、继承、组合、聚合；

属性（properties）：每个元素具备的属性，例如：名称、职责、接口、实现限制等；

原理（principles）：为什么这么设计，例如：拆分依据、设计原则、决策原因等。

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

软件架构的目的

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

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

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

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

第一次软件危机的根源在于软件的 “逻辑” 变得非常复杂；

第二次软件危机主要体现在软件的 “扩展” 变的非常复杂。

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

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

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

系统规模庞大，内部耦合严重，开发效率低；

系统耦合严重，牵一发动全身，后续修改和扩展困难；

系统逻辑复杂，容易出问题，出问题后很难排查和修复；

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

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

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

软件架构分类

业务架构

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

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

应用架构

由应用架构师负责，他需要根据业务场景的需要，设计应用的层次结构，制定应用规范、定义接口和数据交互协议等。并尽量将应用的复杂度控制在一个可以接受的水平，从而在快速的支撑业务发展的同时，在保证系统的可用性和可维护性的同时，确保应用满足非功能属性要求（性能、安全、稳定性等）。

系统架构

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

数据架构

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

部署架构

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

运维架构

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

运维

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。