架构设计 相关文档，希望互相学习，****************************
****************************共同进步
知识总览
共19章内容，主要包括：
1）1绪论、2计算机系统、3信息系统、4信息安全技术、5软件工程
2）6数据库设计、7系统架构设计基础知识
3）8系统质量属性与架构评估、9软件可靠性、
10软件架构演化与维护、11未来信息综合技术
4）12信息系统架构设计、13层次式架构设计、14云原生架构设计、
15面向服务架构设计、16嵌入式系统架构设计、17通信系统架构设计、
18安全架构设计、19大数据架构设计
本文学习第1章 绪论，以下为个人笔记，希望有所帮助，共同学习。
第1章 绪论
系统架构设计师 (System Architecture Designer) 是项目开发活动中的关键角色之一。系统 架构是系统的一种整体的高层次的结构表示 ，是系统的骨架和根基，其决定了系统的健壮性 和 生命周期的长短。
本章主要内容：架构定义、发展历程、典型架构、未来发展等方面概要说明，建立架构的整体概念；然后对系统架构设计师的定义、职责、范围和工作内容等进行 讲解，并说明了对于一名合格的系统架构设计师的要求。
1.1 系统架构概述
1946年第一台计算机诞生。著名美籍匈牙利数学家冯·诺伊曼 提出"离散变量自动电子计算机" (EDVAC)，由运算器、控制器、存储器、输入、输出设备 五部分组成。该计算机的内部运算采用二进制， 而不是十进制。由于一个电子元件只有开或关两种状态，可以表示0或1 ,这就大大提高了运 算速度(十进制有0～9十种状态，用电子元件来表示要复杂得多);控制计算机运行的程序存 放在存储器中，可以自动地从一个程序指令转入下一个程序指令。
冯·诺伊曼的思想是电子计算机发展史上的里程碑，当今计算机都是依据这一理论制造的，也被称为冯·诺伊曼结构计算机。
之后，计算机被分解为 ：计算机硬件、计算机软件 两部分，----> 逐步发展为 计算机硬件系统、计算机软件系统。计算机是全球信息化发展的核心载体,信息系统的规模、复杂程度 让系统的结构变得重要。否则 系统的可靠性、安全性、可移植性、可扩展性、可用性、可维护性 影响重大。
系统架构 (System Architecture) ：是系统的一种整体的高层次的结构表示，是系统的骨架和根基，也决定了系统的健壮性 和生命周期长短。系统架构师 是承担系统架构设计的核心角色，连接用户需求 和系统进一步设计和实现的桥梁，也是系统开发早期阶段质量保证 的关键角色。系统架构师 是项目的总设计师：
1）需要掌控整体又要洞悉局部瓶颈 ，依据具体业务场景给出解决方案的总体设计人员；
2）要确认和评估系统需求，给出开发规范 ，搭建系统实现的核心构架，并澄清技术细节、扫清主要难点的技 术人员；
3）要掌握技术团队的能力需要 ，给出项目管理方法，采用合适生命周期模型，具备以 自身为核心形成团队的能力 ，并在项目进度计划和经费分配等方面开展评估，预防风险。
要成为一名系统架构设计师：应精通专业基础知识 ，具备丰富的实际工作经验 ，具有跨学科能力 和把握系统整体设计的能力。
1.系统架构的定义
架构 (Architecture)：体现在组件中的系统的基本组织、它们彼此的关系与环境的关系及指导它的设计和发展的原则。
系统：是组织起来完成某一特定功能或一组功能的组件集。
系统架构 (System Architecture) 是系统的一种整体的高层次的结构表示，是系统的骨架和根基，支撑和链接各个部分，包括组件、连接件、约束规范以及指导这些内容设计 与演化的原理，是刻画系统整体抽象结构的一种手段。
系统架构设计的目的：对需要开发的系统进行一系列相关的抽象 ，用于指导 系统各个方面的设计与实现 ，架构设计在系统开发过程中起着关键性作用，架构设计的优劣决定了系统的健壮性和生命周期的长短。 架构设计：需求分析后、系统设计前
架构设计的作用：● 解决相对复杂 的需求分析问题；
● 解决非功能属性 在系统占据重要位置的设计问题；
● 解决生命周期长、扩展性需求高 的系统整体结构问题；
●解决系统基于组件需要的集成问题；
● 解决业务流程再造难的问题。
2.发展历程
系统架构的发展历程：追溯到20世纪60年代中期爆发的一场大规模软件危机（软件生产不仅效率低，而且质量差）主要是因为软件开发的理论和方法不够系统、技术手段相对落后，软件生产主要是手工作坊式。
北大西洋公约组织 (NATO) 分别于1968年和1969年连续召开两次著名的软件会议(即N A T O会议),提出了软件工程的概念，发展了软件工程的理论和方法，为今后的软件产业的发展指明了方向。
通过避免软件开发中重复劳动的方式 提升软件开发效率并保障软件质量，软件重用 与组件化成为解决危机行之有效的方案。
软件架构的发展历程：经历了 实践 ->理论，再 理论 -->反馈指导实践的过程，已良性循环。
软件架构 自概念诞生以来，大致经历了四个发展阶段：
1)基础研究阶段(1968---1994年)：模块化开发方法
形成了软件架构的雏形，模块化开发方法已被逐步采用，为后续软件架构的发展奠定了基础。
模块化开发方法：是指把一个待开发的软件分解成若干个小的而且简单的部分，采用对复杂事物分而治之的经典原则。模块化开发方法涉及的主要问题是模块设计的规则，即系统如何分解成模块。而每一模块都可独立开发与测试，最后再组装成一个完整软件。对一个规约进行分解，以得到模块系统结构的方法有数据结构设计法、功能分解法、数据流设计和面向对象的设计等。
将系统分解成模块时，应该遵循以下规则：(1)最高模块内聚 。模块内部的元素最大限度地关联，只实现一种功能是高内聚的，具三种以上功能的模块则是低内聚的。(2)最低耦合 。是不同模块之间的关系尽可能弱，以利于软件的升级和扩展。(3)模块大小适度 。颗粒过大会造成模块内部维护困难，而颗粒过小又会导致模块间的耦 合增加。 (4)模块调用链的深度(嵌套层次)不可过多。 (5)接口简单、精炼(扇入扇出数不宜太大),具有信息隐蔽能力。 (6)尽可能地复用已有模块。
2)概念体系和核心技术形成阶段(1999---2000年)：组件化开发
软件架构概念体系的建设始于20世纪90年代， Windton W.Royce 与Waiker Royce在1991 年首次对软件架构进行了定义。从1995年起，软件架构研究领域开始进入快速发展阶段，来自于工业界与学术界的研究成 果大量出现，使得软件架构作为一个技术领域日渐成熟 。 Booch、Runbaugh和 Jacobson从另一 个角度对软件架构的概念进行了全新诠释，认为架构是一系列重要决策模式。
2000年， IEEE 1471-2000标准的发布第一次定义 了软件架构的形式化标准。这标志着软件架构理论体系已基本建立，并已具备普及应用的基础。这一阶段最重要的成果 之一就是软件组 件化技术 ，通过沿用20世纪的工业组件概念，提升了软件重用能力和质量。
组件 具有可组装性、可插拔性 。每个组件的运行仅依赖于平台 或 容器 ，组件与组件之间不存在直接的耦合关系。同时，组件和组件之间又并非绝对独立。组件经过组装后可与其他组件进行业务上的交互。组件化开发 并不等同于 模块化开发 。模块化开发只是在 逻辑上做了切分，物理上(代码) 通常并没有真正意义上的隔离 。组件化也不等同于应用集成 ，应用集成是将一些基于不同平台或不同方案的应用软件有机地集成到一个无缝的、并列的、易于访 问的单一系统中，以建立一个统一的综合应用。组件化比模块化更独立，但比应用集成结合得 更加紧密。
3)理论体系完善与发展阶段(1996年至今)：架构
随着基于组件软件架构理论的建立，与之相关 的研究方向逐渐成为软件工程领域的研究重点 ，主要包括：软件架构描述与表示、软件架构分析、设计与测试；软件架构发现、演化 与重用；基于软件架构开发方法；软件架构风格；动态软件架构等。
4)普及应用阶段(2000年至今)：
1999年是一个关键年份，召开了第一届 IFIP软件架构 会议，成立了IFIP工作组2.0与全球软件架构师协会。软件产品线 成为软件架构的一个重要分支，吸引了大量大型企业的关注。 软件产品线架构 表示一组具有公共的系统需求集的软件系统，是根据基本的用户需求对 标准的产品线架构进行定制，将可重用组件与系统独立的部分集成而得到的。
软件架构是软件生命周期中的重要产物，影响软件开发的各个阶段：
● 需求阶段：把软件架构 的概念引入需求分析阶段，保证需求规约和系统设计 的可追踪性和一致性。
● 设计阶段：是软件架构研究关注最早、最多的阶段，主要包括 软件架构的描述、软件架构模型的设计与分析以及对软件架构设计经验的总结与复用等。
● 实现阶段：将设计阶段设计的算法及数据类型用程序设计语言进行表示，满足设计、架构、需求分析的要求，从而 满足设计需求。
● 维护阶段：为保证软件有良好的维护性，针对维护性目标进行分析时，需对有关维护性的属性 (如可扩展性、可替换性)进行规定，当架构经过一定的开发过程实现和形成软件系统时，这些属性也相应地反映了软件的维护性。
3.软件架构的常用分类
典型的 架构模型包括：分层架构、事件驱动架构、微核架构、微服务架构和云架构等五类。
1)分层架构 (Layered Architecture) ，最常见的软件架构，也是事实上的标准架构。它将软件分成若干个水平层 ，每一层都有清晰的角色和分工，不需要知道其他层的细节 。层与层 之间通过接口进行通信 。分层架构通常明确约定软件一定要分成多少层，但是，最常见的是四 层结构：
● 表现层 (Presentation Layer): 用户界面，负责视觉和用户互动；
● 业务层 (Business Layer): 实现业务逻辑
● 持久层 (Persistence Layer): 提供数据， SQL语句就放在这一层；
● 数据库 (Database Layer): 保存数据。
2)事件驱动架构 (Event-driven Architecture)事件 (Event) 是状态发生变化时软件发出的通知。事件驱动架构 是通过事件进行通信的软件架构，它分成四个部分：（事件代理 前3 + 事件处理）
● 事件队列 (Event Queue): 接收事件的入口；
● 分发器 (Event Mediator): 将不同的事件分发到不同的业务逻辑单元；
● 事件通道 (Event Channel): 分发器与处理器之间的联系渠道
● 事件处理器 (Event Processor): 实现业务逻辑，处理完成后会发出事件，触发下一步 操作。
3) 微核架构 (Microkernel Architecture) 又称 插件架构 (Plug-in Architecture)是指软件的 内核相对较小，主要功能和业务逻辑都通过**插件实现。**内核 (Core) 通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信应 该减少到最低，避免出现互相依赖的问题。
4) 微服务架构 (Microservices Architecture)是服务导向架构 (Service-Oriented Architecture,SOA) 的升级 。每一个服务就是一个独立的部署单元 (Separately Deployed Unit)。 这些单元都是分布式 的，互相解耦，通过远程通信协议(比如 REST、SOAP) 联系
微服务架构分成三种实现模式：
● RESTfulAPI模式：服务通过API提供，云服务就属于这一类；
● RESTful应用模式：服务通过传统的网络协议或者应用协议提供，背后通常是一个多功能的应用程序，常见于企业内部；
● 集中消息模式：采用消息代理 (Message Broker) 可以实现消息队列、负载均衡、统一 日志和异常处理，缺点是 会出现单点失败，消息代理可能要做成集群。
5)云架构 (Cloud Architecture)主要解决扩展性和并发的问题，是最容易扩展的架构 。 高扩展性体现在将数据都复制到内存中，变成可复制的内存数据单元 ，然后将业务处理能力封装成一个个处理单元 。 若访问量增加，就新建处理单元；若访问量减少，就关闭处理单元。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里，需要进行数据持久化。
云架构主要分成两部分：处理单元 和虚拟中间件
(1)处理单元(ProcessingUnit) ：实现业务逻辑。
(2)虚拟中间件(Virtualized Middleware)：负责通信、保持会话控制 (sessions)、 数据复制、分布式处理和处理单元的部署。 虚拟中间件又包含四个组件：
● 消息中间件 (Messaging Grid): 管理用户请求和会话控制 , 当一个请求进来以后，它决定分配给哪一个处理单元。
● 数据中间件 (Data Grid) : 将数据复制到每一个处理单元，即数据同步。保证某个处理 单元都得到同样的数据。
● 处理中间件 (Processing Grid) : 可选，如果一个请求涉及不同类型的处理单元，该中 间件负责协调处理单元。
● 部署中间件 (Deployment Manager) : 负责处理单元的启动和关闭，监控负载和响应时 间，当负载增加，就新启动处理单元，负载减少，就关闭处理单元。
4.系统架构的常用建模方法
架构师在软件架构设计时，必须掌握软件架构的表示方法 ，即如何对软件架构建模。 根据建模的侧重点的不同，可以将软件架构的模型分成4种：结构模型、框架模型、动态模型 、过程模型。
● 结构模型：最直观、最普遍的建模方法。此方法以架构的构件、连接件和其他概念来刻画结构 。并力图通过结构来反映系统的重要语义内容，包括系统的配置、约束、隐含的假设条件、风格和性质。研究结构模型的核心是架构描述语言。
● 框架模型：框架模型与结构模型类似，但它不太侧重描述结构的细节，而更侧重整体的 结构。框架模型主要以一些特殊的问题为目标建立只针对和适应问题的结构。
● 动态模型：动态模型是对结构或框架模型的补充，主要研究系统的"大颗粒"行为的性 质。如 描述系统的重新配置或演化。动态可以是指系统总体结构的配置、建立或拆除通信或计算的过程，这类系统模型常是激励型的。
● 过程模型：过程模型是研究构造系统的步骤和过程，结构是遵循某些过程脚本的结果。
上述 4种模型并不是完全独立的，通过有机的结合才可形成一个完整的模型 来刻画软件架构，也将能更加准确、全面地反映软件架构。软件架构可从不同角度来描述用户所关心架构的特征。 Philippe Kruchten 在1995年提出了一个"4+1"视角模型。"4+1"模型从5 个不同的视角包括逻辑 (Logical) 视角、过程 (Process) 视角、物理 (Physical) 视角、开发 (Development) 视角和场景 (Scenarios) 视角来描述软件架构。每一个视角只关心系统的一个 侧面，5个视角结合在一起才能够反映系统的软件架构的全部内容。
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.系统架构师的定义
架构设计师是系统开发的主体角色 ，通过执行一系列活动来实施架构设计 。架构设计通过生成过程 形成最终的产品架构，架构设计师的成果是创建架构。
架构设计师是负责系统架构的人、团队或组织 (IEEE 1471-2000)。架构设计师是系统或产品线的设计责任人，是一个负责理解和管理并最终确认 和 评估非功能性系统需求 (如软件的可维护性、性能、复用性、可靠性、有效性和可测试性等), 给出开发规范，搭建系统实现的核心构架，对整个软件架构、关键构件和接口进行总体设计并 澄清关键技术细节的高级技术人员。
2.架构设计师的职责
架构设计师的职责：是技术领导 ，即 专门技能 + 领导能力。 领导能力：既体现在组织中的职位 上，也体现在架构设计师展现的品质上。
在组织中的职位 方面：架构设计师是项目中的技术领导 ，应拥有技术决策的权威 。 架构设计师和项目经理 代表项目的 公共角色，项目经理更关注管理资源、进度和成本方面的项目计划。
在架构设计师展现的品质 方面：领导力也可在与其他团队成员的交流 中展现出来， 架构设计师应该为他人树立榜样 并在制定方向方面表现出自信。
成功的架构设计师：是以人为导向 的，都应在指导并培养他们团队的成员 上花时间，以保证团队成员能够在后续项目的开发中 完整地理解架构设计师的设计思路。
其次，拥有专门技能：主要体现在除了必须非常清楚项目的总体目标 和 实施方法 外，还应是 特定的开发平台、语言、工具的大师 ，对常见应用场景能 及时给出最恰当的解决方案 ，同时要对所属的开发团队有足够的了解，能够评估该开发团队实现特定的功能需求目标 的资源代价。架构设计师必须非常关注交付的实际结果 ，并必须赋予项目在技术方面的驱动力 ，还必须能够进行决策并确保这些决策被传达、理解并始终被执行。
3.架构设计师的任务与组成
架构设计师在项目中的主要任务：
(1)领导与协调 整个项目中的技术活动(分析、设计和实施等)。
(2)推动主要的技术决策并最终表达为系统架构。
(3)确定系统架构，并促使其架构设计的文档化，文档化应包括需求、设计、实施 、部署等"视图"。
从技术角度看，架构设计师的职责：抽象设计、非功能设计、关键技术设计等三大任务。架构设计师角色 可以由一个人或一个团队来履行。所以架构设计师角色通常由多个人履行。这种方式允许技能分布于多个人，每个人都能充分运用他自己的经验。特别是在理 解业务领域和掌握各个方面技术所必须的技能上，往往由几个人才能很好地覆盖。
这个团队是拥有共同目标、执行目标 ，相互负责 ，技能互补 的一小部分人。 如果该角色由团队履行，拥有一个首席架构设计师角色 ，他不仅有先知先明的能力、还是架构团队的单点协调人 。没有这个协调人，架构团队的成员要创造出 内聚的架构 或做出决策是困难的。
优秀的架构设计师应知道：他的优势和弱势。无论架构设计师的角色是否由一个团队来履行， 架构设计师都应有好几个可信顾问的支持，这样架构设计师不仅可以了解其弱点，还可以通过 获取必要的技能或与他人一起合作来弥补其知识的缺陷，进而弥补这些弱点。最优秀的架构通 常由一个团队而不是个人创建，这仅仅因为当有多人参与进来时，使见识更广和更深。
4.架构设计师应具备的专业素质
架构设计师：作为项目的技术领导，他应熟悉业务领域知识并熟练掌握软件开发知识。优秀的架构设计师 可以做到 软件开发知识、业务领域知识 之间的平衡。
架构师应具备专业知识：
1.掌握业务领域的知识
2.掌握技术知识
3.掌握设计技能
4.具备编程技能
5.具备沟通能力
6.具备决策能力
7.知道组织策略
8.应是谈判专家
1.掌握业务领域的知识：熟悉业务也使得架构设计师能够预见可能发生的改变。由于架构受其部署环境(包括业务领域)影响很大，对业务领域的正确认识可 使架构设计师能够在可能改变的区域和稳定性方面做出更全面的决策。2.掌握技术知识：由于架构设计的某些方面明确需要技术知识，所以架构设计师应该拥有一定程度的技术水平。然而架构设计师不必是一个技术专家 ，它必须关注技术的重要因素，而不是细节。架构设计师需要理解像Java EE或.N E T这类平台上的可用关键框架 ，但是不必理解 访问这些平台 可用的每个应用程序接口 (API) 的细节 。由于技术的发展相当快速，架构设计师必须跟得上这些技术的发展。
3.掌握设计技能：设计过程是架构设计的核心内容，架构是关键设计决策的具体化，因此，架构设计师应该拥 有很强的设计技能。关键设计决策 指关键结构设计决策、特定模型的选择、指导规格说明书等。 为了保证系统的结构完整性，这些元素被代表性的广泛应用并对系统取得成功产生深远的影响。 因此，这样的元素应该由拥有相当技能的人识别出来。设计能力不可能在短时间内获得，而是多年经验积累的结果，因此，一个优秀的架势设计师是要经过多年工作实践才能成为技术领导。
4.具备编程技能：项目中的开发人员是架构设计师必须与之打交道的最重要的团队成员，而项目的最终产品 是可执行代码，只有架构设计师承认开发人员的工作价值时，在架构设计师和开发人员之间的 沟通才是有效的，尤其是在项目开发后期的缺陷更改时，双方的沟通尤为重要。因此，架构设计师应该具有一定的编程技能，即使他们在项目中不必编写代码，也必须跟上技术的更新。优秀的架构设计师通常 会有组织地参与开发并应该编写一定量的代码，如果架构设计师参与代码 实现，开发组织会从架构设计师那儿获得见识，这些见识可以直接有益于架构的专业知识本身。 架构设计师还可以通过查看他们决策和设计的第一手结果，对开发流程给出反馈。
5.具备沟通能力：与架构设计师相关的所有软技能中，沟通最重要。架构设计师应该具备有效的口头和书面 表达能力。有效的沟通可使开发组织能够充分理解架构设计师的思想，同时开发组织也能够及 时将架构设计实现中遇到的问题及时反馈给架构设计师。有效的沟通是项目成功的基础。 架构设计师能够有效地与利益相关方沟通，对于理解他们的需求及与他们就架构达成并保 持一致是非常重要的。架构设计师不是简单地将信息传达给团队，还要激励团队，架构设计师 负责传达系统愿望，以便这个愿望为大家共享，而不是只有架构设计师理解并相信。
6.具备决策能力：决策是架构设计师必须具备的能力，尤其是在很多不很明确的情况下，而且没有充足的时 间研究所有可能性时，架构设计师不能果断决策 会延误项目，失去信任。优秀的架构设计师应 承认这种情况，即使在决策时咨询其他人并营造共同参与决策的环境，进行适当的决策仍然是 架构设计师的职责，而这些决策并不总是正确的，但是架构设计师必须学会纠正这些错误决策。
7.知道组织策略：成功的架构设计师并不仅仅关心技术，还应对政治敏感并知道其在组织中的权利，利用这些知识与恰当的人进行沟通，并确保项目在适当的周期中获得支持。
8.应是谈判专家：架构设计师需要与许多利益相关者进行交流，其中的一些交流需要谈判技巧。架构设计师 应特别关注的一点是在项目中尽可能早地把风险降到最低，这对稳定架构所花费的时间有直接 影响。因为风险与需求有关，消除风险的一个途径是通过精炼需求以使这种风险不再出现，因 此，必须回退需求以便利益相关者和架构设计师达成一致。这种情形要求架构设计师是一位有效的谈判专家，能够清晰明白地表明各种折中方案的后果。
5.架构设计师的知识结构
架构设计师 综合的知识能力结构 主要包括10个方面：
(1)战略规划能力。
(2)业务流程建模能力。
(3)信息数据架构能力
(4)技术架构设计和实现能力。
(5)应用系统架构的解决和实现能力。
(6)基础 IT知识及基础设施、资源调配的能力。
(7)信息安全技术支持与管理保障能力。
(8)IT 审计、治理与基本需求的分析和获取能力。
(9)面向软件系统可靠性与系统生命周期的质量保障服务能力。
(10)对新技术与新概念的理解、掌握和分析能力。
系统架构设计师 必须是 开发团队的技术引导者。应具有很强的系统思维能力，需要能够从大量互相冲突的系统方法和工具中，判断出哪些是有效的或者是无效的，并在关键时刻能够做出科学的决策。因此，架构设计师 应当是 一个 思维敏捷、经验丰富、技术水平高超、受过良好教育的善于学习与沟通且决策能力强的人。
必须广泛了解各种技术并精通一种特定技术，至少了解计算机通用技术以便确定哪种技术最优，或组织团队开展技术评估。 优秀的架构设计师能考虑并评估所有可用来解决问题的总体技术方案。架构设计师 需要 拥有良好的书面、口头沟通技巧，一般通过可视化模型和小组讨论进行沟通并指导团队，从而确保开发人员按照架构建造系统。
因此，系统架构设计师应该是一种综合性特强的人才，其知识维度可以满足多层次、多方面的能力。多层次是指架构设计师应在技术领域的深度上掌握更多的基础知识，即必须在体系 结构、计算机软硬件与网络基础知识、系统工程、信息系统、嵌入式系统、软件安全与可靠性 等知识层面上受过良好教育并拥有自学习能力；还须在架构设计方法、架构模式、开发流程以 及各种模型等方面有丰富的经验，广泛了解各种产品和技术并精通一种特定领域的架构设计方 法。多方面是指架构设计师应在业务领域以及管理、商务、财务和法律等方面具备一定背景知 识并熟悉相关政策，这与系统架构设计师的多角色特点是紧密相关的。
1.3 如何成为一名好的系统架构设计师
1.如何衡量一名优秀架构设计师
架构设计师是一个充满挑战的职 业，需要关注很多维度和技术。
Pat Kua (原 ThoughWorks咨询师) 提出：好架构设计师是技术全面的，并6个角色特质：
● 作为领导者；
● 作为开发者；
● 作为系统综合者；
● 具备企业家思维；
● 具备战略技术专家的权衡思维与战术思维；
● 具备良好的沟通能力。
总之，做一个技术全面的架构设计师并不容易，因为有很多方面需要关注，而每个方面都有很多作为开发人员 经常不会专注并练习的技能。其实最重要的不一定是一个架构设计师的能力，而是 他们在 每个不同的领域 都有足够的专业知识。有价值的架构设计师需要在上述6个方面都具备良好的专业知识。
1 领导者：作为领导者并不一定要告诉开发人员做什么。相反，好的架构设计师会 借助讲故事、影响力、引导冲突和构建信任等领导技能，将他们的架构愿景变成现实。一个好的领导者，同时也是一个好的架构设计师。他/她会仔细听取每个参与者的意见，通过与团队 的互动调整他们的愿景。2 开发人员：一个架构设计师同时又是一个好的开发人员。通常，做出一个良好的架构选择需要权衡理想的架构状态 与 软件系统的当前状态。例如，架构设计师如不考虑技术选型与 问题域之间的匹配度，会很容易受到各种技术的诱惑------即常见的"象牙塔式架构设计师"行为模式。 此时最佳方法：让架构设计师多与开发人员待在一起，花一些时间在代码上。 了解系统的 构建方式及系统的约束，这将帮助架构设计师 在当下环境中做出正确的选择。
3 聚焦系统：经验丰富的开发人员明白代码只是软件的一部分。为了让代码可运行，还需了解代码在生产环境中运行良好所需的其他重要质量属性。他们需要考虑部署过程、自动化测试、性能、安全、可支持性等多个方面。开发人员可能以临时 的方式来实现这些质量属性，而架构设计师不仅专注于了解代码，还要了解并满足不同利益相关者 (如支持、安全和运营人员) 的需求 。一个好的架构设计师需要专注于寻找那些能够满足不同利益相关者需求的解决方案， 而不是选择针对某一个参与者的偏好或风格进行优化的工具或方法。
4 具备企业家思维：所有技术选型 考虑 成本 和 收益，就如成功的企业家是愿意承担风险 的，不但会寻求快速学习的机会和方法，也要学会做好接受失败的心理准备。架构设计师可以用类似的方式做出技术选型，收集真实世界中有 关短期和长期成本的信息，以及他们可能意识到的好处。 如 架构设计师避免承诺立即使用一个在阅读新文章时看到或在某会议上听到过的工具。相反，他们试图通过架构调研来了解工具在其环境中的相关性，以收更多信息。对于工具的选择不是基于销售量，而是考虑价值。还会寻找工具背后的隐性成本，例如工具的支持情况(如文档化程度、社区使用情况),工具可能带来的约束或长期来看可能带来的额外风险。
5 权衡策略思维与战术思维：许多团队由一些独立的开发人员一起构建软件，而每个人都倾向于选择自己最舒适或最有经验的工具和技术。好的架构设计师会持续关注可能有用的新技术、工具或方法，但不一定立 即采用它们。技术采用往往需要长期的考量。架构设计师将在团队和组织层面寻求敏捷度(允 许团队快速采取行动)和一致性(保持足够的一致性)之间的良好平衡。建立自己的技术雷达 进行练习是用 战略思维探索技术的一个有用工具。
6 良好的沟通：架构设计师需要知道，有效的沟通是 建立信任 和 影响团队以外成员的关键技能。不同群体使用不同的术语，与 其谈论模式、工具和编程概念，架构设计师需要使用听众熟悉的术语与之交流，诸如风险回报、 成本和收益等。这比单纯使用技术词汇进行沟通来得更好。架构设计师还需要认识到团队内部 沟通与外部沟通同样重要，可以使用图表和小组讨论的方式来建立和完善技术愿景，并进行书面记录(如架构决策日志或Wiki等),从而为将来留下可追溯的历史。
2.从工程师到系统架构设计师的演化
人们通常把系统架构设计师 类比为建筑师，其共同点都是做好顶层设计，充当需求方和 实施者的桥梁 。但是系统架构设计师和建筑师存在许多不同，对于建筑师而言，在成为建筑 设计师之前，是不会成为建筑工人或工程师的；而系统架构设计师 一定是从工程师成长起 来的。
工程师、架构设计师 本质区别：主要体现在技术、组织和个人成长上。
1）在技术上，架构设计师的首要工作是抽象建模 ，更重要的是 了解自己所处 的业务领域。只有对业务足够了解，才能更好地抽象和建模，也更能沉淀通用的设计方法论。 另一方面，架构设计师需要了解甚至精通 业务领域所涉及的技术领域，譬如对于互联网行业的 架构设计师，小到语言、算法、数据库，大到网络协议、分布式系统、服务器、中间件、 I D C 等等都需要涉猎。
一句话，架构设计师是技术团队的对外接口人，也应该是外部团队技术问题 的终结者。广度 + 深度，对于关键技术模块的设计，架构设计师需要有技术的权威性。
而工程师 则属于 开发团队成员，主要负责项目的具体实现工作，在架构设计师的指导和帮助下，要熟悉相关业务流程，懂得建模方法，使用已确定的开发方法进行设计、编码和测试等 工作，从掌握专用技术知识层面来讲，工程师必须熟练掌握详细的设计方法、编程语言、工具和环境。
架构设计师要成为业务和技术的桥梁 ，因此需要精通业务和技术的语言 ，要锻炼沟通能力 ， 不只 口头沟通能力，也包括用 标准化的图表 表达设计思路的能力。架构设计师需要一种学会 掌握"中庸之道"的方法。不管是技术的选型，团队的协作、培养和分工，商业诉求和成本控制，产品需求和技术诉求的匹配，很多时候都是在做权衡。可以说，架构的工作主题就是权衡， 这可能也是工程师成长为架构设计师的最大挑战。工程师经常是完美主义的，程序也总是精准 而精确的，但是 架构设计师要 习惯于不完美 和一定条件下的 不精确。工程师 主要是追求产品的 完美形态，通过自己设计出的漂亮程序以充分展示自我能力，很少考虑团队与协同，开发团队相互间为了提升，往往存在相互竞争。
系统架构设计师 一般都具备计算机科学或软件工程的知识 ，由工程师做起，然后再慢慢成长为架构设计师。
成为系统架构设计师的关键：是要培养自己的判断力、执行力、创新力。判断力是能够准确 判断系统的复杂度在哪里，能准确地看出系统的脆弱点；执行力是能够使用合适的方案解决复杂度问题；创新力是能够创造新的解决方案解决复杂度问题。
因此，要成为一个系统架构设计师，就需要不断地锻炼自己的内功 ，这些内功来源于经验、视野、思考。成长：应遵循积累经验，拓宽视野 、深度思考的原则。成长过程如下：
1.工程师阶段 典型特征是"在别人的指导下完成开发"
技术员(助理工程师) 到 一个合格的工程师：需要参加相关工作1～3年
工程师负责编码 实现，高级工程师或者技术专家会指导工程师进行编码实现。工程师阶段应该是原始的"基础 技能积累阶段",主要积累基础知识，包括编程语言、基本数据结构、开发环境、操作系统、数据库以及相关软件开发流程等。
2.高级工程师阶段 其典型特征是"独立完成开发",
从工程师成长为高级工程师需要3～5年时间。
其典型特征是"独立完成开发", 包括需求 分析、方案设计和编码实现。其中需求分析和方案设计已经包含了"判断"和"选择",只是 范围相对来说小一些，更多是在已有架构下进行设计。高级工程师主需要"积累方案设计经验",简单来说就是业务当前用到的相关技术的设计经验。
差异：其一是深度，工程师 知 道How , 高级工程师 知道Why。如 Java的各种数据结构的实现原理，因为只有 深入掌握了这些实现原理，才能对其优缺点和使用场景有深刻理解，这样在做具体方案设计的 时候才能选择合适的数据结构。
其二是理论，理论就是前人总结出来的成熟的设计经验，如 数据库表设计的3个范式、面向对象的设计模式、 SOLID 设计原则、缓存设计理论(缓存穿透、 缓存雪崩和缓存热点)等。
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分：概述、计算机硬件、计算机软件
操作系统 3分：进程管理、存储管理、文件管理、设备管理
数据库技术 3分：数据库设计、关系代数、范式、事务并发、数据库安全、新技术
嵌入式技术 3分：嵌入式硬件、嵌入式操作系统、嵌入式软件开发
计算机网络 3分（超纲较多）：OSI七层模型、TCP/IP协议族、网络生命周期、IP地址
其他计算机系统基础知识 1分：计算机语言、多媒体、系统工程
系统性能 1分：性能指标、性能设计
信息系统基础知识 3分：信息系统生命周期、开发方法、五大典型系统
信息安全技术基础 5分：安全属性、信息安全技术、网络安全技术、安全协议
软件工程 12分：概述、需求工程、系统设计、运维、测试、基于构件；
面向对象技术 3分：面向对象基础、分析设计、UML关系、图
项目管理 1分：进度管理、配置管理、质量管理、风险管理
系统架构设计 20分：架构概念、生命周期、ABSD、DSSA、架构风格、
架构复用、质量属性、架构评估
软件可靠性 2分：可靠性建模、软件可靠性设计
软件架构的演化和维护1分：架构演化分类、评估、面向对象架构演化
未来信息综合技术 3分：信息物理系统、人工智能、边缘计算、机器人、数字李生、云计算
数学与经济管理 2分：最小生成树、最短路径、网络与最大流量、线性规划、决策论
知识产权和标准化 2分：知识产权属性、保护期限、产权人确定、侵权判定
专业英语 5分：完形填空，大学英语3级难度，自学
|------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------|
| 【架构专栏】架构考试介绍 | 【架构专栏】架构知识点 |
| 【架构专栏】第1章 绪论 | 【架构专栏】第11章 未来信息综合技术 |
| 【架构专栏】第2章 计算机基础知识 | 【架构专栏】第12章 信息系统架构设计理论与实践 |
| 【架构专栏】第3章 信息系统基础知识 | 【架构专栏】第13章 层次式架构设计理论与实践 |
| 【架构专栏】第4章 信息安全技术基础知识 | 【架构专栏】第14章 云原生架构设计理论与实践 |
| 【架构专栏】第5章 软件工程基础知识 | 【架构专栏】第15章 面向服务架构设计理论与实践 |
| 【架构专栏】第6章 数据库设计基础知识 | 【架构专栏】第16章 嵌入式系统架构设计理论与实践 |
| 【架构专栏】第7章 系统架构设计基础知识 | 【架构专栏】第17章 通信系统架构设计理论与实践 |
| 【架构专栏】第8章 系统质量属性与架构评估 | 【架构专栏】第18章 安全架构设计理论与实践 |
| 【架构专栏】第9章 软件可靠性基础知识 | 【架构专栏】第19章 大数据架构设计理论与实践 |
| 【架构专栏】第10章 软件架构的演化和维护 | |
[架构专栏 知识点]
希望有所帮助，互相学习、共同进步，欢迎点赞、收藏！