1. 软件架构认知
1.1 组成派和决策派
组成派
- 组件:代码包,模块,领域,CBM,SOA
- 软件系统架构:就是描述计算组件和组件的交互
- 架构设计:拆解、定义、关联组件,画图和实现
决策派
- 架构的真谛是由架构决策,是智慧和思维
- 软件系统架构:由一个个决策组成的有机整体
IT界的莫扎特
-
桥梁
:从“产品”听众获取灵感 -
指引
:指引“研发”乐队完成演奏 -
分割
:将长篇大作切割成乐章 -
交互
:将乐章和声部交叠协奏 -
决策
:在思考中挣扎,在决策中完美 -
演进
:逐渐优化
面试题
作为架构师,你的日常工作主要有哪些?
工作广度;组成和决策;莫扎特6大作用
- 加分项:方法论完整,新架构框架,新技术框架
作为架构师,有什么推崇的书或者大师?
- 学习能力、知识体系
- 加分项:体系书籍、新技术书籍,大师互动分享
你在架构设计过程中的难点?
- 案例深度;决策派思路,莫扎特6大作用触发
- 加分项:决策依据,理论-实际-理论
1.2 软件架构的意义
1.2.1 架构是项目干系人进行交流的手段
语境不同,立场不同,渠道失真
SWOT 分析
1.2.2 架构有助于循序渐进的原型设计
-
拆迁者模式:一次性全部迁移
绞杀者模式
:一个一个模块进行迁移
- 修缮者模式:
适应度函数
- 原子 vs 整体性适应度函数
- 触发式 vs 持续式适应度函数
- 静态 vs 动态适应度函数
- 自动 vs 手动适应度函数
- 临时 vs 预设适应度函数
1.2.3 SWOT分析
1.2.4 约束条件
-
ADMEMS矩阵
-
RAID矩阵
-
那些质量最核心
- 扩展性、性能、可用性、安全性、耦合性
- 可操作性、可重用性、伸缩性、可维护性、易用性、可移植性
1.2.4 架构和组织结构
- 如何解决环境问题?开发、QA和生产不匹配
- 如何解决耦合问题?凤凰项目和传统系统耦合
- 如何决绝资源公用问题?关键人员疲于在多项目中切换
- 如何满足峰值需求?突发性业务需求、性能测试需求
- 如何解决安全问题?最小代价完成安全合规审计
1.2.5 架构可复用、可传递的模型
方法论复用(ABSD、DSSA、AT、EA、TOGAF)
- 模型复用(UML、SOA、CBM)
- 工件复用(素材、图片、表格、图标、文件)
架构复用
剪裁(三七原则,保留30%还是70%)
- 架构资产更新(内部资产库,外部架构社区)
1.2.6 面试
-
题目:作为架构师,遇到部门冲突如何解决?
题眼:决策派,语境、立场、沟通渠道处理,架构决策加分项:方法论完整(通用语言、RASCI)决策、SWOT分析)
-
作为架构师,平常设计关注那些因素?
质量(扩展性、性能、可用性、安全性、耦合性)
加分项:多角度分析,实际案例侧重点分析 -
如何处理新老架构之间的冲突?
题眼:解决技术债,架构演进策略
加分项:多模式使用(拆迁、修缮、绞杀)、冲突预防 -
作为架构师,挑选一个你的实战项目,描述应用架构如何随着组织架构的变化而演进?
-
挑选一个项目,描述该项目中,你如何挑选、复用和剪裁合适的架构设计框架、设计模式、架构风格、软件包?
1.3 基于软件架构的软件开发ABSD
- ABSD方法论:功能分解、架构风格、软件模板、递归
- 什么是架构的真正驱动:业务、质量、功能需求
- 具体实现:需求、设计、文档化、复审、实现、演化
需求驱动
四大基石
- 功能分解:使用已有的基于模块的内聚和耦合技术
- 架构风格:选择架构风格来实现质量和业务需求
- 软件模板:描述软件元素在共享服务和底层架构的基础上,如何进行交互
- 递归:清晰定义迭代的每一个步骤
自顶向下功能分解
体系结构6大过程
需求过程
面试题
-
对于新业务,如何完成一个完成的架构设计流程?
题眼:架构设计方法论(如ABSD的需求、设计、文档化、复审、实现、演化)
加分项:能将设计原则、架构风格和演化过程描述清楚 -
如何在架构设计中选择合适的软件风格和软件模板?
需求驱动论(功能、质量、限制)
加分项:能结合实际项目,描述如何根据需求选择风格和模板
1.4 基于特定领域的软件架构开发DSSA
- DSSA方法论:特定问题域的应用模型
- 领域具有普遍性、抽象性、重用性
- 分析、设计、实现、迭代
DSSA基本活动
建立过程
#### 三层模型
领域分析方法和人员分工
- 领域专家:产品经理-需求规约、领域字典
- 领域分析人员:系统分析员、产品经理、企业架构师
- 领域设计人员:应用架构师、自身程序员-软件重用和领域设计
- 领域实现人员:老带新模式
面试题
-
描述一下你在大型架构设计中的职责,以及如何和其他部门同事配合?
题眼:人员分工、架构师沟通、架构师职责、组件和决策
加分项:结合特定方法论(如ABSD、DSSA 、AT等) -
描述一下对领域架构的理解?
题眼:领域驱动模型、DSSA领域架构开发方法
加分项:能将业务映射到领域,并复用现有架构元件 -
描述一下你们公司的业务模型?
题眼:领域驱动模型,本公司核心域DSSA软件架构
加分项:能将所在行业的领域DSSA软件架构解释清楚
1.5 架构思维方法论AT
2. 架构师核心能力
2.1 学了这么多技术,为啥还成不了架构师?
-
三观培养
技术 -> 业务 (钱) 业务驱动性公司 -
指标:高并发、高可用、可扩展性、快速变更、安全性、成本控制
-
十项全能
-
打破职位界限:技术人员、产品经理、项目管理(
落地
) -
塑造三维
-
全面发展
- 走到聚光灯下
- 跳出舒适区:积极跑位才有机会
- 主动承担:主动承担一个项目,为结果负责
- 表达想法:没有想法,还是想法太少
- 做让业务部门最惦记的技术人员,才能升任架构师
面试
- 大型应用中架构设计的考量点
高可用、吞吐量、扩展性、快速变更、成本平和和安全性 - 职业生涯规划的问题
初期强调技术路线,远期转管理路线、培养软实力
业务重要性(技术调研,产品能力,大局观、影响力的构建) - 什么特质使你从一个团队脱颖而出?
软硬实力+业务能力
2.2 架构师发展方向
应用领域架构师
代码是第一生产力
理解业务,需求分析与拆解(业务理解层次)
业务架构师
技术方案最佳实践。不要轻视业务,懂业务的架构师才值钱
系统架构师/企业架构师
技术路线和演进
技术生态扩张案例
技术平台输出路线:由内向外
业务平台输出路线:由外向内
:微信-小程序
推进项目落地
协调能力:共同利益,资源
,有打法,厚脸皮
面试
-
个人职业生涯规划
架构师方向是一个不会出错的答案 -
对架构师能力模型的认识?
业务+技术
业务层面(理解业务,需求分析和拆解,业务对接,领域治理)
技术层面(单兵能力(深度和广度)、技术选型、有码在手、组件和模块化结构) -
所在行业的技术发展趋势\业务发展趋势?
开放平台是BAT的战略方向
中台化的看法:肯定公司的业务方向、借鉴行业第一的经验来回答 -
项目快速落地?
优先级+时间表+协调能力
2.3 化技术为生产力
2.3.1 拆解技术难题-三段论
以大化小
职责领域划分
分层构建解决方案
推演工作中的解决方案,总结沉淀方法论
2.3.2 解决问题从转换思维开始
拥抱变化
2.3.3 面试题
-
讲一讲你在项目当中碰到的难题
强技术导向,不要将推进时候的困难 -
你是怎么解决的?
有思考有打法:三段论; 业务背景-技术难点-拆解问题以大化小; 学到了什么
2.4 围绕业务做技术架构
2.4.1 技术助力业务的两个方向
2.4.2 自建系统 vs 外包采购
投入收益曲线
稳定性++ 风险隔离
研发资源平衡
- 同质化 vs 核心业务
掌握核心技术
:直接盈利业务,术业有专攻
以新零售业务为例:
业务特点制定技术发展路线
- 阿里系
- 抖音系
面试题
-
谈一谈职业发展?基础平台类?or 业务类
10年前:到技术强的部门去(情怀)技术日新月异
现在:到业务复杂的部门(现实)真正有价值在业务,顶级绩效都是业务团队
-
聊一聊具体项目
业务为先:先让面试官明白你的业务
技术主线:为什么选用这个技术?和业务的关系
想象空间:未来的改进点,业务量double架构方案
2.5 制定技术发展路线图
2.5.1中长期的技术架构路线图
- 短期:强业务驱动
- 中期:承上启下
- 远期:面向未来
2.5.2 规划面向未来的架构
挑战:用户量级的增长
面向未来:容量规划 底层架构
面试题
3. 架构设计原则和规约
3.1 架构设计原则和规约
3.1.1 基本原则
开放封闭原则
对修改关闭,对扩展开放
简单说:就是不修改原有实现类,而是新写实现类。
缺点:会导致代码臃肿。
单一职责
一个类只做一件事
依赖倒置原则
以抽象为基准比以细节为基准搭建起来的架构要稳定得多,因此大家在拿到需求之后,要面向接口编程,先顶层再细节来设计代码结构。
接口隔离原则
接口隔离原则(Interface Segregation Principle, ISP)是指用多个专门的接口,而不使用单一的总接口,客户端不应该依赖它不需要的接口。
接口隔离原则和单一职责原则区别?
接口隔离:指的接口
单一职责:指的是类和方法
迪米特法则
迪米特原则(Law of Demeter LoD)是指一个对象应该对其他对象保持最少的了解,又叫最少知道原则(Least Knowledge Principle,LKP),尽量降低类与类之间的耦合
里氏替换原则
组合和聚合原则
3.1.2 设计高并发系统
局部并发原则
服务化拆分
3.1.3 高可用系统
- 限流
- 降级
- 弹性计算
- 流量切换
- 回滚
3.1.4 简单轻量的架构
3.1.5 面试
研究各类技术文章,了解高并发业务的解决方案:
红包,春晚红包,全局发号器,秒杀,抢单