架构师1-架构认知、核心能力和基本原则

hsfxuebao
2,171 阅读10分钟

1. 软件架构认知

1.1 组成派和决策派

组成派

  • 组件：代码包，模块，领域，CBM，SOA
  • 软件系统架构：就是描述计算组件和组件的交互
  • 架构设计：拆解、定义、关联组件，画图和实现

决策派

  • 架构的真谛是由架构决策，是智慧和思维
  • 软件系统架构：由一个个决策组成的有机整体

IT界的莫扎特

  • 桥梁:从“产品”听众获取灵感

  • 指引:指引“研发”乐队完成演奏

  • 分割:将长篇大作切割成乐章

  • 交互:将乐章和声部交叠协奏

  • 决策：在思考中挣扎，在决策中完美

  • 演进:逐渐优化

面试题

作为架构师，你的日常工作主要有哪些？

  • 工作广度；组成和决策；莫扎特6大作用
  • 加分项：方法论完整，新架构框架，新技术框架

作为架构师，有什么推崇的书或者大师？

  • 学习能力、知识体系
  • 加分项：体系书籍、新技术书籍，大师互动分享

你在架构设计过程中的难点？

  • 案例深度；决策派思路，莫扎特6大作用触发
  • 加分项：决策依据，理论-实际-理论

1.2 软件架构的意义

1.2.1 架构是项目干系人进行交流的手段

语境不同，立场不同，渠道失真

SWOT 分析

image.png

1.2.2 架构有助于循序渐进的原型设计

  • 拆迁者模式：一次性全部迁移

    image.png
  • 绞杀者模式：一个一个模块进行迁移
image.png
  • 修缮者模式：
image.png

适应度函数

  • 原子 vs 整体性适应度函数
  • 触发式 vs 持续式适应度函数
  • 静态 vs 动态适应度函数
  • 自动 vs 手动适应度函数
  • 临时 vs 预设适应度函数

1.2.3 SWOT分析

image.png image.png

1.2.4 约束条件

  • ADMEMS矩阵

    image.png

  • RAID矩阵

    image.png

  • 那些质量最核心

    • 扩展性、性能、可用性、安全性、耦合性
    • 可操作性、可重用性、伸缩性、可维护性、易用性、可移植性

1.2.4 架构和组织结构

  • 如何解决环境问题？开发、QA和生产不匹配
  • 如何解决耦合问题？凤凰项目和传统系统耦合
  • 如何决绝资源公用问题？关键人员疲于在多项目中切换
  • 如何满足峰值需求？突发性业务需求、性能测试需求
  • 如何解决安全问题？最小代价完成安全合规审计

1.2.5 架构可复用、可传递的模型

  • 方法论复用(ABSD、DSSA、AT、EA、TOGAF)
  • 模型复用(UML、SOA、CBM)
  • 工件复用(素材、图片、表格、图标、文件)

架构复用

  • 剪裁（三七原则，保留30%还是70%）
  • 架构资产更新(内部资产库，外部架构社区)

1.2.6 面试

  1. 题目：作为架构师，遇到部门冲突如何解决？ 题眼：决策派，语境、立场、沟通渠道处理，架构决策

    加分项：方法论完整（通用语言、RASCI)决策、SWOT分析)

  2. 作为架构师，平常设计关注那些因素？ 质量(扩展性、性能、可用性、安全性、耦合性) 加分项：多角度分析，实际案例侧重点分析

  3. 如何处理新老架构之间的冲突？ 题眼：解决技术债，架构演进策略 加分项：多模式使用（拆迁、修缮、绞杀）、冲突预防

  4. 作为架构师，挑选一个你的实战项目，描述应用架构如何随着组织架构的变化而演进？

  5. 挑选一个项目，描述该项目中，你如何挑选、复用和剪裁合适的架构设计框架、设计模式、架构风格、软件包？

1.3 基于软件架构的软件开发ABSD

  • ABSD方法论：功能分解、架构风格、软件模板、递归
  • 什么是架构的真正驱动:业务、质量、功能需求
  • 具体实现：需求、设计、文档化、复审、实现、演化

需求驱动

image.png

