软件架构设计
2021-09-11 10:34:33 1 举报AI智能生成
软件架构设计
作者其他创作
大纲/内容
软件架构设计
什么是架构
五花八门的架构职业
架构师职业分类
架构的分类
软件架构分层.png
第一层
基础架构
云平台、操作系统、网络、存储...
第二层
中间件与大数据平台
中间件架构
消息中间件、数据库中间件、缓存中间件...
大数据架构
Hadoop、Hive、Spark、Storm、Flink...
第三层
业务系统架构
通用软件系统
办公软件、浏览器、播放器...
离线业务系统
基于大数据的BI分析、数据挖掘、报表与可视化...
在线业务系统
搜索、推荐、即时通信、电商、游戏...
架构的道与术
何为道，何为术
方法论，即是架构的道
技术问题
高并发、高可用和一致性
业务问题
业务的需求分析和建模
具体可操作的即为术
具体的语言、框架或中间件使用技巧
道与术的辩证关系
道
内功心法、知（理论）、问题
术
外部招式、行（实践）、问题
实践-->总结理论-->指导实践-->修正理论...
计算机功底
语言
层出不穷的语言
精通一门语言
操作系统
缓冲I/O和直接I/O
内存映射文件与零拷贝
网络I/O模型
进程、线程和协程
无锁（内存屏障与CAS）
网络
HTTP 1.0
HTTP 1.1
HTTP/2
SSL/TLS
HTTPS
TCP/UDP
QUIC
数据库
范式与反范式
分库分表
B+树
事务与锁
事务实现原理
1.Redo Log
2.Undo Log
Binlog 与主从复制
框架、软件与中间件
对生态体系的认知
框架
软件与中间件
技术架构之路
高并发问题
问题分类
高并发读
高并发写
容量规划
高可用与稳定性
多副本
隔离、限流、熔断和降级
灰度发布与回滚
监控体系与日志报警
事务一致性
分布式事务问题
分布式事务解决方案
2PC
最终一致性（消息中间件）
TCC
事务状态表+调用重试+接收方幂等
对账
妥协方案
弱一致性+基于状态的补偿
重试+回滚+报警+人工修复
总结
多副本一致性
高可用且强一致性到底有多难
Paxos 算法解析
Raft 算法解析
Zab 算法解析
3 种算法对比
CAP 理论
CAP 理论的误解
现实世界不存在“强一致性”（PACELC理论）
典型案例：分布式锁
业务架构之路
业务意识
产品经理 VS 需求分析师
悖论
有限的人力资源和时间资源
无限的业务需求
什么叫业务意识？
与公司相互影响
需求来自何处、往往和公司的基因、盈利模式紧密挂钩
公司本身决定了需求从什么地方来
需求来自何处？
toC 来自用户反馈
toB 来自客户
来自对业务数据的分析挖掘
来自Boss
真需求还是伪需求？
真
客户要解决的“问题”
系统只是解决问题的一种答案
伪
老板的决定、面向KPI的需求
信息传递的递减效益
隐性
产品手段 VS 技术手段
产品经理
产品的手段解决
搜索框的长度延长一半
暗示用户多输入几个字
扣减库存分布式难题，提示用户失败，重试解决
实时报表难度大，改用小时/天级别的报表
技术人员
技术的手段解决
需求的优先级
效益
什么叫作一个“业务”
案例
子主题
定义
“业务”往往与公司的长期战略、盈利模式、发展阶段、组织架构密切相关
没有划分标准
特点
“闭环”
团队闭环
产品闭环
商业闭环
纵向闭环
横向闭环
“业务架构”的双重含义
第一层意思
从商业角度去看
组织架构根据业务的发展来决定
康威定律
一个组织产生的系统设计等同于组织之内、组织之间的沟通结构
第二层意思
从技术的角度去看
业务架构和技术架构会相互作用、相互影响
eg. 广告业务
如果认为CPC、CPM、CPT 是三个业务
三个团队，三套技术架构
如果认为是一个业务
哪些是共用的，哪些是个性化的
“业务架构”与“技术架构”的区分
区分的目的
业务问题，却想用技术手段解决
技术问题，无法实现，反过来将是业务问题
既不是技术也不是业务问题，而是组织架构问题，部门利益问题
软件架构4+1视图
物理架构（物理部署图）
运行架构（多线程、多进程）
数据架构（数据库表的schema）
应用架构（系统的微服务划分）
业务架构思维
“伪”分层
底层调用上层
方法1
业务逻辑拆分，一部分放在基础服务
方法2
DIP（依赖反转），底层定义接口，上层实现
同层之间双向调用
服务间的职责分配是否有问题，出现了服务之间的紧耦合
提供公共服务，其他服务都依赖它
层之间没有隔离，参数层层透传
eg. if businessType==xxx 从场景层透传到底层
聚合层特别多，各种拼装
业务层太薄，纯粹从技术角度拆分了业务
按业务领域划分，服务是一个闭环
边界思维
对象层面（SOLID原则）
接口层面
产品层面
组织架构层面
系统化思维
利益相关者分析
eg.
为什么谈业务架构，要先谈“利用相关者”
利益相关者是从“外部”来看系统
业务具有“闭环”的特点，利益相关者就是一个最好的视角
每个利益相关者代表了一个视角
利益相关者往往也对应了一种业务划分、系统划分
非功能性需求分析
并发性
可用性
一致性
稳定性和可靠性
可维护性
可扩展性
可重用性
视角（架构4+1/5+1 视图）
功能视图
逻辑视图
物理视图
开发视图
运行视图
抽象
什么是抽象？
语言中的抽象
计算机的抽象
怎么做抽象？
分解：找出差异和共性
归纳：造词
抽象带来的问题
抽象造成意义模糊
抽象错误：地基不稳
抽象造成关键特征丢失
抽象过度
建模
本质：重要东西“显性化”
重要的东西：构造块
显性化
形成体系
建模层次
自然语言建模
计算机语言建模
过程建模
对象建模
领域建模
正交分解
分解过程保证
分清
同一层次之间相互独立
分尽
完全穷尽
技术架构与业务架构的融合
分久必合，合久必分
格式各样的方法论
why 领域驱动设计
什么是领域
领域是面对的“业务问题空间”
业务问题--系统如何很好地处理复杂的
业务需求
业务流程
业务规则
什么是领域模型
解决业务问题给出的“答案”
领域模型如何描述
逻辑层面
类图和状态图
关键实体与实体间关系，以及实体状态迁移过程
物理层面
实体对应数据库的schema
why DDD
软件开发阶段.png
前提
业务足够复杂且多变，需要系统灵活支持
要领
业务需求会一直增加，业务流程会改变，业务规则也会改变
“领域模型”不能随便改变
业务流程 != 系统流程
1、面向人员不同
业务流程粗粒度，给产品、运营、用户等
系统流程更细化，给开发、设计
2、数据在多个系统之间copy，维护困难
业务角度：数据在copy
技术角度：传递的是数据ID
3、业务流程开始是瀑布，复杂后会变成网状
系统流程变成网状
领域模型设计难
意识问题
业务人员沟通语言是“流程”-->开发过程“流程驱动”，而不是“领域驱动”
现实世界的复杂性
现实世界模棱两可的东西-->技术人员不懂业务-->无法提炼模型
迭代速度
现实世界一直在改变，模型“腐化”
toC 产品：业务流程不复杂、牵扯系统不多
适合快速迭代
toB 产品：牵扯很多系统之间的对接，一次开发很少改动
不适用
火候的掌握
悟性
什么地方是不变的
作为基础
什么地方是易变的
留出扩展
DDD与微服务的“合”
诸侯制
中央集权制
DDD与读写分离（CQRS）
小范围的技术问题
大范围的业务问题
业务分层架构模式
产品属性
销售属性
运营属性
运输属性
管道—过滤器架构模式
管道-过滤.png
状态机架构模式
状态机.png
系统之间相互独立，专注做自己的事
状态机维护数据状态，数据从哪来，处理了几步，谁继续处理...
状态机与系统，可以RPC、基于消息的Pub-Sub或微服务的Event-Sourcing
业务切面/业务闭环架构模式
从架构到技术管理
个人素质的提升
能力模型
格局
全局的视野、大局的问题
“格局”有层次
国家总理在“国家”层次思考
公司CEO在行业、“公司”层次思考
业务负责人在其负责的“业务”层次思考
扩大思考“范围”，即格局
历史观—技术血脉
历史唯物主义
抽象能力
从“抽象”到“细节”
深入思考的能力
深度思考的习惯-->新技术理解更透彻
落地能力
架构方案必须能够落地
项目管理，对不确定因素进行把控
“人”的因素
沟通不充分、组织混乱、职责不清
影响力塑造
关键时刻能顶上
打工思维 VS 老板思维
空杯心态
持续改进
建言献策
团队能力的提升
不确定性与风险把控
需求的不确定性
相关方达成“共识”
哪些是清晰的，可以做
哪些还需要进一步思考
技术的不确定性
前期多调研，多测试
人员的不确定性
分摊风险
不要把项目最核心的部分让一个人开发维护，导致别人无法插手
组织的不确定性
多部门如何协作
历史遗留问题
对项目进行梳理
以价值为中心的管理
第一层次
第二层次
第三层次
系统为公司带来了什么业务价值
第四层次
战略性投入
团队培养
技术能力
独立意识
能掌控事情，接得住
思维能力
通过一次次的讨论来言传身教
0 条评论
下一页
