架构师训练营 - 第一周学习总结

架构师如何做架构

1. 什么是架构师

架构师是做架构设计，对系统架构负责的那个人。

架构师是一顶帽子，而不是一把椅子；架构师是一个角色而不是一个职位。

2. 架构师的职责与能力

2.1 架构师的主要职责

• 编写架构设计文档

• 开发编程框架

• 重构软件代码

• 设计系统架构

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

• 优化系统性能

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

• 保障系统安全与高可用

• 大数据应用

• 技术创新

• 沟通管理



2.2 架构师的主要能力

• 编程能力

• 基础技术掌握能力

• 常用技术产品的理解与应用能力

• 性能优化与分析故障能力

• 常用架构模式和框架的理解与应用能力

• 建模以及设计文档的方法和能力

• 业务理解与功能模块及非功能模块拆解能力

• 快速学习能力

• 沟通与领导能力



3. 怎样成为架构师

3.1 获得架构师职位

拥有架构师头衔能跟顺利的做架构师的事，获得架构师职位的方式：

• 通过公司内部晋升获得架构师职位

• 通过跳槽获得架构师offer

3.2 做架构师的角色

架构师是一顶帽子，而不是一把椅子；是一个角色而不是一个职位。

so，拥有架构师职位也不一定就是真正的架构师。

那么，真正做架构师的事情，在系统中扮演架构师角色的人就是这个系统的架构师。

无论你是否有架构师职位，只要你去做系统架构设计、负责系统架构这样的事情，你就是架构师。

4. 什么是软件架构

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

——维基百科

直接上图：



一个系统的架构是由架构元素，和元素间关系组成的。

系统本身与相关方关联，系统架构关联架构文档，架构文档包含各个相关方的关注点的架构视图。

软件架构就是，为了调和满足与系统关联的各个相关方的关注点的一个系统设计方案。重点就是满足各个相关方的关注点。

5. 架构师如何做架构设计

5.1 “4+1”架构视图

软件架构 = {元素，形式，关系/约束}

单一的视图无法完整的表达架构，因此需要具备完整的视图集。

"4+1"视图模型，从5个不同的视角包括包括逻辑试图、进程视图、物理视图、开发视图、场景视图来描述软件体系结构。每一个视图只关心系统的一个侧面，5个视图结合在一起才能反映系统的软件体系结构的全部内容。



• 逻辑视图（logical View），设计的对象模型。

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

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

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

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



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

• 相关者：性能优化，开发相关人员，系统集成人员。

• 视角：系统运行时线程，进程的情况。

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

• 用途：服务于系统集成人员，方便后续性能测试。



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

• 相关者：系统安装人员，系统运维人员。

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

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

• 用途：服务于系统工程人员，解决系统的拓扑结构，系统安装，通信等问题。



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

• 相关者：编程人员，软件管理人员，测试人员。

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

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

• 用途：用来描述软件模块的组织与管理（通过程序库或子系统），服务于软件编程人员，方便后续的设计与实现。



• 场景视图（Scenarios），描述用例场景。

• 相关者：用户，设计和开发人员。

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



参考链接：https://www.doc88.com/p-1055866465921.html

6. 如何使用UML进行软件架构设计和建模

6.1 什么是模型？

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

通常，开发一个计算机系统是为了解决某个领域特定问题，问题的求解过程，就是从领域问题到计算机系统的映射。

6.2 为什么要建造模型？

建造传统模型的目的是为了证明某件事务能否工作。

建造软件模型的目的是为了是他人沟通，为了保存软件的最终成果。

6.3 UML建模

UML (Unified Modeling Language)：统一建模语言，以图形方式描述软件的概念。

UML 用途：描述某个问题领域，描述构思中的软件设计，描述已经完成的软件实现。

6.3.1 静态建模

所谓静态建模是指对象之间通过属性互相联系，而这些关系不随时间转移。

类和对象的建模，是 UML 建模的基础.。UML 的静态模型包括:

• 用例图 (User case diagram)

• 类图 (Class diagram)

• 对象图 (Object diagram)

• 包图 (Package diagram)

• 组件图 (Component diagram)

• 部署图 (Deployment diagram)

6.3.2 动态建模

动态建模是用动态模型描述系统的动态行为和控制结构。动态行为包括系统中对象生存期内可能的状态以及事件发生时状态的转移，对象之间动态合作关系，显示对象之间的交互过程以及交互顺序，同时描述了为满足用例要求所进行的活动以及活动间的约束关系。

在动态模型中，对象间的交互式通过对象间的消息的传递来完成的。对象通过相互间的通信（消息传递）进行合作，并在其生命周期中根据通信的结果来不断改变自身的状态。



动态模型主要描述系统的动态行为和控制结构，包括四类UML图:

• 状态图（state diagram）：状态图用来描述对象，子系统，系统的生命周期。

• 活动图（activity diagram）：着重描述操作实现中完成的工作以及用例实例或对象中的活动，活动图是状态图的一个变种。

• 时序图（sequence diagram）：是一种交互图，主要描述对象之间的动态合作关系及合作过程中的行为次序，常用来描述一个用例的行为。

• 合作图（collaboration diagram）：描述相互合作的对象间的交互关系，她描述的交互关系是对象间的消息连接关系。

7. 一些问题

1. 架构师做架构设计的第一张图是什么?

一般用例图不需要架构师画，做架构设计的第一张图应该是系统的部署图。



1. 概要设计，与详细设计的分界点在哪里？

系统总体设计，子系统设计，组件设计，接口设计，类设计。分界点在组件设计。接口和类属于详细设计。



1. 组件的粒度大小如何把握？

一般组件的粒度，控制在刚好够一个人能开发完成。



1. 技术的深度与广度如何去选择与平衡?

有深度才有广度，没有深度的广度是虚假的广度。