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

关注

发布于: 2020 年 06 月 13 日

什么是架构？架构一词源于建筑学，常指建筑物在其尺度上是如何依靠内部的支撑物相互结合而稳固构造的方式。具体到软件架构，维基百科定义为：“有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计”。系统的各个重要组成部分及其关系构成了系统的架构，这些组成部分可以是具体的功能模块，也可以是非功能的设计与决策，他们相互关系组成一个整体，共同构成了软件系统的架构。--摘自《大型网站架构技术》
下面这张图，需要牢记于心：
什么是架构师？架构师是一个角色而不是一个职位，是做架构设计、对系统架构负责的那个人。这个人既需要掌控整体，又需要洞悉局部瓶颈，并能够深入理解业务，具备较好的沟通能力，依据具体的业务场景给出解决方案。
架构师需要具备哪些能力？编程能力
基础技术掌握能力
常用技术产品的理解与应用能力
性能优化与分析故障的能力
常用架构模式与框架的理解与应用能力
建模以及设计文档的方法和能力
业务理解与功能模块及非功能模块拆解能力
快速学习能力
沟通与领导能力
架构师如何进行软件架构设计？作为架构师要记住为谁来设计架构，架构师可能同时对接公司老板、产品经理、一线开发、运维人员。单一的视图是无法完整表述架构的，因此需要具备完整的视图集。比较常用的是4+1架构视图：
逻辑视图
相关方：客户、用户和开发组织管理者。
视角：系统的功能元素，以及他们接口，职责和交互。
主要元素：系统，子系统，功能模块，子功能模块和接口。
用途：开发组织划分，成本/进度的评估。
开发视图
相关方：开发相关人员和测试人员。
视角：系统如何开发实现。
主要元素：描述系统的层，分区，包，框架，系统通用服务，业务通用服务，类和接口，系统平台和相关基础框架。
用途：指导开发组织设计和开发实现。
物理视图
相关方：系统集成商，系统运维人员，DevOps开发人员。
视角：系统逻辑组件到物理节点的物理部署和节点之间的物理网络配置。
主要元素：物理节点以及节点的通信。
过程视图
相关方：性能优化，开发相关人员。
视角：系统运行时线程，进程的情况。
主要元素：系统进程，线程以及处理队列等。
如何使用UML进行软件架构设计与建模？首先要明确为什么要建模？
模型是一个系统的完整抽象，人们对某个领域特定问题的求解和解决方案都蕴含在模型当中。
领域问题 --> 概念模型 --> 系统需求 --> 解决方案
建造软件模型的目的：
为了与它人沟通
为了保存软件设计的最终成果
说到底为模型画图的根本目的是为了表达你对某个问题的理解，UML只是一种比较标准化的手段，如果领域专家和技术团队对UML整体接纳程度都很低，那其实下面的内容是没有什么看的必要的。
通常在做设计过程中，常用的UML图有以下几种类型：
用例图：描述系统的功能需求，从执行者的角度来理解系统，用于描述系统外部执行者与系统提供的用例之间的某种关系。（在大公司内一般是产品经理提供）
部署图：用来描述系统硬件的物理拓扑结构以及在此结构上执行的软件，显示计算机节点的拓扑结构和通信路径，特别对于分布式系统比较合适。部署图中的节点通常代表某种硬件。（最优先要考虑的）
组件图：组件可以看做包与类对应的物理代码模块，逻辑上与包，类对应，实际上是一个文件。组件之间的依赖关系是指结构之间在编译，连接或执行时的依赖关系。
状态图：用来描述一个特定对象的所有可能状态及其引起状态转移的事件。（如订单状态流转）
时序图：时序图用来描述对象之间东岱的交互行为，着重体现对象间消息传递的时间顺序。（描述业务逻辑时重点使用）
架构师应该如何成长？体系化成长。
坚持思考悟道。
能说会道能落地。
善于抓住机遇。
勇于破局。