系统架构的本质

系统架构的本质可以从以下几个核心维度进行深入理解：

1. 架构是对系统高层结构与行为的定义 

系统架构的本质首先在于它是软件系统的高层结构。架构师在进行设计时，通常不会关注具体的细枝末节的功能实现，而是着眼于粗略的、概要的、轮廓性的框架结构。同时，架构也定义了系统的行为，但这主要指的是交互行为，例如组件之间的调用、依赖、扩展关系，以及组件与环境之间的交互。

2. 架构聚焦于系统的“主要元素” 

架构设计并不是要面面俱到，而是要关注系统中的主要元素。根据资料，主要元素包含两类：

• 核心功能：用户关注的重点、难点功能，或者具有特色亮点的功能。

• 质量属性：解决系统重要特性的元素，即通常所说的质量属性，如高性能、高可用性、安全性等。这些是架构设计时需要重点关注的对象。

3. 架构的核心在于“平衡”利益相关者的需求 

这是架构极其重要的一个本质特征。系统利益相关者（Stakeholders）不仅指直接使用系统的人，还包括所有对系统感兴趣或有关联的人、团队或组织（如客户方老板、开发人员、测试人员、运维人员等）。

• 冲突与矛盾：不同的利益相关者关注点往往不同，甚至相互冲突。例如，老板希望省钱，用户希望高性能，而安全部门要求高安全性（可能损耗性能）。

• 平衡的艺术：做架构的本质过程，就是去平衡这些不同甚至矛盾的关注点，以满足各方的需要。

4. 架构是基于证据的决策具体化 

架构设计不是凭空想象或“拍脑门”决定的，而是基于合理的证据使决策透明化和具体化。这些证据可以是：

• 同类成功产品的参考。

• 架构团队过往的设计经验。

• 专门为验证架构可行性而做的实际测试（如 PoC）。

5. 架构与环境及团队的双向影响

• 受环境制约：架构会受到外部环境的深刻影响，包括法律法规、行业标准，以及必须融合或交互的既有遗留系统。

• 反作用于团队：架构也会反过来影响开发团队的结构。例如，如果决定采用微服务架构，开发团队的建设和组织方式就需要与之匹配（这也体现了康威定律的某种形式）。

软件架构的高层结构与宏观骨架

软件系统架构中的“高层结构”具体指代的是一种宏观的、整体的骨架，而非细节的堆砌。

具体来说，它可以从以下三个方面来理解：

1. 定义：粗略的轮廓 高层结构是指软件系统比较粗略的、概要的、轮廓性的结构。它不是对系统面面俱到的描述，而是对系统整体形态的一种抽象概括。

2. 关注点：重框架，轻细节 在定义高层结构时，架构师不会去关注具体的细枝末节的功能实现。

• 不做： 纠结于某个具体按钮的逻辑或某个小功能的代码实现。

• 要做： 将着眼点放在支撑整个系统的宏观框架之上。

3. 形象类比：大楼的梁柱 为了帮助理解，资料中使用了一个直观的比喻： 如果将软件系统比作一栋已经修建好的大楼，那么“高层结构”并不是指房间里的装饰或家具，而是指在修楼时搭建起来的梁柱与框架（框框）。

总而言之，高层结构是系统的骨架。就像大楼必须先有梁柱框架才能填充墙体和装修一样，软件架构的高层结构为后续的具体功能开发和交互行为定义了基础的边界和支撑体系。

软件架构设计的核心要素与焦点

在架构设计中，架构师通常不会关注所有细致的功能实现，而是将精力集中在系统的主要元素上。这些主要元素具体包含以下两个方面：

1. 用户视角的核心功能 从用户角度来看，架构设计应重点关注那些重点难点的功能，或者被视为系统特色亮点的功能。这些功能通常决定了系统的核心价值和竞争力。

2. 解决重要特性的元素（质量属性） 这是架构设计中极为重要的一部分，指为了满足系统重要特性而存在的元素。这些特性通常被称为质量属性，主要包括：

• 高性能

• 高可用性

• 安全性

架构师需要重点关注那些能够解决上述质量属性问题的元素。

