系统架构最佳实践 -- 系统架构设计师(上)

前言

从本篇开始，梳理关于软考的「系统架构设计师」的文章，如果不对，还望指出。

1.1 系统架构

系统架构是系统的一种整体的高层次的结构表示，是系统的骨架和根基，其决定了系统的健壮性和生命周期的长短。

架构的定义来源于IEEE 1471-2000，架构是体现在组件中的一个系统的基本组织、它们彼此的关系与环境的关系及指导它的设计和发展的原则。

例如Java平台标准版8，也可以说是Java平台的架构，从图中可以看到Java相关结构。

图来自：https://docs.oracle.com/javase/8/docs/index.html

再举一个例子，那就是作为开发人员常常使用的MySQL数据库，一款存储数据的数据文件管理系统，来看看InnoDB 的架构图

图来自：https://dev.mysql.com/doc/refman/8.4/en/innodb-architecture.html

上述两个架构图不懂也没关系，我们考试不考上面的图，只是在这里来讲解什么是架构给一个概念。通俗地说，

【系统架构】

系统架构 (System Architecture)是系统的一种整体的高层次的结构表示，是系统的骨架和根基，支撑和链接各个部分，包括组件、连接件、约束规范以及指导这些内容设计与演化的原理，它是刻画系统整体抽象结构的一种手段。系统架构设计的目的是对需要开发的系统进行一系列相关的抽象，用于指导系统各个方面的设计与实现，架构设计在系统开发过程中起着关键性作用，架构设计的优劣决定了系统的健壮性和生命周期的长短。

1.2 软件架构定义

【软件架构】

软件架构（也可称为体系结构）是用来刻画软件系统整体抽象结构的一种手段，软件架构设计也是软件系统开发过程中的一个重要环节。

1.3 软件架构发展阶段

1、软件复杂、易变，其行为特征难以预见，软件开发过程中需求和设计之间缺乏有效的

转换，导致软件开发过程困难和不可控。

2、随着软件系统的规模越来越大、越来越复杂，整个系统的结构和规格说明就显得越来

越重要。

3、对于大规模的复杂软件系统，相较于对计算算法和数据结构的选择，系统的整体结构

设计和规格说明已经变得明显重要得多。

4、对软件系统结构的深入研究将会成为提高软件生产率和解决软件维护问题的最有希望

的新途径。

随着上述问题，软件架构应运而生，而在这些问题的基础上，可以将软件架构的发展归纳为四个阶段，分别是基础研究阶段、理论体系完善和发展阶段、概念体系和核心技术形成阶段、普及应用阶段。

1.4 软件架构在软件开发中的意义

软件架构是软件生命周期中的重要产物，它影响软件开发的各个阶段。

● 需求阶段：把软件架构有的概念引入需求分析阶段，有助于保证需求规约和系统设计之

间的可追踪性和一致性。

● 设计阶段：设计阶段是软件架构研究关注最早、最多的阶段，这一阶段的软件架构主要

包括软件架构的描述、软件架构模型的设计与分析以及对软件架构设计经验的总结与复

用等。

● 实现阶段：将设计阶段设计的算法及数据类型用程序设计语言进行表示，满足设计、架

构和需求分析的要求，从而得到满足设计需求的目标系统。

● 维护阶段：为了保证软件具有良好的维护性，在软件架构中针对维护性目标进行分析

时，需要对一些有关维护性的属性(如可扩展性、可替换性)进行规定，当架构经过一

定的开发过程实现和形成软件系统时，这些属性也相应地反映了软件的维护性。

架构设计师也是随着架构概念的不断演化而逐步发展为软件开发过程中一个非常重要的

角色。

1.5 软件架构分类

典型的架构模型包括分层架构、事件驱动架构、微核架构、微服务架构和云架构等五类。

1、分层架构 (Layered Architecture)是最常见的软件架构，也是事实上的标准架构。一般情况，在分层中，会分为四层：表现层、业务层、持久层、数据库。

