从零开始学架构-大纲笔记
2023-08-01 15:26:57 0 举报AI智能生成
登录查看完整内容
极客时间-从零开始学架构大纲笔记
作者其他创作
大纲/内容
软件架构指的是软件系统的顶层结构
架构是什么
性能
可用性
可扩展性
安全性
成本
解决软件系统复杂度带来的问题
架构的目的
单机
集群
高性能
冗余
实现方式
独裁式
协商式
民主式
决策方式
计算高可用
存储高可用
分类
高可用
预测变化
将变化固定在变化层，稳定层保持不变
变化层和稳定层
抽象层是稳定的，更改功能只需增加新的实现
抽象层和实现层
应对变化
创造新技术
引入新技术
如何降低成本
往往只有“创新”才能达到低成本目标
XSS攻击
SQL注入
CSRF共计
系统漏洞
功能安全
DDos攻击
架构安全
安全
防小偷
防强盗
功能多
数据多
规模
复杂度来源
系统无中断地执行其功能的能力，代表系统的可用性程度
量变引发质变
合适优于行业领先
组件越多，故障概率越大
系统越复杂，定位问题越困难
组件越多，改动影响范围越大
简单优于复杂
架构要满足当时的业务需要
架构要不断地在实际应用过程中迭代
演化优于一步到位
买，整体外部采购
初期-个人网站
买，使用Oracle替换MySQL
买，NAS（网络附属存储）替换本地存储
发展中-集群站点
花钱请Sun公司的人，淘宝从PHP切换至Java
重构-Java1.0时代
数据分库
引入Spring
加入CDN
引入JBoss
降本增效-Java2.0时代
自研支撑海量业务
影响整个互联网的技术发展
分布式-Java3.0时代
淘宝
靠买已经不能解决问题了，成本和技术方案约束
单体接入服务器和存储
十万级
集群接入服务器和存储
百万级
业务集群
监控集群
运维控制集群
接入集群
容灾集群
同步集群
千万级
城市A
城市B
城市C
存储架构
调度中心
同步中心
状态服务
同步代理
IM接入层
通信架构
亿级
手机QQ
设计案例
3到5个备选方案为佳
备选方案的差异要明显
不局限于熟悉的技术
关注技术选型，而不是技术细节
备选方案
设计原则
TPS
QPS
是否需要高性能
是否需要高可用
是否需要高可扩展
安全边界
成本边界
如何识别复杂度
基础架构
展示层
业务层
数据层
存储层
分层架构
扩展时不需要修改所有分层
优点
缺点
面向流程拆分
注册
登录
信息管理
微服务
扩展时只需要修改对应服务
服务划分过细，交互关系复杂
服务数量多，团队效率降低
调用链长，性能下降
调用链长，问题定位困难
无自动化系统支持，无法快速交付
无服务治理，服务多了管理混乱
根据开发人数，3个人负责一个微服务
服务粒度
基于业务逻辑拆分
稳定服务
变动服务
基于可扩展拆分
核心服务
普通服务
基于可用性拆分
高性能要求
低性能要求
基于性能划分
拆分方法
服务发现
服务路由
服务容错
必备
接口框架
API网关
开发提效
服务监控
服务跟踪
服务安全
自动化部署
配置中心
运维提效
自动化测试
测试提效
基础设施
最佳实践
面向服务拆分
手机号注册
身份证注册
邮箱注册
常用场景
核心系统
插件模块
基本架构
插件注册表
插件管理
OSGI（Open Services Gateway initiative）
消息模式
依赖注入
插件连接
插件通信
设计关键点
可扩展
易理解
高效率
规则引擎
实现示例
微内核架构
扩展时只需要修改对应功能
面向功能拆分
基本思想：拆
高可扩展性
不同的拆分方式，本质上决定了系统的扩展方式
一主多从
主写从读
主从数据同步
实时性高的操作读主库
二次读取，读从失败后读主
关键业务读主，普通业务读写分离
如何解决复制延迟
代码封装
中间件
分配机制
带来的问题
读写分离
无法联查
不支持事务
成本增长
业务分库
分库
列分布在不同表内，需多次查询
垂直拆分
范围路由
Hash路由
配置路由
路由算法
联查需要多次查询
count相加
维护一个记录数表
count操作
需手动实现order by
水平拆分
分表
数据库
解决关系数据库无法存储数据结构，如Redis
K-V存储
解决关系数据库强 schema 约束的问题，如MongoDB
文档类数据库
解决关系数据库大数据场景下的 I/O 问题，如HBase
列式数据库
如Elasticsearch
解决关系数据库的全文搜索性能问题
全文搜索引擎
NoSQL
不存在的key设置默认值
数据不存在
缓存生成耗时较长
缓存穿透
更新锁，限制特定线程才能更新缓存
后台更新，禁止业务更新缓存
设置不同的过期时间
缓存雪崩
多份缓存副本，减少单台缓存服务器热点
缓存热点
缓存
Process Per Connection
Thread Per Connection
单 Reactor 单进程 / 线程
单 Reactor 多线程
多 Reactor 多进程 / 线程
Reactor
Proactor
单服务器
DNS负载均衡
硬件负载均衡
LVS
Nginx
软件负载均衡
任务分配策略
地理级别负载均衡
集群级别负载均衡
机器级别负载均衡
按照顺序轮流分配
轮询
不同机器权重不同
加权轮询
负载最低的机器
负载最低优先
处理最快的机器
性能最优
源地址Hash
ID Hash
Hash
任务分配算法
采样率 采样周期
连接数请求数CPU负载IO负载
高性能架构
对某个指定的客户端来说，读操作保证能够返回最新的写操作结果
Consistence-一致性
非故障的节点在合理的时间内返回合理的响应
Availability-可用性
当出现网络分区后，系统能够继续“履行职责”
Partition Tolerance-分区容错性
CAP
CAP 关注的粒度是数据，而不是整个系统
CAP 是忽略网络延迟的
正常运行情况下，不存在 CP 和 AP 的选择，可以同时满足 CA
放弃并不等于什么都不做，需要为分区恢复后做准备
CAP细节
给出初始的架构设计图
假设架构中某个部件发生故障
分析此故障对系统功能造成的影响
根据分析结果，判断架构是否需要进行优化
FMEA（Failure mode and effects analysis，故障模式与影响分析）
客户无感知
实现简单，只需做数据复制
资源浪费
故障需要人工干预
主备复制
主机故障时，读操作相关的业务可以继续运行
主从复制架构的从机提供读操作，发挥了硬件的性能
复杂度高，读写分离的话，客户端需要感知主从关系
主从延迟
主从复制
实现简单，不存在切换的概念
应用场景单一，很多数据不能双向复制
主主复制
双机架构
数据集中集群
数据分散集群
数据集群
数据只能写到主机，数据集中存储，适合数据量不大的场景
数据分散集群架构中，适合业务数据量巨大、集群机器数量庞大的场景
考虑数据量
分区规则
实现简单，各分区无耦合
扩展简单
成本高，需要维护单独的备份中心
集中式，独立的备份中心
成本低
实现复杂
扩展复杂
互备式，互相备份
实现简单
成本高，需要维护多个备份中心
独立式，每个分区自有备份中心
复制规则
数据分区
冷备
热备
主备
主从
对称集群
非对称集群
同城双活
针对数据一致性要求不高，数据不怎么改变，或者即使数据丢失影响不大的业务，比如微博
应用场景
保证核心业务的异地多活
尽量减少异地机房距离，搭建高速网络
减少数据同步，只同步核心数据
保证最终一致性，不保证实时一致性
保证核心数据最终一致性
消息队列
二次读取
存储系统同步
回源读取
重新生成数据
采用多种手段同步数据
保证绝大部分用户的异地多活
设计思路
根据访问量
核心业务
创收业务
业务分级
数据量级
是否唯一
实时性
可丢失性
可恢复性
数据分类
消息队列同步
数据同步
多通道同步
同步和访问结合
日志记录
用户补偿
异常处理
访问指异地机房通过系统的接口来进行数据访问
设计步骤
跨城双活
数据同步是异地多活的核心采用多种手段，保证绝大部分用户的核心业务异地多活
不同地区用户提供服务
只读类业务，如Google
跨国双活
架构模式
对于城市范围的故障没办法，但是发生概率太小针对机房火灾、机房停电、机房空调故障等情况，是应对机房级别故障的最优架构
异地多活
代码逻辑
内部原因
大量请求
上下游系统影响
外部原因
原因
系统后门降级
独立降级系统
降级
熔断
基于请求限流
基于资源限流
限流
排队
解决思路
接口级别的故障
高可用架构
在一个分布式系统（指互相连接并共享数据的节点的集合）中，当涉及读写操作时，只能保证三者中的两个，另外一个必须被牺牲
从零开始学架构
收藏
收藏
0 条评论
回复 删除
下一页