四大基石

  • 功能分解：使用已有的基于模块的内聚和耦合技术
  • 架构风格：选择架构风格来实现质量和业务需求
  • 软件模板：描述软件元素在共享服务和底层架构的基础上，如何进行交互
  • 递归：清晰定义迭代的每一个步骤

自顶向下功能分解

image.png

体系结构6大过程

image.png

需求过程

image.png

面试题

  1. 对于新业务，如何完成一个完成的架构设计流程? 题眼：架构设计方法论(如ABSD的需求、设计、文档化、复审、实现、演化) 加分项：能将设计原则、架构风格和演化过程描述清楚

  2. 如何在架构设计中选择合适的软件风格和软件模板？ 需求驱动论（功能、质量、限制） 加分项：能结合实际项目，描述如何根据需求选择风格和模板

1.4 基于特定领域的软件架构开发DSSA

  • DSSA方法论：特定问题域的应用模型
  • 领域具有普遍性、抽象性、重用性
  • 分析、设计、实现、迭代
image.png

DSSA基本活动

image.png

建立过程

image.png #### 三层模型 image.png

领域分析方法和人员分工

image.png
  • 领域专家：产品经理-需求规约、领域字典
  • 领域分析人员：系统分析员、产品经理、企业架构师
  • 领域设计人员：应用架构师、自身程序员-软件重用和领域设计
  • 领域实现人员：老带新模式

面试题

  1. 描述一下你在大型架构设计中的职责，以及如何和其他部门同事配合？ 题眼：人员分工、架构师沟通、架构师职责、组件和决策 加分项：结合特定方法论（如ABSD、DSSA 、AT等）

  2. 描述一下对领域架构的理解？ 题眼：领域驱动模型、DSSA领域架构开发方法 加分项：能将业务映射到领域，并复用现有架构元件

  3. 描述一下你们公司的业务模型？ 题眼：领域驱动模型，本公司核心域DSSA软件架构 加分项：能将所在行业的领域DSSA软件架构解释清楚

1.5 架构思维方法论AT

2. 架构师核心能力

2.1 学了这么多技术，为啥还成不了架构师？

  1. 三观培养 技术 -> 业务 （钱） 业务驱动性公司

    image.png

  2. 指标：高并发、高可用、可扩展性、快速变更、安全性、成本控制

  3. 十项全能 image.png

  4. 打破职位界限：技术人员、产品经理、项目管理（落地）

  5. 塑造三维

    image.png

  6. 全面发展

image.png
  1. 走到聚光灯下
    • 跳出舒适区：积极跑位才有机会
    • 主动承担：主动承担一个项目，为结果负责
    • 表达想法：没有想法，还是想法太少
  2. 做让业务部门最惦记的技术人员，才能升任架构师

面试

  1. 大型应用中架构设计的考量点 高可用、吞吐量、扩展性、快速变更、成本平和和安全性
  2. 职业生涯规划的问题 初期强调技术路线，远期转管理路线、培养软实力 业务重要性（技术调研，产品能力，大局观、影响力的构建）
  3. 什么特质使你从一个团队脱颖而出？ 软硬实力+业务能力

2.2 架构师发展方向

应用领域架构师

image.png image.png

代码是第一生产力

理解业务，需求分析与拆解(业务理解层次)

image.png

业务架构师

image.png

技术方案最佳实践。不要轻视业务，懂业务的架构师才值钱
image.png

image.png

系统架构师/企业架构师

image.png image.png

技术路线和演进

image.png

技术生态扩张案例

  • 技术平台输出路线：由内向外
image.png image.png
  • 业务平台输出路线：由外向内 :微信-小程序

推进项目落地

image.png

协调能力：共同利益，资源,有打法，厚脸皮

面试

  1. 个人职业生涯规划 架构师方向是一个不会出错的答案

  2. 对架构师能力模型的认识？ 业务+技术 业务层面(理解业务，需求分析和拆解，业务对接，领域治理) 技术层面（单兵能力(深度和广度)、技术选型、有码在手、组件和模块化结构）

  3. 所在行业的技术发展趋势\业务发展趋势？ 开放平台是BAT的战略方向 中台化的看法：肯定公司的业务方向、借鉴行业第一的经验来回答

  4. 项目快速落地？ 优先级+时间表+协调能力

