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

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.pngimage.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.pngimage.png

代码是第一生产力

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

image.png

业务架构师

image.png

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

image.png

系统架构师/企业架构师

image.pngimage.png

技术路线和演进

image.png

技术生态扩张案例

  • 技术平台输出路线:由内向外

image.pngimage.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.pngimage.png

2.4.2 自建系统 vs 外包采购

image.png

投入收益曲线

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

研发资源平衡

image.png

  • 同质化 vs 核心业务
  • 掌握核心技术:直接盈利业务,术业有专攻

以新零售业务为例:

image.pngimage.png

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

  • 阿里系

image.pngimage.png

  • 抖音系

image.png

面试题

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

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

2.5 制定技术发展路线图

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

  1. 短期:强业务驱动

image.png

  1. 中期:承上启下

image.png

  1. 远期:面向未来

image.pngimage.png

2.5.2 规划面向未来的架构

image.png

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

image.pngimage.pngimage.png

面试题

image.pngimage.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.pngimage.pngimage.png

3.1.5 面试

image.pngimage.png

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

3.2 架构设计原则

3.2.1 微服务应用服务拆分

image.pngimage.pngimage.png

3.2.2 不同维度对服务拆分

压力模型

image.png

主链路规划

image.png

领域模型DDD

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

image.pngimage.pngimage.pngimage.pngimage.pngimage.pngimage.png

3.2.4 理解微服务的无状态

image.pngimage.png

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

image.pngimage.png

3.2.5 可用性-流量整形

image.pngimage.png

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

image.png

3.2.7 数据一致性-幂等性

image.pngimage.pngimage.png

面试

image.png

© 版权声明
THE END
喜欢就支持一下吧
点赞0

Warning: mysqli_query(): (HY000/3): Error writing file '/tmp/MYj2Dk3V' (Errcode: 28 - No space left on device) in /www/wwwroot/583.cn/wp-includes/class-wpdb.php on line 2345
admin的头像-五八三
评论 抢沙发
头像
欢迎您留下宝贵的见解!
提交
头像

昵称

图形验证码
取消
昵称代码图片