一. 架构高可用评价维度：
- 指系统在面对各种异常时可以提供正常服务的能力
- 系统的可用性可以用系统停服务的时间和正常服务时间的比例来衡量
- 系统不可用时间(故障时间=故障修复时间点-故障发现时间点)
- 几个9
- 4个9的可用性(99.99%)
• 具备自动恢复能力的高可用
• 一年停机的时间不能超过53分钟
• 3652460/10000 = 53分钟 - 5个99的可用性(99.999%)
• 极高可用性
• 一年停机的时间不能超过5分钟
• 3652460/100000=5分钟
- 4个9的可用性(99.99%)
二. 服务分级
2.1 服务名和服务级别对应关系的梳理，例如：
2.2 事故级别定义：
• 确定服务级别
• 使用最合适衡量标准确定事故的影响面
三. 稳定性按系统层次划分:
3.1 接入层稳定性设计大纲
3.1.1 接入层Session设计遇到的问题？
- 高可用主要基于服务无状态
- 事实上业务总是有状态的，如，用户点餐，需要记录
- 这些有状态的信息会随用户操作变化而发生更新
3.1.2 接入层Session设计
- 服务端设计：
- 集群(多机)设计-Session复制，根据路由策略路由到任一机器
- 优势：高可用保证
- 劣势：海量的session复制，占用带宽，每台机器全量拷贝，会出现oom。
- Session绑定：通过hash(ID)，路由到指定的session服务器，存储方式：本地内存，redis，mysql,nosql
- 优势：高可用保证，M-S。
- 客户端设计：
- 客户端保持session:
- Session由服务端生成，存储到客户端
- 每次请求携带客户端Session
- 服务端若有更新返回给客户端存储。
- 对于app存储到Native，对于web存储到Cookie中。
-
Session高可用集群：
- 接入层无状态化
- 统一的高可用Session服务器
- 接入层分布式读写Session集群
- 状态分离：
1.接入层本身无状态。
2.Session集群有状态。
3.存储：分布式缓存，sql或nosql数据库。
3.1.3 模块和数据分离：
- 接入层模块无状态：
- 动态线性伸缩
- 冗余
- Session数据统一分布式存储：
- 数据冗余保证
- 高可用性保证
3.1.4 接入层最佳实践:
1.模块和数据分离。
2.Session绑定。
3.不存储Session。
3.2 逻辑层稳定性设计大纲：
3.2.1 逻辑层职责：整个系统中业务逻辑的处理。
3.2.2 逻辑层如何设计?
- 业务间物理垂直划分方式
优点：
1.业务间完全解耦
2.业务间互不影响
3.业务模块独立。
4.业务模块独立。
5.效率高。
3.2.3 无状态业务逻辑层设计：
- 关键因素：
1.业务逻辑层不保存请求状态。
2.业务逻辑层不保存数据。
3.所有业务逻辑层服务器完全对称。
4.当一台或者多台宕机。
5.请求提交到集群中的任意可用服务器。
6.业务逻辑层高可用-负载均衡。 - 负载均衡（LVS/Nginx）：
1.服务器可用状态实时监测的机制。
2.自动转移失败任务(机器)的机制。
3.请求量和数据量较高，将流量和数据分摊到集群中多台服务器的能力。
4.通过心跳机制发现下游服务器不可用，剔除掉。
5.一旦服务器可用，可以自动重连恢复。
3.2.4 业务逻辑层如何异步调用?
优缺点：
1.异步调用优点：线程(调用者)非阻塞，一直Running，CPU利用率高，系统性能高，系统吞吐量高。
2. 异步调用缺点：实现成本稍高，代码可读性差。
方案一（业务解耦考虑）：消息队列方案（kafka）：
通过消息队列(缓冲、持久化、解决异步)实现异步调用
例子：
新用户注册请求，假设需要2步
» 第一步:用户名和密码写入数据库
» 第二步:发送注册成功邮件异步方式：
» 新用户注册请求写入消息队列，直接返回成功给请求调用者
» 业务逻辑层通过成消息队列中读取请求，异步执行第一步和第二步 » 调用者不阻塞，效率高
» 系统性能高
方案二 (性能提升考虑)：nio,netty,nodejs,vert.x。
高性能纯异步网络调用设计:
• server端连接池+server端收发队列;
• client端连接池+client端收发队列; • 超时队列与超时管理器;
• 上下文管理器+状态机;
3.2.5 业务逻辑层如何分级管理:
1.部署层面：
• 服务部署隔离
• 避免故障带来的连锁反应
• 核心系统部署在物理机上
• 核心系统部署不同的机房 • 边缘系统部署虚拟机
• 边缘系统公用机器
监控分级层面
• 核心服务更多类型的监控
– 进程
– 语义
– 错误日志 – ......
• 监控粒度更细致
• 邮件和短信发送通知响应分级层面：
• 核心服务开发响应迅速
• 核心服务上线响应迅速
• 核心服务运维响应迅速
• 核心服务上线问题处理迅速
3.2.6 设置合理超时：
1.设置合理超时的重要性：
- 业务逻辑层和下游模块交互次数多
- 设置合理超时非常重要
- 下游服务宕机、线程死锁等，请求得到不到响应 – 请求占用资源
- 调用方得不到响应，用户体验糟糕
2.设置合理超时：
- 请求的超时设置根据请求的平均响应延迟:经验值
- 超时时间是平均响应延迟的2倍，避免过长时间等待
- 响应延迟高，超时时间设置长些：3S
- 响应延迟低，超时时间设置短些100MS
- 下游请求超时后，业务层根据预设的调度策略
- 继续重试
- 一般3次
- 多次无好处
- 请求转移到下游其他同样服务上
3.2.7 业务逻辑层服务降级设计：
1.降级必要性:
- 网站高峰期，并发量大
- 服务能力有限
- 性能下降
- 服务宕机
- 系统雪崩情况
2.降级方案：
- 拒绝部分请求
- 关闭请求
3.拒绝部分请求
• 拒绝低优先级服务的调用
• 减少服务调用并发数
• 确保核心服务正常使用
- 关闭部分服务：
• 非核心服务直接关闭
• 业务逻辑层屏蔽掉
• 不再调用
• 节约系统开销
• 保证核心服务的正常响应
• 秒杀活动
• 双11.11活动
3.2.8 业务逻辑层如何做到幂等设计?
1.天然幂等，如把离线消息设置为已读，多次设置都是一样的。
2.非幂等->幂等设计：
如： 支付
- 支付ID，支付状态
- 每次支付前，判断支付状态，未支付状态继续进行，已支付了就中止
3.2.9 业务逻辑层稳定性总结：
• 无状态
• 冗余部署
• 异步
• 超时机制
• 请求分级
• 幂等设计
• 高性能
3.3 数据存储层稳定性设计大纲
3.3.1 数据存储高可用的几个原理：
3.3.1.1 CAP定理与设计
- 一致性(Consistency)、可用性(Availability)、分区可容忍性(Tolerance of network Partition)。
- 在分布式环境下，三者不可能同时满足
-分布式存储系统需要能够自动容错，也就是说分区容忍性需要保证：
- 保证一致性
– 强同步复制
– 主副本网路异常，写操作被阻塞，可用性无法保证 - 保证可用性
– 异步复制机制
– 保证了分布式存储系统的可用性 – 强一致性无法保证 - 一致性和可用性需要折中权衡
- 不允许数据丢失(保证强一致性)
» 金融
2.小概率丢失允许(保证可用性)
» 消息
3.3.1.1 2PC协议与设计
• 实现分布式事务
• 两类节点
– 协调者
» 1个
– 事务参与者
» 多个
• 每个节点都会记录Commit Log，保证数据可靠性
• 两阶段提交由两个阶段组成
- 请求阶段
- 提交阶段
3.3.1.2 Paxos协议与设计
- 用于解决多个节点之间的一致性问题
- 多个节点，只有一个主节点
- 主节点挂掉，能够选举新的节点
- 主节点往往以操作日志的形式同步备节点
- 角色：
- 提议者( Proposer)
- 接受者( Acceptor)
- 执行步骤：
- 批准( accept)
Proposer发送accept消息到Acceptor要求接受某个提议者 - 确认(acknowledge)
如果超过一半的Acceptor接受，意味着提议值生效， Proposer发送acknowledge消息通知所有的Acceptor提议 - 生效
2PC协议与Paxos协议
3.3.2 数据存储层冗余我们如何做
3.3.2.1 数据复制：
基于日志
Master-Slave:
– MySQL、MongoDBReplic Set:
– MongoDB双写
- 存储层多主对等结构
- 数据模块层对存储层双写
- 比较灵活
- 数据模块层成本较高
3.3.3 数据备份落地
- 数据冷备份
- 数据热备份
3.3.3.1 数据冷备份:
将数据复制到某种存储介质上(磁盘等)
- 优点:
- 简单、廉价
- 成本和技术难度都较低
- 缺点:
- 定期备份
- 数据一致性保证不了
- 恢复时间长，系统高可用保证不了
3.3.3.2 数据热备份:
1.方法：
- Online异步热备份
- Online同步热备份
2.数据异步热备份：
- 多份数据副本写入异步完成
- 应用程序写入成功一份数据后，即返回
-
由存储系统异步写入其他副本
4.jpeg
3.数据同步热备份：
- 多份数据副本写入同步完成
- 应用程序收到所有副本的写入成功
- 应用程序收到部分服务的写入成功，可能都成功(网络故障无法返回成功resp)
- 为了提高写入性能，应用程序并发写入数据
- 没有主从之分，完全对等
- 响应延迟是最慢的那台服务器，而不是所有响应延迟之和
3.3.3.3 数据存储层失效转移机制：
- 失效确认：
- 是否宕机
- 心跳
- 访问转移：
- 访问路由到非宕机机器 • 存储数据完全一致
- 数据恢复：
- Master-Slave
- 日志
3.3.3.4 数据存储层如何做无缝数据迁移：
- 数据类型：
1.时效性数据，特点：过期作废(1个月)，迁移简单
2.核心数据，特点：永久有效，迁移复杂
时效性数据迁移方案：
核心数据迁移方案：
3.3.3.4 数据存储层高可用最佳实践
- 可用性
- 可靠性
- 一致性
- 备份
- 转移
3.4 分布式缓存层稳定性设计大纲：
3.4.1 分布式缓存类型:
- Memcached
- Redis
- 自主研发
3.4.2 高可用架构缓存原则：
- 缓存就是缓存，不是磁盘数据库。
- 一旦缓存不可用，查询数据库。
- 那么问题来了，数据会不会挂掉?
- 缓存集群，宕机某台几率大，宕机多台几率小
- 宕机某台，对数据库影响不大，不会产生雪崩
- 预估宕机一台，数据库可以承受的最大压力
3.4.3 高可用架构缓存一致性
- 多份数据副本（数据库、多份缓存），数据一致性问题会存在
- 强一致性较难
- 追求最终一致性
3.4.4 高可用架构缓存命中率:
- 业务不同，命中率不同
- 命中率80%+
- 相对静态数据缓存
- 缓存时间长些
- 定期查看缓存命中情况，适当调整缓存对象
3.4.5 高可用架构缓存最佳实践
- 业务特点，选用多级缓存
- Local
- Process
- Distrubute
- 缓存高可用性保证
- 缓存宕机，数据库最大压力评估
- 缓存一致性
- 最终一致性
- 强一致性场合少
- 分布式锁、分布式队列
四.性能评估,扩容:
4.1 性能评估
4.1.1 目的：
- 找出系统性能瓶颈
- 提供性能优化方案
- 达到硬件和软件的合理配置，使系统资源使用平衡
4.1.2 性能评估工具(Linux)
4.1.2.1 CPU性能评估:
1.cup
- us:用户进程消耗CPU时间百分比，us值高，用户进程消耗CPU时间多，如果长期大于50%，优化程序;
- sy:内核进程消耗的CPU时间百分比;
- us + sy参考值为80%，如果us + sy大于80%，说明可能存在CPU不足。
- 进程
• r:运行和等待CPU时间片的进程数，如果长期大于系统CPU的个数，CPU遇到瓶颈，需要扩展CPU。
• b:等待资源的进程数，比如正在等待磁盘I/O、网络I/O等。
3.问题:
- 系统CPU整体利用率不高，而应用响应缓慢?
– 选择单线程还是多个线程? - CPU闲置问题
4.1.2.2 内存性能评估：
- free工具
• free [-m/-g]
• 应用程序可用内存数量: - 经验值
• 应用程序可用内存/系统物理内存 > 70% 内存充足
• 应用程序可用内存/系统物理内存<20% 内存不足，需要增加内存
• 20%<应用程序可用内存/系统物理内存<70%内存基本够用
4.1.2.3 磁盘I/O性能评估：
4.1.2.3.1 iostat工具：
• iostat –xdk 1
• 磁盘块设备分布
• rkB/s每秒读取数据量kB;
• wkB/s每秒写入数据量kB;
• svctm I/O请求的平均服务时间，单位毫秒;
• await I/O请求的平均等待时间，单位毫秒;值越小，性能越好;
• util 一秒中有百分几的时间用于I/O操作。接近100%时，表示磁盘带宽跑满，需 要优化程序或者增加磁盘;
• rkB/s、wkB/s根据系统应用不同会有不同的值，但有规律遵循:长期、超大数 据读写，肯定不正常，需要优化程序读取。
• svctm的值与await的值很接近，表示几乎没有I/O等待，磁盘性能好，如果await 的值远高于svctm的值，则表示I/O队列等待太长，需要优化程序或更换更快磁 盘。
4.1.2.3.2 ifstat工具:
- 各个网卡的in、out
- 观察网络负载情况
- 程序网络读写是否正常 – 程序网络I/O优化
- 增加网络I/O带宽
Load average分析:
- 含义： 任务队列的平均长度
1分钟、5分钟、15分钟前到现在平均值 - 分析方法：
这三个值的大小一般不能大于系统CPU的核数，如果三个值长期大于CPU的核数说明CPU很繁忙，负载很高影响机器整体系统;相反如果这三个值小于CPU个数，表示CPU比较空闲。
4.1.3 应用程序性能评估：
- 压力测试
• 确认模块的最大吞吐量 – QPS、TPS
2.模块单机压力极限衡量标准- CPU极限
» 线程32
» CPU3200% - 内存极限
» 内存32G
» 应用占完了，排除内存泄露的可能 - 磁盘I/O极限
» util 100% - 网络I/O极限
» 100Mb
» in、out带宽跑满了
3.日志:
根据日志统计出最大的QPS、TPS
- CPU极限
4.2 系统扩容原则:
4.2.1系统使用和优化原则
- 始终保留一定量的空闲资源。
- 多少合适?根据应用的特点，比如是否有突发性使用增长?
- 一般情况下，保留至少50%的系统资源，以应付流量增长(流量翻一倍);
- 一般情况下，资源使用率达到80%时，需要考虑扩容的事儿。
- 系统硬件达到合理的配置，资源消耗均衡为目标
1.系统性能的木桶理论 - 应用程序对资源的使用要均衡(理想目标)：
理想状况为:CPU消耗到50%的时候，磁盘I/O也到50%，网络I/O也到50%，内 存使用也到50%;
