【总结】架构师如何做架构

日拱一卒



架构师是什么

根据维基百科，对架构师有如下定义：

系统架构师（System Architect，簡稱SA或SAr），是在信息系统研发中，负责依据需求来确定主要的技术选择、设计系统的主体框架结构，并负责搭建实施的人。他们（与系统分析师共同）确立系统的主体架构和实现方向，并负责指导软件工程师等开发人员的编码开发工作。

可以看到架构师贯穿了信息系统整个生命周期，从需求分析到上线实施，并需要对之负责的人。在实际工作中，架构师并不是一个位置，更多是一个角色。特别是在创业或小型公司中，并没有架构师这一职位，而是由技术经理承担这一角色，或产品经理和技术经理分摊了架构师的角色。并不是只有在大公司需要架构师帮助复杂系统进行架构，即使只有2-3个人的团队中，也是需要有“架构师”的。不管是大型系统还是单服务的系统都是需要进行架构工作，架构工作是对系统的需求分析，技术选择，组件抽象，部署实施等等工作综合，帮助系统从无到有，预先设计规划，起到蓝图的工作。拓展开来，架构师并不仅仅存在于信息领域，生活中方方面面，都有着架构师的存在，只不过他们叫其他名字，老师，公司老板，家长等等。比如：老师就是自己授课的“架构师”，老师需要确定课程的目的，组成部分，授课的方式，在课堂中以什么方式组织知识点能够帮助学生理解，让真正学会。他们都在做着“架构师”这个角色。

架构师主要职责

在信息领域，架构师的职责包括但不限于以下职责：

• 编写架构设计文档

• 开发编程框架

• 重构软件代码

• 设计系统架构

• 进行技术选型，解决技术应用中的问题

• 优化系统性能

• 模块分解与微服务架构重构

• 保障系统安全与高可用

• 大数据应用

• 技术创新

• 沟通管理

架构师的基本素质

架构师应该具备以下基本素质。

沟通能力

架构师的工作是贯穿整个信息系统周期的，在不同的阶段需要和不同的相关方合作，沟通。其中包括老板，产品经理，开发工程师，测试工程师和运维工程师等。这就决定了架构师在和各方沟通的时候，统一利益相关方的利益，让项目能够最终成功。我觉得这是最重要的。

技术深度和广度

架构师的工作需要一定的技术深度和广度。首先要有技术深度，最好是精通1-2个技术，然后对其他相关技术做到熟练掌握，所谓触类旁通，所以架构师首先需要是一个优秀的工程师。而且优秀技术可以在工程师和产品经理中形成影响力，而影响力是形成领导力的重要一环。架构师是团队中的技术权威。

领导能力

架构师能够推动整个团队的技术进展，能在压力下作出关键性的决策，并将其贯彻到底，这就需要架构师具有领导能力。架构师在团队中需要建立领导力，里面包括个人魅力、技术能力、知识传递等等。

抽象思维和分析能力

架构师需要有抽象思维和分析的能力，这是在进行系统分析和系统分解的基本素质。只有具备这样的能力，架构师才能看清系统的整体，掌控全局。

架构是什么

根据维基百科，对软件架构定义如下：

软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。

软件架构是一个系统的草图。软件架构描述的对象是直接构成系统的抽象组件。各个组件之间的连接则明确和相对细致地描述组件之间的通讯。在实现阶段，这些抽象组件被细化为实际的组件，比如具体某个类或者对象。

架构的表述

软件架构和各要素之间的关系可以用下图来表示：





• 系统 需要有一个 架构

• 架构 由 架构元素 和 元素间关系 组成

• 架构 需要产出 架构文档

• 系统 的生命周期中有很多 相关方

• 架构文档 是为各 相关方 写的，不同的相关方重点及范围不同。重点是从对方的角度思考，让对方能够理解架构

• 架构文档 中有各种 架构视图

• 不同的 相关方，关注点 是不同的

• 架构视图 就是来解释 相关方 的 关注点

架构视图

架构视图有多种表示方式，其中比较有名的有4+1视图模型和UML。

