架构师职责及要求

架构师职责：

l  编写架构文档

l  开发编程框架

l  重构代码

l  设计系统架构

l  技术选型

l  解决技术应用中问题

l  优化系统性能

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

l  保障系统安全且高可用

l  大数据应用

l  技术创新

l  沟通管理。

能力要求：编程、基础技术掌握、常用技术理解与应用、性能优化与分析故障、常用架构模式和框架理解与应用、建模及编写设计文档、业务理解与功能/非功能模块拆解、快速学习、沟通及领导能力。

软件架构

什么是软件架构

对软件整体结构和组件的抽象描述，用于指导大型软件系统各方面的设计与开发。

如何做架构：

架构元素和元素间关系构成软件架构；架构视图组成架构文档，视图描述了系统相关方的关注点，包括功能如何实现，性能如何提升，不同用户如何做隔离（多租户隔离），未来功能如何扩展。

不同阶段输出的架构文档不同，初期是给给老板、相关方看的架构视图；中期给开发工程师看的系统组件图及类图等。

架构师的目标：

软件技术的进步使得程序员不需要了解技术细节和原理就能开发出能用的软件。

让程序员关注更少的事情有助于提供软件开发效率和质量。

架构师是做架构设计、对系统架构负责，推动架构落地。

软件开发本质及方法

4+1 视图

由于单一视图无法完整表达框架，因此需具备完整视图集。

l  逻辑视图：设计对象模型；

相关方：客户，用户，开发组织管理者。

视角：系统的功能元素，以及它们接口，职责，交互。

主要元素：系统，子系统，功能模块，子功能模块，接口。

用途：开发组织划分，成本、进度评估。

示例：功能模块图、子系统关系图（均属于逻辑视图的一种）

l  开发视图：描述了开发环境中软件的静态组织结构；

相关方：开发、测试相关人员。

视角：系统如何开发实现。

主要元素：描述系统的层，分区，包，框架，系统通用服务，业务通用服务，类和接口，系统平台和相关基础框架。

用途：指导开发组织设计和开发实现。

示例：类图

l  物理视图：描述软件到硬件的映射，反映了部署特性；

相关方：系统集成商，系统运维人员。

视角：系统逻辑组件到物理节点的物理部署和节点之间物理网络配置。

主要元素：物理节点以及节点间的通信。

l  过程视图：捕捉设计的并发和同步特征；

相关方：性能优化，开发相关人员。

视角：系统运行时线程、进程情况。

主要元素：系统进程，进程以及处理队列等。

示例：如下图

l  场景视图：描述用例场景；

相关方：用户，设计，开发人员

视角：概括了架构上最重要的场景（最典型或最有风险）及非功能性需求，通过这些场景的实现，阐明了架构的广度或众多架构元素运行的方式。

示例：用例图

总结：4+1 视图架构设计中并不常用，仅是一个维度方面启发，在做设计过程中，更多是用 UML。

什么是模型

模型是一个系统完整的抽象。对某个领域特定问题的求解及解决方案，对它们理解和认识都蕴含在模型中。

如果不对领域问题进行建模、抽象，仅是对系统功能进行堆叠，随着系统不断复杂，最终导致系统会难以维护。

所以需要对领域问题进行分析、抽象，构建领域模型、设计模型。

模型是软件设计的关键，而软件架构设计，要做领域模型设计和系统设计。

为什么要建造模型

目的：1.为与他人沟通，告知他人我对领域问题的认知、对设计的抽象，设计方案是否可靠；2.为保证软件设计的最终成果；3.通过模型理解设计者最初意图；

何时画图

l  讨论、交流

l  最终设计文档；

n  只保留少量、重要图

n  避免涉及过多内容和实现细节

UML 图

作用

描述某个问题领域。

描述构思中软件设计。

描述已经完成的软件实现

UML 图分类-静态图

静态图：通过描述类、对象和数据结构以及它们之间存在的关系，来描述软件要素中不变的逻辑结构。

l  用例图：描述系统功能，从执行者角度理解系统，描述执行者和系统之间的关系。

描述系统功能需求。在宏观上给出模型总体轮廓，通过典型用例分析，是开发者了解用户需求。

需求分析阶段使用。

