系统架构设计师【第1章】: 绪论 (核心总结)

本文主要是介绍系统架构设计师【第1章】: 绪论 (核心总结)，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1.1　系统架构概述

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

系统架构设计师是承担系统架构设计的核心角色，他不仅是连接用户需求和系统进一步设计与实现的桥梁，也是系统开发早期阶段质量保证的关键角色。

1.1.1　系统架构的定义及发展历程

通俗地说，系统架构 (System Architecture) 是系统的一种整体的高层次的结构表示，是系统的骨架和根基，支撑和链接各个部分，包括组件、连接件、约束规范以及指导这些内容设计与演化的原理，它是刻画系统整体抽象结构的一种手段。

系统架构设计的 目的 是： 对需要开发的系统进行一系列相关的抽象，用于指导系统各个方面的设计与实现，架构设计在系统开发过程中起着关键性作用，架构设计的优劣决定了系统的健壮性和生命周期的长短。我们通常把架构 设计作为系统开发过程中需求分析阶段后的一个关键步骤，也是系统设计前的不可或缺工作要点之一，架构设计的 作用 主要包括以下几点:
● 解决相对复杂的需求分析问题;
● 解决非功能属性在系统占据重要位置的设计问题;
● 解决生命周期长、扩展性需求高的系统整体结构问题;
● 解决系统基于组件需要的集成问题;
● 解决业务流程再造难的问题。

系统架构设计是成熟系统开发过程中的一个重要环节，它不仅是连接用户需求和系统进一步设计与实现的桥梁，也是系统早期阶段质量保证的关键步骤。

软件架构自概念诞生以来，大致经历了四个发展阶段:

• 1)基础研究阶段(1968—1994年)
• 2)概念体系和核心技术形成阶段(1999—2000年)
• 3)理论体系完善与发展阶段(1996年至今)
• 4)普及应用阶段(2000年至今)

1.1.2　软件架构的常用分类及建模方法

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

1)分层架构
分层架构 (Layered Architecture) 是最常见的软件架构，也是事实上的标准架构。这种架构将软件分成若干个水平层，每一层都有清晰的角色和分工，不需要知道其他层的细节。层与层 之间通过接口进行通信。最常见分层:

• 表现层（Presentation Layer）: 用户界面，负责视觉和用户互动
• 业务层（Business Layer）: 实现业务逻辑
• 持久层（Persistence Layer）: 提供数据， SQL语句就放在这一层
• 数据库（Database Layer）: 保存数据

2)事件驱动架构
事件驱动架构 (Event-driven Architecture) 是通过事件进行通信的软件架构，它分成四个部分：

• 事件队列 (Event Queue): 接收事件的入口
• 分发器 (Event Mediator): 将不同的事件分发到不同的业务逻辑单元
• 事件通道 (Event Channel): 分发器与处理器之间的联系渠道
• 事件处理器 (Event Processor): 实现业务逻辑，处理完成后会发出事件，触发下一步操作

3)微核架构
又称为插件架构，指软件的内核相对较小，主要功能和业务逻辑都通过插件实现

4)微服务架构
微服务架构 (Microservices Architecture) 是服务导向架构 (Service-Oriented Architecture,SOA)的升级。每一个服务就是一个独立的部署单元 (Separately Deployed Unit)。这些单元都是分布式的，互相解耦，通过远程通行协议联系。分成三种模式：

• RESTfulAPI模式 : 服务 通 过 A P I 提 供 ， 云 服 务 就 属 于 这 一 类
• RESTful应用模式 : 服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部
• 集中消息模式 : 采用消息代理 (Message Broker) 可以实现消息队列、负载均衡、统一 日志和异常处理，缺点是会出现单点失败，消息代理可能要做成集群

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

云架构主要分成两部分:

• 处理单元 (ProcessingUnit) ： 实现业务逻辑
• 虚拟中间件 (Virtualized Middleware) ： 负责通信、保持会话控制 (sessions)、 数据复制、分布式处理和处理单 元的部署。

根据建模的侧重点的不同，可以将软件架构的模型分成4种：

• 结构模型：这是一个最直观、最普遍的建模方法。此方法以架构的构件、连接件和其他 概念来刻画结构。并力图通过结构来反映系统的重要语义内容，包括系统的配置、约 束、隐含的假设条件、风格和性质。研究结构模型的核心是架构描述语言。
• 框架模型： 框架模型与结构模型类似，但它不太侧重描述结构的细节，而更侧重整体的 结构。框架模型主要以一些特殊的问题为目标建立只针对和适应问题的结构。
• 动态模型： 动态模型是对结构或框架模型的补充，主要研究系统的“大颗粒”行为的性 质。例如，描述系统的重新配置或演化。这里的动态可以是指系统总体结构的配置、建 立或拆除通信或计算的过程，这类系统模型常是激励型的。
• 过程模型： 过程模型是研究构造系统的步骤和过程，其结构是遵循某些过程脚本的结果。