4+1视图模型

4+1视图模型是有IBM总结提出的架构视图模型（具体模型）。该模型包含五个主要的视图：

• 逻辑视图（Logical View），设计的对象模型（使用面向对象的设计方法时）。

• 过程视图（Process View），捕捉设计的并发和同步特征。

• 物理视图（Physical View），描述了软件到硬件的映射，反映了分布式特性。

• 开发视图（Development View），描述了在开发环境中软件的静态组织结构。

架构的描述，即所做的各种决定，可以围绕着这四个视图来组织，然后由一些用例 （use cases）或场景(scenarios)来说明，从而形成了第五个视图。之间的关系如下图：

4+1视图模型传递出一个非常好的理念：针对不同的相关方，需要有不同层次的视图，来解释架构师脑中关于系统各个方面的思考，从而让各相关方能够很好的理解将要建设的系统。

UML

视图分类

现在，架构师更加常用的视图建模工具是UML。其中表述系统元素间静态关系的视图有如下视图，其中黑色为重要视图，是经常使用的。

• 用例图 是从用例的角度描述系统的功能需求，它是系统预期功能（用例）及其环境（参与者）的模型。用例使您能够将系统需要与系统如何满足这些需求相关联。

• 对象图 是实例 (Instance) 的表达，包括对象和数据值。静态的对象图是类图的一个实例，它是系统在某个时间点的详细状态的快照，不同之处在于类图表示了一个由类及其关系组成的抽象模型，而对象图则表达了特定时刻的实例。

• 类图 是一切面向对象方法的核心建模工具。该图描述了系统中对象的类型以及它们之间存在的各种静态关系。

• 组件图 描绘了组件如何连接在一起以形成更大的组件或软件系统。它展示了软件组件的体系结构以及它们之间的依赖关系。

• 包图 是 UML 一種用以显示包和包之间的依赖关系的结构性图表。模型图能显示系统的不同视图，例如，多层应用程序。

• 部署图 有助于模拟面向对象软件系统的物理方面。它是一个结构性图表，显示了软件产出于系统架构内如何被分发至指定目标。

表述动态关系的视图有：

• 协作图 与序列图类似，协作图也用于模拟用例的动态行为。与序列图相比，协作图更侧重于显示对象的协作而不是时间顺序。

• 序列图 根据时间序列展示对象如何进行协作。它展示了在用例的特定场景中，对象如何与其他对象交互。

• 活动图 描述了目标系统的控制流程，比如探索复杂的业务规则和操作，描述用例和业务流程。在统一建模语言中，活动图旨在模拟计算和组织过程（即工作流程）。

• 状态图 是 UML 中用来描述基于 David Harel 的状态图概念的系统行为的一种图表。状态图描绘允许的状态和转换以及影响这些转换的事件，它有助于可视化对象的整个生命周期，从而更好地理解以状态主導 (State-based) 的系统。

元素间关系

元素间重要的关系有如下：

• 依赖  依赖关系是五种关系中耦合最小的一种关系。类A要完成某个功能引用了类B，则类A依赖类B。依赖在代码中主要体现为类A的某个成员函数的返回值、形参、局部变量或静态方法的调用，则表示类A引用了类B。

• 关联 关联关系比依赖要强。发生关联关系的两个类，类A成为类B的属性，而属性是一种更为紧密的耦合，更为长久的持有关系。

• 实现 实现关系是类元与提供的接口之间的私有类型的实现关系。

• 继承 指的是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系

• 聚合 聚合用来表示集体与个体之间的关联关系。例如班级与学生之间存在聚合关系。

• 组合 组合用来表示个体与组成部分之间的关联关系。例如学生与心脏之间存在复合关系。

视图使用阶段

在软件设计的三个阶段中，分别需要如下视图来帮助理解：

需求分析：用例图、状态图、时序图、活动图

概要设计：部署图、系统级时序图、系统级活动图、组件图、组件时序图、组件活动图

详细设计：类图、类时序图、状态图、方法活动图