简而言之，架构设计并不是要面面俱到地关注所有功能细节，而是要抓住“主要矛盾”：即核心的业务亮点功能以及支撑系统运行质量的关键属性（如性能、安全等）。

系统架构中的利益相关者识别与平衡之道

系统利益相关者的界定范围非常广泛，并不局限于直接操作系统的用户。只要是对系统感兴趣，或者与系统存在某种联系的人、团队或组织，都可以被界定为系统利益相关者。

具体来说，这些群体可以分为以下几类：

1. 客户方（需求方）群体

• 出资人/决策者（如客户方老板）： 他们可能永远不会直接使用软件，但他们负责买单，并对系统提出宏观要求（如成本控制、性能指标、可扩展性等），因此是重要的利益相关者。

• 直接用户： 实际参与业务操作、直接使用系统功能的人员。

• 管理与监管部门： 例如系统管理部门或安全部门，他们会对系统的安全性、合规性提出严格要求。

2. 开发方（构建方）群体 所有参与系统构建全生命周期的人员均属于利益相关者，涵盖了从需求调研到项目落地的各个环节：

• 需求调研人员

• 设计与架构人员

• 开发人员

• 测试人员

• 运维人员

• 项目管理人员

核心洞察：利益相关者的本质是“关注点冲突” 界定这些群体的意义在于，不同的利益相关者通常拥有不同的关注点，这些关注点往往是相互冲突甚至矛盾的。

• 老板可能关注“省钱”（成本）。

• 用户可能关注“高性能”（体验）。

• 安全部门可能关注“高安全性”（但这往往会损耗性能并增加开发成本）。

因此，识别这些群体是架构师工作的前提，因为架构设计的核心任务之一就是去平衡这些不同群体之间的矛盾需求。

系统架构设计的证据驱动决策指南

在系统架构设计中，“基于合理证据决策”是指将架构设计从一种凭空想象（“拍脑门”）的主观行为，转变为一种透明化、具体化的客观过程。

架构师不能仅凭一时冲动（“头一热”）来决定架构形式，而必须依赖直接或间接的合理证据来支撑决策,。具体来说，可以通过以下三种主要途径来获取这些证据：

1. 参考同类成功产品（外部参照） 考察同类产品中已经获得成功的案例，分析它们采用了什么样的架构形式。既然别人已经通过这种架构取得了成功，那么这就可以作为一种合理的参照证据，证明该路径是可行的。

2. 依托团队过往经验（内部积淀） 架构师个人或架构团队在过往项目中积累的设计经验也是重要的证据来源。利用经过验证的经验法则来指导当前的设计，可以降低决策风险。

3. 进行实际测试验证（实证研究） 这是最直接的证据来源。专门为了验证架构的某种设计思路，去设计一些架构方面的验证测试（通常指 PoC，概念验证）。通过实际运行的测试数据和结果来证明该设计是可行的。

基于合理证据决策的本质，就是为了让架构决策过程变得透明化和具体化，确保每一个设计选择背后都有据可依，而不是基于猜测或盲目的直觉。

技术架构与团队组织的双向重塑

系统架构不仅仅是被动地由团队创造出来的，它还会反过来影响和重塑开发团队的结构。

具体来说，这种影响体现在以下方面：

1. 架构决策决定组织形式 当架构师确定了某种特定的架构风格或技术路线时，为了顺利实施该架构，开发团队的建设和组织方式必须随之调整，以实现与该架构的匹配。

2. 典型案例：微服务架构 资料中举了一个非常典型的例子来说明这一点：

• 架构决策：假设系统已经被决定采用微服务架构（Microservices Architecture）。

• 团队影响：由于微服务架构将系统拆分为多个独立的服务，相应的，开发团队的结构就需要按照匹配微服务开发的方式来进行建设和组织。

    ◦ 这意味着团队可能需要拆分成多个由全栈开发人员组成的小型自治小组（Squads），而不是按照传统的前端组、后端组、DBA组来划分。

总结 简而言之，技术架构的选型会驱动组织架构的变革。你不能试图用一个旧的、不匹配的团队结构去强行实施一种新的、复杂的架构模式。