《架构设计模式》读书笔记
2022-04-23 11:18:47 1 举报AI智能生成
架构设计模式
作者其他创作
大纲/内容
四种架构设计模式
分层架构Layered Arch
九天谓一为中天，二为羡天，三为从天，四为更天，五为晬天，六为廓天，七为减天，八为沈天，九为成天
理论概述
什么是分层架构？
为什么要进行分层？
如何进行分层架构设计？
典型案例场景
分层架构定义
层的定义
层是软件的逻辑单元
每一层都有特定的功能
组件被分配到不同层
何为分层
将系统按照职责拆分和组织
上层依赖于直接下层
下层不可以依赖于上层
越往上不依赖于技术层，越往下依赖于技术
不可以跨层访问
实战中是有争议的
跨层访问违反接口聚合原则
案例：家里装修就是分层
经典分层架构应用
OSI（网络） 7层架构
第七层应用层
Application Layer
HTTP、FTP、DNS、SNMP、Telnet
第六层表示层
Presentation Layer
SSL、TLS
第五层会话层
Session Layer
NetBIOS、PPTP
第四层传输层
Transport Layer
TCP、UDP
第三层网络层
Network Layer
IP、ARP、ICMP、IPSec
第二层数据链路层
Data Link Layer
PPP，ATM，Ethernet
第一层物理层
Physical Layer
Ethernet，USB、Bluetooth、IEEE802.11
CS分层架构
两层架构
Client
运行于Desktop的Native富客户端
server
应用服务、业务逻辑和数据存储
通过网络交换信息
BS分层架构（带来互联网风潮）
两层架构
Browser
运行于各种浏览器的瘦客户端
Server
应用服务、业务逻辑和数据存储
通过网络交换信息
企业应用三层架构
Presentation
与用户交互和呈现信息
Domain
业务逻辑
Data
数据存储
缘何分层：Conway·s Law
康威定律
组织
架构
设计系统的架构受制于产生这些设计的组织的沟通架构
复杂度隔离
隔离业务复杂度和技术复杂度
解决不同层的问题可以采用不同技术栈
每层变化速度不一致
防止错误传播
防止错误传播
降低错误影响
防水仓设计
Spring Cloud Netflix Hystrix
所有的共享通信都是不同线程池
层自治
本层功能内聚
自主决策
只有本层的知识
知道的越少，泄密的可能性越小
受影响的可能性越小
OAurh 2.0就是经典的层自治
分层架构的优点
高内聚
每一层的任何变更更最多影响自身和上一层
专注自身功能，其他层的影响被屏蔽
Single Responsibility每一层都是相对单一单调的
低耦合
每一层只依赖于下一层
单向依赖
通过接口交流部
Interface Segregation
Dependency Inversion
分层架构的优点：低耦合
易扩展
功能扩展，影响仅限于本层
内聚性，易于横向扩展
独立步数宝，易于纵向扩展
每层定义了清洗的边界，扩展发生在不同的边界，符合Open-Close
可维护性好
分工合作，开发者关注点集中
每一层可以依据接口并行开发
每一层功能单一，代码易于理解
可测试性高
每层对外提供固定接口，可以直接测试接口
分层测试
Spring Boot层次接口测试比较好
@DatajpaTest
@WebMvcTest
分层架构的缺点
性能下降
分层必定引入新的通信开销
层信息不能泄露，导致每层都有数据转化发生
不能跨层访问，无法通过减少调用链路
开发成本上升
Full stack少且难以培养
跨组织沟通成本
任何变更可能都需要多层参与
如何设计分层架构
依赖规则
越向外越具体，越朝内越抽象
外圈是软件，内圈事规则
依赖关系只能从外向内
定义职责
高层标识规则，底层实现细节
逻辑内聚自治分组
依据组织职责分工
在组织层次划分上理解
在每个层次划分对应职责
定义技术栈
根据每层的需求个子选定
借鉴成功案例
部署方式
如何设计分层架构
代码抽象与分层
层对外暴露的接口，隐藏实现细节
实现依赖抽象，抽象不可依赖实现细节
代码不能跨层调用，只依赖于直接的下一层
集成
集成前做单元测试
根据接口和技术栈确定集成方式
集成联调
案例分析
MVC
Model
Domain model和业务逻辑
View
展示数据和用户交互
Controller
接收输入并转化为对Model的操作
将Model转化为View能展示的数据
MVP
MVC的派生变种，Model和View是隔离的变化不会相互影响，缺点是View层和Model层耦合度很高
Model
Domain model和业务逻辑
View
通过Presenter获得数据而非Model
Presenter
充当桥梁双向绑定
MVVM
Model层
除了Domain model和业务逻辑，也包含部分Controller功能
ViewModel层
View的模型、映射、显示逻辑和绑定器
View
将ViewModel展示在特定的界面
BFF
Backend for frontend
将后台功能聚合到一起，提供给前段
避免将终端和多个服务的交流
GraphQL
层比较薄，几乎没有业务逻辑；可能一般公司做的时候结合GraphQL；如果不采用不微服务架构没必要使用这个
面试题目
题目1：HTTP和底层TCPIP链接的关系
讲讲层与层之间依赖关系，如何进行链接的HTTP在TCPIP中得到什么东西如何进行操作的？
题目2：什么是MVC架构？采用何种技术实现MVC？
MVC看重的是基本功力
ssh可以说说思想是相通的
可以阅读源码或者相关书籍
题目3：Spring Cloud Hystrix 断路器的工作原理
Hystrix的出现原因：业务场景中有N多个服务串起来的，任何服务都被Domain支配的，很难找到错误原因。
当你调用别人也可能被调用会产生雪崩效应
当你调用别人也可能被调用会产生雪崩效应
就相当于家里的短路，断路器
防止雪崩效应，资源隔离也就是防水层设计
Hystrix的线程模型，错误隔离，线程分开
通过窗口实现的，判断窗口期内错误次数？切面检查熔断器状态，查看线程池状态（超时、Error会出现降级服务）；
题目4：如何完成legacy（雷达）的系统重构
体现你的思想和方法论
技术分层思想
分层架构回答
理清系统功能，以及依赖关系
大概知道提供啥服务，提供什么功能
功能之间的依赖，内部的和外部的
按照不同功能和特征划分产品
系统的重要核心和非核心
找打可以舍弃的功能
利用新的分层定义接口规范、重写部分规范
上下的兼容性
利用新的技术架构如何保证？
保证重要东西不缺失
还有测试方法论
单元测试
功能验收
项目集成
上线功能
优化新系统
事件驱动架构模式（EventdrivenArch）
身无彩凤双飞翼，心有灵犀一点通
EDA事件驱动架构
什么是EDA
EDA解决了什么问题
EDA的优缺点
一些典型的应用场景
何为EDA
EDA类别
Notification（通知）
源系统发送消息通知其他系统状态改变
接收方响应非必须
发送Event逻辑和处理Event逻辑无依赖，独立变化
解耦，各自扩展
Carried State Transfer（通知状态转移）
远系统推送信息及变化
依赖着会生成信息副本
容错（Fault Tolerance）
源系统不可用时，依赖着可以使用副本
依赖着维护信息副本和变化
数据的冗余
数据一致性
提高整体性能
依赖者直接使用信息副本
事件驱动架构模式是一种异步分发事件的架构模式
用于高扩展且低耦合的系统
事件为核心，一系列解耦的、单一功能的事件处理器
经典案例
经典应用NIO
针对不同的IO event分配不同的Handler
Selector：监控哪些Channel有IO event
SelectionKey：维护IO event的状和绑定的Handler
经典应用NGINX
Nginx的工作进程一直监听端口并等待Event
Event是由新建立的连接所触发的
所有的连接都会被分配到一个对应状态的状态机
Non-blocking
EDA的两种Topology
Mediactor
中介
流程
Mediator中介模式
简介
存在业务流程
多步骤
统一协调，居中调度
事件分层次
Event Queue
源系统将Event发送到Queue
Event处理系统从Queue中消费Event
源系统和事件处理系统的连接点
Queue只关心事件的传输
Event Mediator
中介从Queue中消费原始事件，并分配、协调各个执行步骤
对应业务处理的每个步骤，产生待处理事件（业务事件）
将待处理事件异步分发到不同的通道（Channel）
无具体业务逻辑，只知道有哪些步骤
Event Channel
Mediator向Channel发送消息，Processor从Channel读取
某种业务事件（消息）的聚合
多个Processor可以监听同一个Channel
Evenet Processor
监听Channel的Event
具体的、单一功能的业务逻辑单元
一个Processor尽量只做一件事
处理器之间无关联性
所有处理器合作形成完整业务流程
经典案例
系统密码修改场景
修改密码
密码变更Event
风险检查
修改次数检查
记录请求日志
发送邮件
Email Send
Email Processor
History Record
History Processor
Quota Check
Quota Processor
Risk Check
Risk Processor
Broker
无中心
无流程
Broker代理模式
简介
无中心控制器
轻量的消息代理将消息串联成链状
分发至事件处理器组件
事件处理器独立运作
Broker
轻量级的代理
无业务逻辑的简单消息分发
源系统将Evenet发送至代理（通道）提供Processor消费
事件通道可以是Queue、Topic或者两者组合
案例说明：学校通知学生事情，学生可以自己去选择看不看，信息透明化，学校只负责通知看不看在于你
Event Processor
监听Channel的Event，判断是否处理
处理一个事件，并发送一个事件，标明其行为
事件处理器，单一业务逻辑
处理器之间无关联性，不构成业务逻辑链
经典案例
订单状态日志记录
订单状态变化作为一个事件，每次状态变化都是一个事件
使用代理模式更符合，主流程为主，支线流程不用管
EDA模式优点
整体灵活性
架构能否在不断的改变的使用场景下快速响应
事件处理器组件目的单一、高度解耦，可以独立变化
代理拓扑结构比中介拓扑结构调度会更容易
事件中介与事件处理器是耦合的
代理模式完全解耦
可扩展性Scalability
高度解耦，独立变化
横向扩展
不同组件的运行节点数均可自行调整
组件本身可以进行自行决定是否再拆分实现
纵向扩展
计算密集型还是内存密集型，按需调整
性能
细粒度的事件处理器有利于提高性能
整体架构是异步并行有利于提高性能
易于部署
高度解耦的事件处理器组件荣整体部署相对容易
EDA模式缺点
可测试性
单元测试无差异
集成测试难
组件众多
异步
可维护性
分布式部署
异步
异常处理难
代码可读性比较复杂
性能
性能
分布式消息（事件）传递会降低性能
经典案例
短信验证码
用户
网站验证功能
发送验证码
编辑消息
发送消息
验证码网关接收验证码
验证服务
Processor1->Processor2->Processor3
电商订单声明周期管理
Purchased
订单状态变化事件监听器
Purchased Mediator
Processor1->Processor2->Processor3
Approved
订单状态变化事件监听器
Approved Mediator
Processor1->Processor2->Processor3
Confirmed
订单状态变化事件监听器
Confirmed Mediator
Processor1->Processor2->Processor3
Delivered
订单状态变化事件监听器
Delivered Mediator
Processor1->Processor2->Processor3
Closed
订单状态变化事件监听器
Closed Mediator
Processor1->Processor2->Processor3
数据同步消息广播
用户
发送数据
数据同步
Data Sync Event Bus（使用Broker方法触发）
Processor1
->Processor2-
Processor2
Processor3
题目1：Servlet规范中Listener的工作原理
简单了解Listener底层原理
事件驱动架构讲解体系
题目2：电商系统下单成功，如果有风控问题，需要客服介入，如何设计？
你是不是在讲解中体现你的优势
把所有问题转化成事件，广播出去。
尽可能多的通知到更多人，客服介入的话就是一个简单问题，每个都经过客服比较麻烦
发现将来可能会发生的变化，只要各个模块需要可以自己去监控事件，不要让客服成为唯一通知方式。
题目3：淘汰老系统，如何实现双写？
新系统发生字段变更，发送Event给老系统让其变化
把任何一次数据库改写，都做成一个广播，让依赖系统监控服务
可能存在问题
事件修改的源头消息发送的出去吗？
发过去之后是否发送成功？
接收方是否能够Listener接收，处理出错或者挂掉等
在架构方面实现双写
在实现方面如何保证双写
使用锁实现
微内核架构模式（Microkernel）
海纳百川，有容乃大
本章概述
什么是内核架构
微内核架构的作用
如何应用微内核架构
典型应用场景
Iron Man（钢铁侠）
弧形反应堆
盔甲
KeyBoard Man（键盘侠）
按键触发功能键
外观多样
Transformers（变形金刚）
机器人反应能量-火种
各种汽车
定义原理
微内核
核心功能
资源封装
插件
可插拔
可扩展性
系统核心
资源封装
硬件接口
系统资源访问接口
环境/上下文（context）访问接口
系统事件接口
插件规范
使用场景
规则或者规范
条件
核心功能
支持系统运作的最小功能集
职责分离
通用流程有核心系统定义
核心定义规范，插件具体实现
插件模块
核心系统能力扩展
遵循核心系统规范
实现其逻辑外延和业务逻辑
单一返回能力（Single Responsibility）
专注于其独立能力
只能通过核心提供接口操作系统资源
插件之间无依赖
尽可能避免依赖其它插件
只依赖于核心
隔离
插件不能影响核心
注册
插件可用性
获得插件的方式
插件信息抽象规范
命名、数据规范、访问协议
连接
自定义连接方式
OSGI，点对点绑定（依赖注入）
Web service，message，etc
通信规范
标准规范配合版本策略
自定义规范配合Adapter
事件
全局事件
可以点对点，不能发布订阅
系统事件
不能点对点，可以发布订阅
插件事件
不能点对点，可以发布订阅
微内核架构的优点
符合开闭原则
核心系统封闭
插件提供开放性
整体系统可持续升级
良好的隔离性
核心系统可以关闭插件
错误的传播范围有限
插件内的错误不会被传播到核心系统
各自独立升级改进
可能有兼容性问题
灵活性
核心系统保持稳定，将变化尽量隔离在插件层
插件根据核心提供的接口和规范来提供丰富的外延功能
整体保持开放，持续进化
可测试性
核心系统和插件系统可以分开测试
插件可以运行在模拟环境
性能
通过简化核心系统，提高其性能
插件按需加钱，降低资源消耗
可以动态关闭插件以保护核心系统
易于部署
插件可在运行时动态添加到核心系统
减少核心系统停机时间
微内核架构的缺点
开发难度高
需要分离核心功能与插件功能
插件需要可以热插拔
需要专门注册协议和通信协议
可扩展性不高
主要用于开发产品，不考虑扩展性
不以可扩展性见长
可以结合其他模式获得扩展性
如何使用微内核架构
注册规范
名称-插件名称
功能-该插件提供的功能
位置-从何处装载该插件
依赖-插件所需依赖申明
权限-插件所需权限申明
定义通信机制
同步/异步
本地/远程
数据格式
实现插件
语言
受限于核心系统，确定插件的开发语言
功能
依据核心系统定义规范实现功能
注册
按照核心系统定义的开发规范和注册规范提供注册信息
集成
确定加载方式
遵循通信规范
装载插件
基于注册表获取插件信息
装载机制
启动器/运行期
内存/远程
装载条件
触发条件
Spring boot思想使用比较多
经典案例
ESB
通过将不同的应用接入ESB以扩展功能
ESB是核心系统
应用是插件
应用间无直接依赖，都与ESB沟通
BPM
通过BPM组合不同子流程形成新的流程扩展系统功能
BPM是核心系统
子流程是插件
子流程之间无直接依赖
NGINX Plus
NGINX通过Module为NGINX添加新的功能
NGINX是核心，Module是plugin
开源NGINX在编译期指定要添加的模块
Nginx Plus可以动态添加或移除Module
Servlet
Servlet实现核心功能
插件
Filter：针对request和response的操作
Listener：Servlet生命周期事件并执行相应的命令
Spring MVC、Struts众多功能都是基于Listener和Filter实现的
生产者消费者模式
生财有大道，生之者众，食之者寡，为之者疾，用之者舒，则财恒足矣
本章概述
核心问题
什么是生产者消费者模式
如何设计生产者消费者系统
一些典型的应用场景
即时战略游戏的迷思
世纪难题：水池放水问题
架构演进史
日志打印演进，由单机部署，到多态部署，再到分布式部署，最后使用消息队列（容器）方式记录消息服务
生产者消费者模式理论
Producer拿到消息PUT消息到Container，Consumer在Container里面消费消息
同步调用变成了异步调用
生产数据和消费数据分离
协调不同处理速度
生产者
系统运转的动力
为下一环节产生待处理的工作/数据
与消费者关系
重点在于如何将数据发送到容器
对消费者无依赖
不关注消费者的How和When
发送顺序
消费者
从容器中获取数据，并按照自身业务逻辑处理
依赖于容器，不直接依赖于生产者
向容器确认数据已经被消费
处理后的数据
从容器中删除（queue）
这个删除知识改变读取状态并不是真正的删除
保留在容器中（Topic）
容器
消费者与生产者的交汇点
保管数据的责任
容量
保存时间
读写效率
生产者和消费者的差速器
数据分配策略
核心问题
平衡
数据不堆积
数据堆积太多容易崩掉
消费者无资源浪费
消费者不要太多
调度算法
与EDA异同
EDA
核心讲的是时间触发流程
重点在事件本身
不解决事件/消息如何传递的问题
Producer-Consumer
强调的是从生产端到消费端到全流程
从抽象程度来看EDA更抽象
消费策略
决定消费者如何消费数据
消费方式
Push
Poll
分发方式
Topic
Queue
事务性
优点
低耦合
Producer。Consumer和Container都可独立变化
Producer和Consumer互无依赖
无事务系统对三者都无约束
异步运作
分布式部署
Producer，Consumer和Container均可分开部署
Producer，Consumer和Container自称分布式系统
各自按需扩展
平衡系统差速
通过Container来平衡生产速度和消费速度
动态节点Producer和Consumer数量
减少资源浪费
避免产生过多数据
避免数据堆积在容器
削峰填谷
肖峰
生产数据超过消费数据
缓存数据
填谷
生产数据的速度下降
消费端速度不变
单点流量增加不影响系统稳定性
整体系统运行于匀速状态
设计数据单元
定义
生产者放入/发送到容器的单体
容器内存储的单体
消费者消费单体
从业务逻辑推导
数据单元具备业务含义
数据单元和颗粒度适中
完整性保证
传输过程中数据单元不可缺失
无依赖
数据单元是独立的
两个数据单元之间互无影响
设计Producer
生产/发送
对发送成功的确认
始乱终弃（Fire and Forget）
望穿秋水（Synchronous send）
云中谁寄锦书来（Asynchronous send）
数据单元独立性
时间
空间
异常处理
超时
错误
重试
设计Consumer消费方式
推（Push）
由Container发起，将数据单元推送给Consumer
Consumer可以尽快获得数据
拉（Pull）
由Consumer发起
Long polling
获取数据有滞后
分发模式
Queue
Point to Point
1->1
不可重复消费
Pub/Sub
Topic
1-N
重复消费
反序列化
将网络数据流还原为数据单元
JSON
Avro
Thrift
Protobuf
消息确认
Commit log
记录读到哪里了？下一次直接根据日志继续
Ack
记录指针的方式，指针指向哪里，处理完，就指向下一个
消费策略
批量/单体
同步/异步
幂等
集群
Replica
Nodes Master-slave
Partitions
Non-replica
只存meta data
读取转移
消息/数据存储
数据单元的存储结构
时效性
调度算法
分配数据单元到Consumer
消费保证
At least once
Producer保证Consumer至少收到一次数据单元
从业务分析Container中可能有重复数据单元
Consumer实现要防重或幂等
At most once
Producer保证Consumer最多收到一次数据单元
从业务分析Container中可能会丢失部分数据单元
Consumer可能无法读取到所需数据单元
引入第三方数据对比验证程序
Exactly once
Producer保证Consumer收到并仅收到一次数据单元
从业务分析Container中有且仅有一份数据单元
Consumer无需防重
注意：现实中很少能够实现Exactly once，大多数是实现At least once（消息推送）、At most once（银行转账）
经典案例
BlockingQueue
早餐炸油条，消费者等待，锅内现炸油条；生产者等待，当没有人买的时候就不会炸油条了；
Thread1往队列里面PUT消息，Thread2在队列中Take消息，Thread1和Thread2都有可能会等待行为就是BlockingQueue
ActiveMQ
Connector
支持OpenWire/Stomp/MQTT/AMQP协议
支持TCP/UDP/SSL/HTTP/WebSocket连接方式
Regin
Topic Regin
Queue Regin
Message Store
JDBC
Journal
Cache
WM
Network Services
Store&Forward
Discovery
Kafka
Kafka与MQ很相似，Kafka不支持Queue只支持Topic
Kafka设计就是一个分布式设计，必须跟Zookeeper配合使用
Kafka（消息/日志）存在Topic会分成不同的Partition，会分布在某个Broker里面，所有的Broker、Partition都存在Zookeeper，扩容的时候，需要扩展Broker、Partition
topic的Partition里面的消息会根据大小设置不同的分片，查找使用的时候通过Index查找
每个Topic会被分成多个Partition，每个Partition会分配到不同的Consumer里面，其中Partition要跟Consumer一一相等，能保证数据读取正常
Partition的offset都是一对一的，能保证数据消费完整每个Topic都维护自己的Partition的读取Offset
ERP审批流程
申请
提交任务
任务API
PUT任务到Pending tasks queue
Take任务
审批任务
Spring events
Defining Custom Event
Event Listener Bean
Event Publisher Bean
题目1：什么是BlockingQueue，如何利用BlockingQueue实现Producer-Consumer模式
题目2：描述Kafka的集群架构如何实现的？
不是很详细的话可以说说，Broker如何分配Topic，如何分配Partition，Consumer如何对应？消息复制原理？消息如何存储？Zookeeper里面存了什么？如何进行选举的？都要了解一下，再找相关的书籍看看
0 条评论
下一页
