架构师所需知识储备与经验



职位职责

• SaaS应用等后台业务的产品调研、讨论以及整体的架构设计

• 业内难点的技术攻坚、主导核心组件、服务的编码和上线

• 定位系统平静，提高系统性能、稳定性以及业务扩展性

• 主导跨部门协作的复杂功能的调研、设计、协调、实施和落地

职位要求

• 具备海量数据和大规模分布式系统的设计和开发经验

没有实践的机会

• 从设计到实现始终对其业内一流产品水准

什么是一流的业界标准，六七个实践案例

• 具备良好的沟通能力、组织能力以及团队协作精神

为公司整体价值提供增值，找到与其他团队的利益共同点

• 对多种数据库中间件、消息中间件及其他大规模分布式系统的基础架构组件有深入理解

分布式系统的关键技术

• 熟悉公有云、私有云、虚拟化、容器化部署（没框起来，感觉也很重要）

• 擅长领域模型，具备微服务架构

领域模型是设计微服务架构会涉及到的方法

• 对spring、mybatis等常用开源框架应用经验丰富、对框架本身的体系有较为深厚的理解和应用经验

通过框架约束大家的开发过程，很重要，根据团队的具体情况构建一套解决方案

• 优化性能

• 对数据结构和算法有深刻的理解与良好的编码能力

• 计算机基础知识（操作系统、数据结构、网络编程、java虚拟机、文件系统如何管理）



架构师主要职责

• 编写架构设计文档（本周）

• 开发编程框架

• 重构软件代码

• 设计系统架构

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

• 优化系统性能

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

• 保障系统安全与高可用

• 大数据应用

• 技术创新

• 沟通管理

互联网大厂典型面试题

面试题

什么是软件架构

什么是软件架构？如何写一个架构设计文档，文档中应该包含哪些方面的内容

答：TODO

子父类

子类override父类的方法后，想要修改抛出的异常，那么子类方法抛出的异常类应该是父类方法抛出异常类的子类还是父类？

答：应该是子类，重载方法抛出异常应不能大于父类中的异常

spring问题

Spring是如何实现单例的？

和设计模式中的单例实现方式有什么不同？

答：

主流大厂系统架构设计

淘宝这样的大规模分布式互联网应用系统使用了哪些技术方案和手段，主要解决什么问题？

CAP

什么是CAP原理？

请描述某个你熟悉的NoSQL产品是如何解决CAP问题的

性能相关

如何进行性能测试、流程、主要关注指标

java虚拟机垃圾回收

数据库索引

IO流

DDD设计

你怎么理解领域驱动设计DDD

DDD的优缺点是什么



高可用

高可用的方案有哪些

如何保护数据库中存储的用户密码

大数据

spark为什么比MapReduce快

搜索引擎



区块链

什么是边缘计算

区块链如何保障无法被串改

沟通人际

如何认知问题、发现问题、解决问题



架构师主要能力

• 编程能力

• 基础技术掌握能力

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

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

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

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

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

• 快速学习能力

• 沟通与领导能力

什么是软件架构



相关方不同提供文档不同



架构师的价值

对于软件的技术细节不了解的程序员，出问题的时候解决问题，软件做大时负责软件技术点的解决

模糊掉底层细节方便程序开发

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

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



大家关注的问题

• 架构师与全栈工程师的区别

架构师是做架构设计，推动开发团队实现架构落地，全栈工程师是技术掌握全面，所有代码都自己写，架构师不一定写代码，主要是组织别人进行工作

• 架构师如何成长，哪些人适合做架构师

多做实践，解决各种问题，皮厚肉糙，有思路，做事情主动的人

• 技术广度和深度如何平衡和解决

没有深度就没有广度，融会贯通

• 有没有什么好的方式沉淀领域知识，以便构建个人中台

深度

4+1视图模型：

4+1架构视图

单一的视图无法表达完整的系统架构，需要通过不同的维度来表示



• 逻辑视图

设计的对象模型

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

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

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

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

• 过程视图

捕捉设计的并发和同步特征

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

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

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

• 物理视图

描述了软件到硬件的映射，反映了部署特性

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

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

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

部署图

• 开发视图

描述了在开发环境中软件的静态组织结构

相关者：开发相关人员，测试人员

视角：系统如何开发实现

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

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

类图

• 场景视图（+1的那个）

描述用例场景

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

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

用例图

如何用UML进行架构设计与建模

什么是模型

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

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

建造传统模型的目的

• 为了证明某些事情能都工作

• 前提：建造模型的成本远远低于实物的成本

造飞机

造高楼

建造软件模型的目的

• 为了与他人沟通

• 为了保存软件设计的最终成功

• 前提：除非模型比代码更说问题？（模型比代码浪费的资源更多就不做了）



何时画图

• 讨论、交流时

• 最终设计文档

只保留少量的、重要的图

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

何处画图

• 白板

• 绘图工具

• draw.io



UML:软件架构建模的一般方法与工具

UML图分类

静态图

• 用例图

• 对象图

• 类图

• 组件图

• 包图

• 部署图

动态图

• 协作图

• 序列图

• 活动图

• 状态图

通用模型元素

节点：服务器通常是节点



关联关系的具体解释