1.1.3　软件架构的应用场景

软件架构风格在实践中已被反复使用，不同的架构风格具有各自的优缺点和应用场景，比如

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

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

1.1.4　软件架构的发展未来

架构发展的主线可以归纳为模块化编程/面向对象编程、构件技术、面向服务开发技术和云技术。其中关键的技术如图所示：

1.2　系统架构设计师概述

系统架构设计师 (System Architecture Designer) 是项目开发活动中的众多角色之一，它可以是一个人或一个小组，也可以是一个团队。架构师 (Architect) 包含建筑师、设计师、创造 者、缔造者等含义，可以说，架构师是社会各领域的创造者和缔造者。

从组织上划分，架构师通常可分为: 业务架构师 (Business Architect)、 主题领域架构师 (Domain Architect)、 技术架构师 (Technology Architect)、 项目架构师 (Project Architect) 和系统架构师 (System Architecture) 等5类。

如果参考微软公司对架构设计师的分类，这里根据架构师关注的领域不同，可将系统架构设计师分为4种:企业架构师EA(Enterprise Architect)、 基础结构架构师IA(Infrastructure Architect)、 特定技术架构师TSA(Technology Architect) 和解决方案架构师 SA(Solution Architect)。

1.2.1　架构设计师的定义、职责和任务

1.架构设计师的定义
架构设计师 是系统或产品线的设计责任人，是一个负责理解和管理并最终确认和评估非功能性系统需求(如软件的可维护性、性能、复用性、可靠性、有效性和可测试性等), 给出开发规范，搭建系统实现的核心构架，对整个软件架构、关键构件和接口进行总体设计并 澄清关键技术细节的高级技术人员。

2.架构设计师的职责
架构设计师必须非常关注交付的实际结果，并必须赋予项 目在技术方面的驱动力，还必须能够进行决策并确保这些决策被传达、理解并始终被执行。

3.架构设计师的任务与组成
架构设计师在项目中的主要任务可概述如下。

• (1) 领导与协调整个项目中的技术活动(分析、设计和实施等)。
• (2) 推动主要的技术决策并最终表达为系统架构。
• (3) 确定系统架构，并促使其架构设计的文档化，这里的文档化应包括需求、设计、实施和部署等“视图”。

从技术角度看，架构设计师的职责就是抽象设计、非功能设计和关键技术设计等三大任务。

1.2.2　架构设计师应具备的专业素质

1、掌握业务领域的知识
2、掌握技术知识
3、掌握设计技能
4、具备编程技能
5、具备沟通能力
6、具备决策能力
7、知道组织策略
8、应是谈判专家

1.2.3　架构设计师的知识结构

架构设计师综合的知识能力结构主要包括10个方面：
1、战略规划能力
2、业务流程建模能力
3、信息数据架构能力
4、技术架构设计和实现能力
5、应用系统架构的解决和实现能力
6、基础IT知识及基础设施、资源调配的能力
7、信息安全技术支持与管理保障能力
8、IT审计、治理与基本需求的分析和获取能力
9、面向软件系统可靠性与系统生命周期的质量保障服务能力
10、对新技术与新概念的理解、掌握和分析能力

系统架构设计师应该是一种综合性特强的人才，其知识维度可以满足多层次、多方面的能力。

• 多层次是指架构设计师应在技术领域的深度上掌握更多的基础知识，即必须在体系结构、计算机软硬件与网络基础知识、系统工程、信息系统、嵌入式系统、软件安全与可靠性 等知识层面上受过良好教育并拥有自学习能力;还须在架构设计方法、架构模式、开发流程以 及各种模型等方面有丰富的经验，广泛了解各种产品和技术并精通一种特定领域的架构设计方 法。
• 多方面是指架构设计师应在业务领域以及管理、商务、财务和法律等方面具备一定背景知识并熟悉相关政策，这与系统架构设计师的多角色特点是紧密相关的。

1.3　如何成为一名好的系统架构设计师

1.3.1　如何衡量一名优秀架构设计师

Pat Kua (原 ThoughWorks 咨询师) 提出:一个好的架构设计师是技术全面的，并给出了成为一个技术全面的架构设计师必须具备的6个角色特质：
1.作为技术领导者
2.作为开发人员
3.聚焦系统
4.具备企业家思维
5.权衡策略思维与战术思维
6.良好的沟通

1.3.2　从工程师到系统架构设计师的演化

系统架构设计师一般都具备计算机科学或软件工程的知识，由工程师做起，然后再慢慢成长为架构设计师。要从工程师成 长为架构设计师，应遵循积累经验，拓宽视野和深度思考的原则。

