1. 架构的基本定义

1.1 架构组成理论

系统架构包括系统元素、基本系统属性、设计和发展原则3个主要方面。

1.1.1 系统元素

1）概念

• 系统元素：包括模块、组件、接口、子系统等日常开发中的内容。
• 系统结构：元素加上它们之间的关系。

2）静态结构和动态结构

• 静态结构 ：体现在设计时，描述系统内部设计时元素及其组合方式；
• 动态结构：关注运行时的元素及其交互方式

1.1.2 基本系统属性

• 功能属性：系统能做什么
• 质量属性：外部可见非功能性属性.如系统的性能、安全性等属性

1.1.3 设计和发展原则

• 应该是可度量、可测试和可跟踪。

常见的原则如用户操作响应时间在1s之内、用户信息需要进行安全性处理、系统可以快速集成第三方服务等。

1.2 架构的决策理论

以下两个理论体系仅是对架构定义问题的一个诠释，架构师需根据自己的情况理解。

1.2.1 统一软件过程（Rational Unified Process，统一软件过程）

• 架构
  该理论关注架构实践的主体—人，以人的决策为描述对象。架构决策不仅包括软件系统的组织、元素、子系统和架构风格等，还包括众多非功能性需求的决策。
• 决策
  当架构设计过程无法顺利进行，如碰到模块如何划分、模块之间交互方式是什么、开发技术如何选型、如何适应可能发生的变化等常见问题时，通过架构师团队根据场景和问题作出相应的决策。不断决策的过程就是问题得到不断解决、架构得到不断发展的过程。通过一系列的决策最终形成完整的系统架构。

1.2.2 决策类的架构设计过程

• 架构
  决策类的架构设计过程往往可以从系统切分出发，如把系统分成客户端和服务器端两大部分。然后基于服务器端，可以在拆分成服务适配层、业务逻辑层和数据访问层。而业务逻辑层再可以分成多个模块。如下图所示：

  
  cad73eb00964d11a519512ad6a2d0b62_f69ae0a2e6fb4a45849403d6d6fa542f.png

• 决策
  每一个切分的过程实际上就是一个决策的过程，通过合理而有效的决策促进系统架构由高层次到较低层次再到实现层次的不断演进。

1.3 架构设计与系统工程

架构设计就是以干系人提出的业务需求为源头、以技术管理和过程改进体系为工作流程、以质量为重心的一项系统工程。

在系统工程中，业务需求需要进行分析和抽象、过程需要进行管理和改进、设计质量需要进行保障，完成包含这些活动在内的整个系统架构设计工作的角色就是架构师。

1.3.1 人

• 干系人（Stakeholder）：构所需要满足的各种业务方、客户、市场、项目、产品等相关人员。

干系人是功能需求的来源，同时拥有对系统架构是否成功的判断权利。

• 架构设计本质是满足业务需求，业务架构驱动着技术架构（而不是反其道而行）。

• 系统工程的第一点核心思路：就是我们从事任何架构设计相关的工作都是为了满足干系人的需求。

1.3.2 事

• 主要包括描述架构和展示架构
  • 架构描述：使用特定的工具、特定的流程和特定的视图视角创建、记录和维护架构。
  • 架构展示：把描述出来的架构在合适的时机和场合展示给相关干系人供其参考和判断。
• 系统工程的第二个核心思路：要站在过程管理的思维模式上去看待架构设计这件事情

无论是架构描述还是架构展示都不是一步能够到位的，架构设计本身也是一个过程，过程就需要通过计划、实施、监控、管理等方法确保其执行，并通过持续改进实现过程的高效性和正确性。

1.3.3 物

• 指所设计的架构及对应的架构描述。

架构描述并不只是架构师的个人成果，而是架构师及相关干系人共同确认的成果，用于构建系统，以满足业务需求。

• 系统工程的第三个核心思路：需要提供架构设计产物的可见性，同时确保具备较高设计质量，使其能够接受来自内部和外部的评审和验证。

2. 架构师

2.1 架构师的活动与系统工程

架构师是负责设计、记录和领导能够满足所有干系人需求的系统构建过程的人。

2.1.1 架构师的工作

• 识别干系人并让他们参与进来

干系人是业务需求的源头，识别正确的干系人能够确保业务需求的正确性，让干系人参与能够确保业务需求的实时性和有效控制需求变更。

• 理解和记录系统功能和非功能相关的关注点

通过需求分析，架构师梳理并抽象系统的各项功能性和非功能性需求，并对这些需求进行系统建模。

• 创建并拥有应对这些关注点的架构定义

对功能性和非功能性需求，从扩展性（Extensibility）、性能（Performance）、可用性（Availability）、安全性（Security）、伸缩性（Scalability）等架构设计的基本要素出发定义架构。

• 在把架构实现为具体系统的过程中起主要作用

