1. 绪论

发表于 分类于

1 系统架构概述

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

1.1.1 系统架构的定义

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

目的是对需要开发的系统进行一系列相关的抽象，用于指导系统各个方面的设计与实现。

架构设计的作用主要包括以下几点：

  • 解决相对复杂的需求分析问题；
  • 解决非功能属性在系统占据重要位置的设计问题；
  • 解决生命周期长、扩展性需求高的系统整体结构问题；
  • 解决系统基于组件需要的集成问题；
  • 解决业务流程再造难的问题。

1.1.2 发展历程

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

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

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

1.2.1 软件架构的常用分类

目前已形成了满足不同用途的架构模式，比较典型的架构模型包括分层架构、事件驱动架构、微核架构、微服务架构和云架构等五类。当然，像C/S、B/S、 管道-过滤器和 PAC 等架构也是被广泛使用的软件架构，本节简要说明典型架构内涵。

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

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

2)事件驱动架构
事件 (Event) 是状态发生变化时软件发出的通知。事件驱动架构 (Event-driven Architecture)是通过事件进行通信的软件架构，它分成四个部分。

3)微核架构
微核架构 (Microkernel Architecture) 又称为插件架构 (Plug-in Architecture), 是指软件的内核相对较小，主要功能和业务逻辑都通过插件实现。
内核 (Core) 通常只包含系统运行的最小功能。插件则是互相独立的，插件之间的通信应
该减少到最低，避免出现互相依赖的问题。

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

5)云架构
云架构（Cloud Architecture）主要解决扩展性和并发的问题，是最容易扩展的架构。
它的高扩展性体现在将数据都复制到内存中，变成可复制的内存数据单元，然后将业务处理能力封装成一个个处理单元(Processing Unit)。若访问量增加，就新建处理单元；若访问量减少，就关闭处理单元。由于没有中央数据库，所以扩展性的最大瓶颈消失了。由于每个处理单元的数据都在内存里，需要进行数据持久化。云架构主要分成两部分：处理单元（ProcessingUnit）和虚拟中间件（Virtualized Middleware)。

1.2.2 系统架构的常用建模方法

根据建模的侧重点的不同，可以将软件架构的模型分成4种：结构模型、框架模型、动态模型和过程模型。

Philippe Kruchten 在 1995 年提出了一个“4+1”视角模型。“4+1”模型从 5 个不同的视角包括逻辑 (Logical) 视角、过程 (Process) 视角、物理 (Physical) 视角、开发(Development) 视角和场景 (Scenarios) 视角来描述软件架构。每一个视角只关心系统的一个侧面，5个视角结合在一起才能够反映系统的软件架构的全部内容。

1.3 软件架构的应用场景

不同的架构风格具有各自的优缺点和应用场景，比如管道-过滤器风格适用于将系统分成若干独立的步骤；主程序/子系统和面向对象的架构风格可用于对组件内部进行设计；虚拟机风格经常用于构造解释器或专家系统； C/S 和 B/S 风格适合于数据和处理分布在一定范围，通过网络连接构成系统等。

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

1.4 软件架构的发展未来

发展历程：软件架构自 20 世纪 40 年代起，经历 70 余年发展，主线包括模块化/面向对象编程、构件技术、面向服务开发、云技术。

未来趋势：新技术（如微服务、数据驱动、智能架构）将持续融入架构发展，未来可能出现更具突破性的新型架构。

2 系统架构设计师概述

2.1 架构设计师的定义、职贵和任务

2.1.1 架构设计师的定义

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

2.1.2 架构设计师的职责

架构设计师的职责应该是技术领导，这意味着架构设计师除了拥有专门技能外，还必须拥有领导能力。其次，拥有专门技能主要体现在除了必须非常清楚项目的总体目标和实施方法外，还应是特定的开发平台、语言、工具的大师，对常见应用场景能及时给出最恰当的解决方案，同时要对所属的开发团队有足够的了解，能够评估该开发团队实现特定的功能需求目标的资源代价。架构设计师必须非常关注交付的实际结果，并必须赋予项
目在技术方面的驱动力，还必须能够进行决策并确保这些决策被传达、理解并始终被执行。

2.1.3 架构设计师的任务

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

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

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

  1. 业务领域知识
    • 深度理解行业术语与业务模型，确保架构贴合用户需求，预判变化。
  2. 技术知识
    • 掌握关键框架（如 Java EE/.NET）的核心原理，关注技术趋势但无需精通细节。
  3. 设计技能
    • 主导关键架构决策（结构、模型选择等），依赖长期经验积累。
  4. 编程技能
    • 具备实际编码能力以与开发团队高效协作，通过参与代码实现验证设计。
  5. 沟通能力
    • 精准传达架构意图，激励团队，与利益相关方持续对齐目标。
  6. 决策能力
    • 在信息不全时果断决策，承担纠错责任，避免项目延误。
  7. 组织策略认知
    • 理解组织政治，争取关键资源与支持，推动项目落地。
  8. 谈判技巧
    • 通过需求精炼与折中方案谈判，早期消除风险，平衡多方利益。

2.3 架构设计师的知识结构

10 项核心能力

  1. 战略规划
  2. 业务流程建模
  3. 信息/数据架构设计
  4. 技术架构设计与实现
  5. 应用系统架构落地
  6. IT基础设施与资源调配
  7. 信息安全保障
  8. IT审计、治理与需求分析
  9. 系统可靠性与全生命周期质量保障
  10. 新技术/概念的理解与评估

2 个知识维度

  • 多层次深度：体系结构、软硬件、网络、系统工程、安全可靠性等技术纵深，精通至少一种特定领域。
  • 多领域广度：业务、管理、商务、财务、法律等横向知识，支撑多角色协作。

关键定位

  • 技术引导者：在冲突方案中做科学决策。
  • 综合能力：技术+业务+沟通+学习+决策的复合型人才。

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

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

一名优秀系统架构设计师的6 大角色特质与关键行为：

  1. 领导者
    以“导师”身份用故事、影响力凝聚团队，动态调整技术愿景。
  2. 开发者
    保持编码实践，防止“象牙塔”设计，确保技术选型与问题域匹配。
  3. 系统综合者
    超越代码，统筹部署、测试、性能、安全、运维等多方质量属性与利益相关者需求。
  4. 企业家
    用成本-收益思维评估技术，调研真实场景，接受失败风险，避免盲目追新。
  5. 战略+战术权衡者
    平衡组织敏捷度与技术一致性，建立“技术雷达”长期跟踪并择机引入新技术。
  6. 沟通专家
    针对不同受众切换语言（业务/技术），用可视化、文档化手段确保愿景一致、决策可追溯。

结论：技术全面≠全栈，而是在6个维度都具备“足够专业”的深度，持续学习、实践与沟通。

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

  • 首要工作是抽象建模，并深度理解业务领域。
  • 技术“广度+深度”：既通晓全栈技术（语言、算法、数据库、分布式、中间件等），又在关键模块拥有技术权威。
  • 是团队对外的技术接口和外部问题的终结者。

成长三力

  • 判断力——识别复杂度与脆弱点。
  • 执行力——用合适方案解决复杂度。
  • 创新力——创造新方案突破复杂度。