l  对象图：描述参与交互的各个对象在交互过程中某一时刻的状态。可以看做是类图在某一时刻的实例。

l  类图：描述类、接口、协作以及它们之间的关系。

描述系统功能、模块，以及它们里面的核心类信息（类名称、方法、成员变量及方法），类之间关系。

详细设计阶段使用。

l  组件图：描述系统模块、组件之间的关系。

1.     物理组件：Windows 开发出来的 dll，java 打出的 jar 包

2.     逻辑组件: 系统设计由哪些组件构成，之间关系是什么样子，系统设计中重要组成。

l  包图：类的集合，更高阶的模块化之间的关系。

l  部署图：描述部署软件系统的硬件物理架构。

系统部署在哪些服务器上，服务器之间依赖关系，系统最大的一张蓝图，在概要设计中使用。

UML 图分类-动态图

l  状态图：描述对象、子系统、系统的生命周期。

描述状态变迁，例如：订单状态。

l  活动图：描述操作实现中的工作以及用例实例或对象中的活动，活动图是状态图的变种。

UML 中没有流程图，如果想要表达流程信息，可用活动图。

泳道可以进一步描述活动的对象，可以跨域几个领域（每个领域都是一个泳道）描述整个处理逻辑和流程。

l  时序图：一种交互图，描述对象直接动态合作关系以及合作中行为次序，常用来描述一个用例的行为。

描述对象之间动态交互行为，着重体现对象间消息传递的时间顺序。

可以描述不同系统、不同维度；系统或对象之间交互。

时序图中的方块是广义对象（类、组件、子系统、服务器）。

l  协作图：用于描述相互合作的对象间相互关系，它描述的交互关系是对象间消息连接关系。

软件设计各个阶段 UML 图

通用元素模型

模型元素之间关系

依赖：用带箭头的虚线表示，由依赖的一方指向被依赖的一方。

示例描述：1A 类是 B 类中的（其中方法的）局部变量；

2.A 类是 B 类方法当中的一个参数（B 类依赖 A 类）；

3.A 类向 B 类发送消息，从而影响 B 类发生变化；

继承：描述父类与子类之间的关系。

示例描述：

1.子类与父类应该完全一致，父类所具有的属性、操作，子类应该都有；

2.子类中除了与父类一致的信息以外，还包括额外的信息；

3.可以使用父类的实例的地方，也可以使用子类的实例；

实现：规定接口和实现类或构建结构的关系，接口是操作的集合，而这些操作就用于规定类或者构建的一种服务。

类型：1.双向关联；2.单向关联；3.自关联；

关联：类之间联系，用于表示一类对象与另一类对象之间有联系。如客户和订单，每个订单对应特定的客户，每个客户对应一些特定的订单。

类型：1.双向关联；2.单向关联；3.自关联；

聚合：表示的是整体和部分的关系，成员对象可以脱离整体对象独立存在。

示例：汽车包含发动机，整体类车和成员类发动机，就构成聚合关系。

组合：表示的也是整体和部分的关系，成员类的存在依赖于整体类，部分和整体具有统一的生存期。

示例：公司和部门，公司 A 的研发部不可能和公司 B 的研发部对换。

UML 中消息

l  简单消息：

表示控制流，描述如何从一个对象传递到另一个对象，但不描述通信细节。

l  同步消息：时序图中对象一级都是简单同步消息。

一种嵌套控制流，操作调用实现。操作执行者要等消息相应操作执行完毕后并回送一个简单消息后，再继续执行。

l  异步消息：时序图中组件或子系统之间一般会用到异步消息

一种异步控制流，消息发送者在消息发送后就继续执行，不在等待消息处理。

什么是架构文档

软件设计中会输出若干 UML 图描述系统架构及其内部元素之间的关系，将 UML 图和文字描述结合起来形成架构文档。

文档组成

1.       设计概述

功能概述：描述系统背景、主要功能

非功能约束：包括性能、可用性、维护性、安全性

2.       系统部署图与整体设计图

系统部署图：描述整个系统软件映射的物理结构

子系统设计图：时序图、活动图

3.       子系统设计

子系统组件图：时序图、活动图

组件设计：组件类图、组件状态图