2.3 化技术为生产力

image.png

2.3.1 拆解技术难题-三段论

以大化小

image.png

职责领域划分

image.png

分层构建解决方案

image.png

推演工作中的解决方案，总结沉淀方法论

2.3.2 解决问题从转换思维开始

拥抱变化

image.png

2.3.3 面试题

  1. 讲一讲你在项目当中碰到的难题 强技术导向，不要将推进时候的困难

  2. 你是怎么解决的？ 有思考有打法：三段论； 业务背景-技术难点-拆解问题以大化小； 学到了什么

2.4 围绕业务做技术架构

2.4.1 技术助力业务的两个方向

image.png image.png

2.4.2 自建系统 vs 外包采购

image.png

投入收益曲线

image.png 稳定性++ 风险隔离

研发资源平衡

image.png
  • 同质化 vs 核心业务
  • 掌握核心技术：直接盈利业务，术业有专攻

以新零售业务为例:

image.png image.png

业务特点制定技术发展路线

  • 阿里系
image.png image.png
  • 抖音系
image.png

面试题

  1. 谈一谈职业发展？基础平台类？or 业务类 10年前：到技术强的部门去（情怀） 技术日新月异 现在：到业务复杂的部门（现实） 真正有价值在业务，顶级绩效都是业务团队

  2. 聊一聊具体项目 业务为先：先让面试官明白你的业务 技术主线：为什么选用这个技术？和业务的关系 想象空间：未来的改进点，业务量double架构方案

2.5 制定技术发展路线图

2.5.1中长期的技术架构路线图

  1. 短期：强业务驱动
image.png
  1. 中期：承上启下
image.png
  1. 远期：面向未来
image.png image.png

2.5.2 规划面向未来的架构

image.png

挑战：用户量级的增长
面向未来：容量规划 底层架构

image.png image.png image.png

面试题

image.png image.png

3. 架构设计原则和规约

3.1 架构设计原则和规约

3.1.1 基本原则

开放封闭原则

image.png

对修改关闭，对扩展开放

简单说：就是不修改原有实现类，而是新写实现类。

缺点：会导致代码臃肿。

单一职责

一个类只做一件事

依赖倒置原则

以抽象为基准比以细节为基准搭建起来的架构要稳定得多，因此大家在拿到需求之后，要面向接口编程，先顶层再细节来设计代码结构。

接口隔离原则

接口隔离原则（Interface Segregation Principle, ISP）是指用多个专门的接口，而不使用单一的总接口，客户端不应该依赖它不需要的接口。

接口隔离原则和单一职责原则区别？

接口隔离：指的接口

单一职责：指的是类和方法

迪米特法则

迪米特原则（Law of Demeter LoD）是指一个对象应该对其他对象保持最少的了解，又叫最少知道原则（Least Knowledge Principle,LKP），尽量降低类与类之间的耦合

里氏替换原则

组合和聚合原则

image.png

3.1.2 设计高并发系统

局部并发原则

image.png

服务化拆分

image.png

3.1.3 高可用系统

  • 限流
  • 降级
  • 弹性计算
  • 流量切换
  • 回滚

3.1.4 简单轻量的架构

image.png image.png image.png

3.1.5 面试

image.png image.png

研究各类技术文章，了解高并发业务的解决方案： 红包，春晚红包，全局发号器，秒杀，抢单

3.2 架构设计原则

3.2.1 微服务应用服务拆分

image.png image.png image.png

3.2.2 不同维度对服务拆分

压力模型

image.png

主链路规划

image.png

领域模型DDD

3.2.3 新零售业务的微服务拆分

image.png image.png image.png image.png image.png image.png image.png

3.2.4 理解微服务的无状态

image.png image.png

3.2.5 接口版本控制实现向后兼容

image.png image.png

3.2.5 可用性-流量整形

image.png image.png

3.2.6 网关层限流和分布式限流

image.png

3.2.7 数据一致性-幂等性

image.png image.png image.png

面试

image.png
avatar
文章
阅读
粉丝