4.0 架构设计-面试-笔记
2022-05-25 13:31:23 1 举报AI智能生成
几本架构设计相关书籍在一起做的笔记。
作者其他创作
大纲/内容
架构设计
高性能数据库集群
读写分离
主从集群
数据库服务器搭建主从集群，一主一从、一主多从都可以。
数据库主机负责读写操作，从机只负责读操作。
数据库主机通过复制将数据同步到从机，每台数据库服务器都存储了所有的业务数据。
业务服务器将写操作发给数据库主机，将读操作发给数据库从机。
复制延迟
1. 写操作后的读操作指定发给数据库主服务器
2. 读从机失败后再读一次主机
3. 关键业务读写操作全部指向主机，非关键业务采用读写分离
分配机制
1. 程序代码封装
2. 中间件封装
分库分表
业务分库
1.join 操作问题
2. 事务问题
3. 成本问题
分表
垂直分表
对应到表的切分就是表记录数相同但包含不同的列。
垂直分表适合将表中某些不常用且占了大量空间的列拆分出去。
水平分表
对应到表的切分就是表的列相同但包含不同的行数据。
路由
范围路由
Hash 路由
配置路由
复杂度
join 操作
count() 操作
count() 相加
增加记录数表
order by 操作
综合解决方案
1.做硬件优化，例如从机械硬盘改成使用固态硬盘，当然固态硬盘不适合服务器使用，只是举个例子
2.先做数据库的调优操作，例如增加索引;
慢sql优化
根据业务特点，对表设计进行优化
多用短查询
3.引入缓存技术、全文检索等，例如Redis，减少数据库压力
4.程序与数据库表优化，重构，例如根据业务逻辑对程序逻辑做优化，减少不必要的查询;
5.在这些操作都不能大幅度优化性能的情况下，不能满足将来的发展，再考虑分库分表。应该优先垂直分表
高性能NoSQL
关系型数据库缺点
关系数据库存储的是行记录，无法存储数据结构
关系数据库的 schema 扩展很不方便
关系数据库在大数据场景下 I/O 较高
关系数据库的全文搜索功能比较弱
常见的 NoSQL 方案
K-V 存储：解决关系数据库无法存储数据结构的问题，以 Redis 为代表。
文档数据库：解决关系数据库强 schema 约束的问题，以 MongoDB 为代表。
优点
1. 新增字段简单
2. 历史数据不会出错
3. 可以很容易存储复杂数据
缺点/复杂度
最主要的代价就是不支持事务
无法实现关系数据库的 join 操作
列式数据库：解决关系数据库大数据场景下的 I/O 问题，以 HBase 为代表。
全文搜索引擎：解决关系数据库的全文搜索性能问题，以 Elasticsearch 为代表。
高性能缓存架构
适用场景
需要经过复杂运算后得出的数据，存储系统无能为力
读多写少的数据，存储系统有心无力
复杂性
缓存穿透
缓存穿透是指缓存没有发挥作用，业务系统虽然去缓存查询数据，但缓存中没有数据，业务系统需要再次去存储系统查询数据。
1. 存储数据不存在
2. 缓存数据生成耗费大量时间或者资源
缓存雪崩
缓存雪崩是指当缓存失效（过期）后引起系统性能急剧下降的情况。
解决方案1. 更新锁
解决方案2. 后台更新
后台线程除了定时更新缓存，还要频繁地去读取缓存（例如，1 秒或者 100 毫秒读取一次），如果发现缓存被“踢了”就立刻更新缓存
业务线程发现缓存失效后，通过消息队列发送一条消息通知后台线程更新缓存。
缓存预热
缓存热点
单服务器高性能模式：PPC与TPC
高性能负载均衡
分类及架构
DNS 负载均衡
硬件负载均衡
软件负载均衡
负载均衡典型架构
算法
任务平分类
负载均衡类
性能最优类
Hash 类
接口异常
降级
熔断
限流
排队
架构可扩展模式
拆分方式
面向流程拆分：分层架构
面向服务拆分：SOA、微服务。
面向功能拆分：微内核架构。
概念
架构是顶层设计
框架是面向编程或配置的半成品
组件是从技术维度上的复用
模块是从业务维度上职责的划分
系统是相互协同可运行的实体
架构设计的目的
1 架构是为了应对软件系统复杂度而提出的一个解决方案。
2 架构即(重要)决策
3 需求驱动架构，架起分析与设计实现的桥梁
4 架构与开发成本的关系
架构设计的复杂度
复杂度来源：高性能
性能
伸缩性
单机复杂度
进程
线程是任务调度的最小单元，共用进程内的资源。
线程
进程是资源分配的最小单元，与其他进程资源互相独立。
总结
集群复杂度
垂直拆分
增大内存减少I/O操作更换为固态硬盘（SSD）提升I/O访问速度使用RAID增加I/O吞吐能力置换服务器获得更多的处理器或分配更多的虚拟核升级网络接口或增加网络接口
水平拆分
集群（多实例副本）：同一组件重复部署到多台不同的服务器
功能分解：基于功能将系统分解为更小的子系统
数据分割：在每台机器上都只部署一部分数据
复杂度来源：高可用
计算高可用
存储高可用
高可用状态决策
1. 独裁式
2. 协商式
3. 民主式
如何做到高可用
核心思想：网站高可用的主要技术手段是服务与数据的冗余备份与失效转移。同一服务组件部署在多台服务器上；数据存储在多台服务器上互相备份。通过上述技术手段，当任何一台服务器宕机或出现各种不可预期的问题时，就将相应的服务切换到其他可用的服务器上，不影响系统的整体可用性，也不会导致数据丢失。
从架构角度看可用性：当前网站系统多采用经典的分层模型，从上到下为：应用层、服务层与数据层。应用层主要实现业务逻辑处理；服务层提供可复用的服务；数据层负责数据读写；在部署架构上常采用应用和数据分离部署，应用会部署到不同服务器上，这些服务器被称为应用层的服务器；这些可复用的服务也会各自部署在不同服务器上，称为服务层的服务器；而各类数据库系统、文件柜等数据则部署在数据层的服务器。
不可用的技术解决措施
(1)应用服务器。可通过负载均衡设备将多个应用服务器构建为集群对外提供服务（前提是这些服务需要设计为无状态，即应用服务器不保存业务的上下文信息，而仅根据每次请求提交的数据进行业务逻辑的操作响应），当均衡设备通过心跳检测手段检测到应用服务器不可用时，则将其从集群中移除，并将请求切换到其他可用的应用服务上。
(2)服务层服务器。这些服务器被应用层通过分布式服务框架（如Dubbo）访问，分布式服务框架可在应用层客户端程序中实现软件负载均衡，并通过服务注册中心提供服务的服务器进行心跳检测，当发现有服务器不可用时，立即通知客户端程序修改服务列表，同时移除响应的服务器。
(3)数据服务器。数据同步复制，数据库主从同步
复杂度来源：可扩展性
预测变化
应对变化
一应对变化的常见方案是将“变化”封装在一个“变化层”，将不变的部分封装在一个独立的“稳定层”。
1. 系统需要拆分出变化层和稳定层
2. 需要设计变化层和稳定层之间的接口
二常见的应对变化的方案是提炼出一个“抽象层”和一个“实现层”。
1 What：什么是架构的可扩展性？
2 Why：为什么要求架构具备良好的可扩展性？
3 How：如何设计可扩展性好的架构？
（1）从业务维度。对业务深入理解，对可预计的业务变化进行预测。
（2）从技术维度。利用扩展性好的技术，实现对变化的封装。
4.在实际工作场景中的解决方案
（1）使用分布式服务(框架)构建可复用的业务平台。
（2）使用分布式消息队列降低业务模块间的耦合性。
复杂度来源：低成本、安全、规模
架构设计原则
合适原则，合适优于业界领先
简单原则，简单优于复杂。
演化原则
首先，设计出来的架构要满足当时的业务需要。
其次，架构要不断地在实际应用过程中迭代，保留优秀的设计，修复有缺陷的设计，改正错误的设计，去掉无用的设计，使得架构逐渐完善。
第三，当业务发生变化时，架构要扩展、重构，甚至重写；代码也许会重写，但有价值的经验、教训、逻辑、设计等（类似生物体内的基因）却可以在新架构中延续。
架构设计流程
识别复杂度
（1）构建复杂度的来源清单——高性能、可用性、扩展性、安全、低成本、规模等。
（2）结合需求、技术、团队、资源等对上述复杂度逐一分析是否需要？是否关键？
“高性能”主要从软件系统未来的TPS、响应时间、服务器资源利用率等客观指标，也可以从用户的主观感受方面去考虑。“可用性”主要从服务不中断等质量属性，符合行业政策、国家法规等方面去考虑。“扩展性”则主要从功能需求的未来变更幅度等方面去考虑。
（3）按照上述的分析结论，得到复杂度按照优先级的排序清单，越是排在前面的复杂度，就越关键，就越优先解决。
设计备选方案
第一种常见的错误：设计最优秀的方案。
第二种常见的错误：只做一个方案。
第三种常见的错误：备选方案过于详细。
（1）备选方案不要过于详细。备选阶段解决的是技术选型问题，而不是技术细节。
（2）备选方案的数量以 3~5个为最佳。
（3）备选方案的技术差异要明显。
（4）备选方案不要只局限于已经熟悉的技术。
评估和选择备选方案
CAP理论
1. 一致性（Consistency）
2. 可用性（Availability）
3. 分区容忍性（Partition Tolerance）
虽然 CAP 理论定义是三个要素中只能取两个，但放到分布式环境下来思考，我们会发现必须选择 P（分区容忍）要素，因为网络本身无法做到 100% 可靠，有可能出故障，所以分区是一个必然的现象。
遗留： Paxos 算法
ACID 是数据库事务完整性的理论
1.Atomicity（原子性）
2.Consistency（一致性）
3.Isolation（隔离性）
4.Durability（持久性）
CAP 是分布式系统设计理论
BASE 是 CAP 理论中 AP 方案的延伸。
1. 基本可用（Basically Available）
2. 软状态（Soft State）
3. 最终一致性（Eventual Consistency）
FMEA 方法
具体分析方法
给出初始的架构设计图。
假设架构中某个部件发生故障。
分析此故障对系统功能造成的影响。
根据分析结果，判断架构是否需要进行优化。
1.功能点
2.故障模式
3.故障影响
4.严重程度
5.故障原因
6.故障概率
7.风险程度
8.已有措施
9.规避措施
10.解决措施
11.后续规划
收藏
0 条评论
回复 删除
下一页