下面说明从工程师到架构设 计师的成长过程。
1.工程师阶段
要从一名技术员(助理工程师)成为一个合格的工程师需要参加相关工作1~3年时间，其 典型特征是“在别人的指导下完成开发”,这里的“别人”主要是“高级工程师”或者“技术专 家”。通常情况下，高级工程师或者技术专家负责需求分析、讨论和方案设计，工程师负责编码 实现，高级工程师或者技术专家会指导工程师进行编码实现。工程师阶段应该是原始的“基础 技能积累阶段”,主要积累基础知识，包括编程语言、基本数据结构、开发环境、操作系统、数 据库以及相关软件开发流程等。

2.高级工程师阶段
从工程师成长为高级工程师需要3~5年时间，其典型特征是“独立完成开发”,包括需求 分析、方案设计和编码实现，其中需求分析和方案设计已经包含了“判断”和“选择”,只是 范围相对来说小一些，更多是在已有架构下进行设计。高级工程师主要需要“积累方案设计经 验”,简单来说就是业务当前用到的相关技术的设计经验。

3.技术专家阶段
成长为技术专家需要4~8年时间，其典型的特征是“某个领域的专家”,通俗地讲，只要 是这个领域的问题，技术专家都可以解决。例如: Java 开发专家、嵌入式开发专家、操作系统 开发专家等。通常情况下，“领域”的范围不能太小，例如我们可以说 “Java开发专家”,但不 会说 “Java 多线程专家”或 “Java JDBC 专家”。技术专家与高级工程师的一个典型区别就是: 高级工程师主要是在已有的架构框架下完成设计，而技术专家会根据需要修改、扩展和优化架 构。从高级工程师成长为技术专家，主要需要“拓展技术宽度”,因为一个“领域”必然会涉及 众多的技术面。

需要注意的是，拓展技术宽度并不意味着仅仅只是知道一个技术名词，而是要深入去理解 每个技术的原理、优缺点以及应用场景。

4.系统架构设计师(初级)
成长为初级架构设计师需要5~8年时间，其典型特征就是能够“独立完成一个系统的架构 设计”,可以是从0到1设计一个新系统，也可以是将架构从1.0重构到2.0。初级架构设计师负责的系统复杂度相对来说不高，例如后台管理系统、某个业务下的子系统等。

初级架构设计师和技术专家的典型区别是: 初级架构设计师是基于完善的架构设计方法论的指导来进行架构 设计，而技术专家更多的是基于经验进行架构设计。简单来说，即使是同样一个方案，初级架 构设计师能够清晰地阐述架构设计的理由和原因，而技术专家可能就是因为自己曾经这样做过， 或者看到别人这样做过而选择设计方案。

但在实践工作中，技术专家和初级架构设计师的区别 并不很明显，事实上很多技术专家其实就承担了初级架构设计师的角色，因为在系统复杂度相 对不高的情况下，架构设计的难度不高，用不同的备选方案最终都能够较好地完成系统设计。

从技术专家成长为初级架构设计师，最主要的是形成自己的 “架构设计方法论”。形成自己的架构设计方法论的主要手段有:

• 系统学习架构设计方法论，包括订阅专栏或者阅读书籍等;
• 深入研究成熟开源系统的架构设计;
• 结合架构设计方法论，分析和总结自己团队甚至公司的各种系统的架构设计的优缺点，尝试思考架构的重构方案。

5.系统架构设计师(中级)
成长为中级架构设计师需要8~10年以上时间，其典型特征是“能够完成复杂系统的架构设 计”,包含高性能、高可用、可扩展、海量存储等复杂系统，例如设计一个总共100人参与开发 的业务系统等。中级架构设计师与初级架构设计师的典型区别在于系统复杂度的不同，中级架构设计师面对的系统复杂度要高于初级架构设计师。以开源项目为例，初级架构设计师可能引入某个开源项目就可以完成架构设计，而中级架构设计师可能发现其实没有哪个开源项目是合 适的，而需要自己开发一个全新的项目，事实上很多开源项目就是这样诞生出来的。从初级架构设计师成长为中级架构设计师，最关键的是“技术深度和技术理论的积累”。

6.系统架构设计师(高级)
成长为高级架构设计师需要10年以上时间，其典型特征是“创造新的架构模式”,例如: 谷歌的分布式存储架构、分布式计算 MapReduce架构和列式存储架构等开创了大数据时代;在虚拟机很成熟的背景下， Docker创造了容器化的技术潮流。高级架构设计师与中级架构设计师相比，典型区别在于“创造性”,高级架构设计师能够创造新的架构模式，开创新的技术潮流。

关于如何在专业领域内提升，有个著名的“10000小时定律”,简单来说要成为某个 领域顶尖的专业人才，需要10000小时持续不断的练习，例如小提琴、足球、国际象棋、围棋 等领域，无一例外都遵循这个定律，而技术人员的成长也基本遵循这个定律。系统架构设计师 的成长其实最关键的还是技术人员对技术的热情以及持续不断地投入，包括学习、实践、思考 和总结等。

这篇关于系统架构设计师【第1章】: 绪论 (核心总结)的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---