● 表现层 (Presentation Layer): 用户界面，负责视觉和用户互动；

● 业务层 (Business Layer): 实现业务逻辑；

● 持久层 (Persistence Layer): 提供数据， SQL语句就放在这一层；

● 数据库 (Database Layer): 保存数据。

实际上我们一般写说明性文档时，会经常将技术架构标榜在这里，也就是按照分层架构来编写，看一张图就可以明白了。

事件驱动架构、微核架构并不是我等牛马关心的，这些都是高精尖的，一般情况也不会考试这两个，着重看下定义就好了。

2、微服务架构 (Microservices Architecture) 是服务导向架构 (Service-Oriented Architecture,SOA)的升级。每一个服务就是一个独立的部署单元 (Separately Deployed Unit)。这些单元都是分布式的，互相解耦，通过远程通信协议(比如REST、SOAP) 联系。

还是得看图，看图才能明白，不过在我们一些牛马不如的公司底层，所使用的微服务架构多数都是伪命题，这其实是实现上所遗留的问题。例如不能满足于单元都是分布式的。很多情况下都是使用单一单元的有单点风险的微服务。

3、云架构 (Cloud Architecture)主要解决扩展性和并发的问题，是最容易扩展的架构。

云架构主要分成两部分：处理单元 (ProcessingUnit)和虚拟中间件 (Virtualized Middleware)。虚拟中间件又包含四个组件：

● 消息中间件 (Messaging Grid): 管理用户请求和会话控制 (sessions), 当一个请求进

来以后，它决定分配给哪一个处理单元。

● 数据中间件 (Data Grid): 将数据复制到每一个处理单元，即数据同步。保证某个处理

单元都得到同样的数据。

● 处理中间件 (Processing Grid): 可选，如果一个请求涉及不同类型的处理单元，该中

间件负责协调处理单元。

● 部署中间件 (Deployment Manager): 负责处理单元的启动和关闭，监控负载和响应时

间，当负载增加，就新启动处理单元，负载减少，就关闭处理单元。

1.6 软件架构建模

软件架构的模型分成4种：结构模型、框架模型、动态模型和过程模型。

● 结构模型：这是一个最直观、最普遍的建模方法。此方法以架构的构件、连接件和其他概念来刻画结构。并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格和性质。研究结构模型的核心是架构描述语言。

● 框架模型：框架模型与结构模型类似，但它不太侧重描述结构的细节，而更侧重整体的结构。框架模型主要以一些特殊的问题为目标建立只针对和适应问题的结构。

● 动态模型：动态模型是对结构或框架模型的补充，主要研究系统的“大颗粒”行为的性质。例如，描述系统的重新配置或演化。这里的动态可以是指系统总体结构的配置、建立或拆除通信或计算的过程，这类系统模型常是激励型的。

● 过程模型：过程模型是研究构造系统的步骤和过程，其结构是遵循某些过程脚本的结果。

1.7 软件架构风格

现代大型软件，很少使用单一的架构风格进行设计与开发，而是混合多种风格，从不同视角描述大型软件系统的能力，并可保证软件系统的可靠性、可扩展性、可维护性等非功能属性的正确描述。

• 管道-过滤器风格：适用于将系统分成若干独立的步骤；
• 主程序/子系统和面向对象的架构风格：可用于对组件内部进行设计；
• 虚拟机风格：经常用于构造解释器或专家系统；
• C/S 和 B/S 风格：适合于数据和处理分布在一定范围，通过网络连接构成系统；
• 平台/插件风格：适用于具有插件扩展功能的应用程序；
• MVC 风格：被广泛地应用于用户交互程序的设计；
• SOA 风格：应用在企业集成等方面；
• C2风格：适用于GUI 软件开发，用以构建灵活和可扩展的应用系统；

总结

章节在实际考试中分数占用率较少，多数会出现一个选择题，但是针对我们开发人员来讲了解基础和背景，立志成为一个系统架构设计师，却是一个垫脚石。

邀您共同加入产品经理修炼之路：