推动架构设计活动按照项目和产品计划有序进行，参与需求、设计评审等各种技术评审过程，并管理系统设计和开发团队的日常工作。

2.1.2 对项目的参与度

就一个完整的系统开发生命周期而言，架构设计活动有其时效性。下图体现了传统瀑布（Waterfall）模型下的系统开发生命周期与架构师参与情况。

从图中可以看出在由需求分析和系统建模所构成的系统初始阶段，以及由服务集成和产品接受所构成的最后交付阶段，架构师会较多地参与到系统建设过程中去。
对于类似Scrum的敏捷开发模型，如果把一个个迭代看成是小型的Water-Scrum-Fall模型的话，架构师参与程度实际上也与上图所示的结果相类似，即重点参与迭代计划阶段和迭代演示回顾阶段。

2.1.3 架构师和架构描述

• 架构师根据干系人的业务需求捕获系统功能和非功能相关的关注点，并创建架构描述。
• 架构师对架构描述这一架构设计产物具有拥有权
• 因此架构师有权力更有责任维护架构描述并管理其实时性和有效性。
• 架构师需要跟踪并验证架构定义过程的时机、参与者、技术评审和各项阶段性成果。

2.2 架构师的分类

2.2.1 根据作用

设计型、救火型、布道型、极客型等

相较于传统意义上的设计型架构师，以上类型的架构师更加偏重于执行某一项特定的架构任务，并不一定会完整参与系统开发生命周期，更不一定会从系统工程的角度去看问题。

2.2.2 根据职责

• 产品型架构师
  偏重于进行业务架构设计，往往在系统开发前期会重点参与
• 基础设施型架构师
  偏重于进行技术基础框架设计，一般采用独立于系统开发生命周期的特有开发模式
• 应用型架构师（通常意义上的架构师）
  负责将问题领域进行建模并转变成解决方案。

2.2.3 根据关注层次

功能、非功能、团队组织和管理、产品运营等。

2.3 架构师的技能和职责

作为一名合格的架构师，完备的技术领域知识是必备的技能，包括我们在1.1.2节架构演进理论中提到过的分布式系统、缓存、消息中间件、企业服务总线、搜索引擎和批量数据处理等各种目前业务主流的技术体系，也包括软件架构体系结构中所蕴含的架构风格、架构模式和架构模型思想。但针对应用设计型架构师，所需的技能不仅仅限于了解和掌握技术体系，也需要从另外两个层面进行技能拓展。
（1）业务领域知识
在应用程序开发过程中，业务架构驱动技术架构现象非常普遍。提升业务领域知识和提升技术领域知识一样，都对架构设计有直接影响。从这个角度讲，架构师应该具备跨领域的技能。
（2）软技能

2.4 架构师的基本职责

• 作为技术负责人，从问题领域出发进行抽象和建模并提供系统解决方案。
• 与项目经理合作，制定计划、分配资源、组建团队。
• 通过自身影响力和协作能力，保证项目按既定计划和成本完成。

定义并记录系统的架构、构建和部署系统的策略、确保架构满足系统的质量属性、促进系统级别决定的产出、确保相关决定与干系人的期望一致、对架构方面的各项指标做平衡性的判断并确保达成一致意见等都是架构师的职责示例。

3. 从程序员到架构师

3.1 架构师和程序员的对比

3.1.1 思维模式

• 程序员容易情绪化思维，对碰到的问题倾向于使用主观意识去寻找方法，同时又有一些顽固，钻牛角尖的场景并不少见。
• 架构师通常具备全面的思考和分析模式，倾向于使用换位思考从问题的内因、外因出发，找到团队内部和外部能够解决问题的资源，确保问题得以高效解决。

3.1.2 沟通

• 程序员普遍不善交流，表现在不善于听取别人的意见，更不善于表达自身的想法。
• 架构师了解团队和组织文化，把握政治方向，具备沟通和协商能力是基本要求。

3.1.3 学习

• 程序员学习积极性高，能力也强，但过于依赖个人经验，并不能很好把握住学习的方向，缺少系统的学习计划和目标。
• 架构师通常具备较强的自我提升意识，明白要学什么及怎么学。

3.1.4 协作

• 程序员创造力强，但在团队和组织氛围下，缺乏一定纪律性，往往从个人出发思考问题和开展活动。
• 架构师作为技术负责人，需要通过系统的工程学方法，应用项目管理知识领域及相关工程实践开展团队协作。

3.1.5 推动力

• 程序员独立思考，有好的想法但并不喜欢分享，更加不会作为推动者去主动落实这些想法。
• 架构师应具备领导力与推动力，除了技术演进，在团队价值取向、组织趋势把握、组织运营和人才发展等各个方面都可能需要发挥其主导性。

3.1.6 全局高度

