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