• 程序员由于意识形态和经验的缺失，普遍过多关注细节而缺少大局观。
• 而架构师具备全局观，拥有独特的基于系统架构设计的视图和视角。

3.1.7 方法论

• 程序员开发能力出众，但缺乏设计和建模的方法论。
• 架构师善于把握架构设计和系统建模的角度和切入点，并使用一组用于确保成功的手段、方式和流程。

3.1.8 业务

• 程序员相比业务更喜欢钻研技术，通常不关注业务，不善于从干系人角度出发理解业务并进行抽象。
• 架构师理解干系人的业务痛点，并基于业务需求进行业务抽象和系统建模是其基本工作内容之一。

3.1.9 时间管理

• 程序员有很强的时间观念，但又不善于管理时间。
• 架构师善于采用敏捷、迭代的过程来合理安排时间，规避时间管理上的风险。

3.1.10 系统化

• 程序员拼命工作而不是聪明的工作，因为缺少系统化的工作规程。
• 架构师需要从系统工程角度出发，对软件开发、项目管理和过程改进等系统过程进行合理规划，形成统一的工作模式，确保团队成员都能在同一节奏上开展开发工作。

3.1.11 产品交付

• 程序员只关注写“高效”的代码，却不关心“高效”的产品交付。
• 架构师基于产品交付模型和工具进行产品的快速迭代及实现系统的自动化交付。

3.1.12 实用主义

• 程序员写“聪明”的代码而不是“简单”的代码，“聪明”的代码并不意味着一定能够带来更好的性能和可维护性，有时候反而成为团队知识传递的一种障碍。
• 而架构师关注实用主义，追求成功而不是完美。

3.2 转型成功的三段式模型

3.2.1 思路

• 意识形态（Mindset）

意识形态是转型的前提。意识形态很多时候决定了一个人发展的高度。

• 环境（Environment）

一个人所能达到的高度还很大程度受限于环境因素。我们往往无法改变环境，只能适应。转型之前需要判断，必要时应该果断改变。

• 决心（Determination）。

3.2.2 方法论

• 什么是方法论
  所谓方法就是做事的手段、方式、流程，而方法论即一组方法的集合。

• 方法论举例

  • 了解主流软件架构风格、模式和模型、通过整合各种架构体系形成自身的架构设计思想是一种方法论
  • 对主流架构设计方法进行阐述、把握主流技术体系知识领域及相应的原理是一种方法论
  • 围绕软件开发生命周期的系统工程，理解软件工程、业务架构、敏捷方法、产品交付等概念是一种方法论
  • 了解各种软技能需求及相应的应对方法也是一种方法论

3.2.3 工程实践

把软件开发的最佳方式和开发人员个人做得最好的事项总结出来，就是组织的最佳实践。

3.2.3 转型思维导图

3.3 架构师的工作开展

1）识别干系人

2）确定原则

架构原则代表对架构设计过程中采用的方法和意图的基本声明，并用于指导架构的定义。
最小化外部数据、用户信息需要进行安全性处理都属于典型的原则示例。在系统设计之前对一些基本原则的规划和沉淀被认为是一项比较好的工程实践，有助于在根据具体业务场景进行架构设计过程中保持架构的独立性及架构师的基本立场。

3）分析业务场景

• 场景分类
  • 功能性场景：架构视图
  • 系统场景：架构视角
• 识别方法

识别业务场景的过程可以采用从业务需求出发进行分析、跟干系人沟通、借助于架构师经验等方式。该过程的输出是一系列业务场景，确保这些业务场景按照优先级进行排序。

4）使用架构模式

是解决问题通用的方法和结构，包括发布-订阅、管道-过滤器、事件驱动架构等架构风格，也包括对象-关系行为模式、Web表现模式、分布模式架构等架构模式及各种架构模型。

5）构建系统模型

• UML

采用UML能够方便地建立系统所需的用例建模、静态建模、动态建模和架构模型。

• 领域驱动设计（Domain Driven Design，DDD）模型

6）完成技术方案

对于系统架构设计，技术方案即架构描述。
架构描述中通常包含干系人的关注点、通用架构原则、架构视图的确立、架构视角的确定、视图与视角之间的一致性和相关性等要素。

7）评估与决策

• 评估的作用：架构描述需要通过评估才能正式生效。
• 评估的目的：评估只是过程，不是结果，评估的目的是与干系人达成一致。
• 常见的评估方法：正式评审、结构化走查、场景评估、原型系统演示等。
• 架构师在评估中的作用：在各种评估活动中应该起到推动作用。

8）管理过程事务

架构师作为技术负责人，通常也担任技术团队的Leader，自然也需要参与团队资源整合、内部/外部分享和交流、Code Review、人员招聘面试、汇报等日常管理事务。

9）开发并学习

架构师通常也需要和团队一起参与核心代码编写、参加技术会议和调研新技术。

---