可伸缩架构-面向增长应用的高可用

Posted 2020-10-06 wade&luffy

可用性

可靠性：系统是否具备无差别的执行预期操作的能力。主要指标：是否通过了所有测试套件。 3+2=6  不可靠

可用性：为了执行这些操作，系统当前可运行的能力。主要指标：是否能进行响应。

测量可用性公式：网站可用性百分比=(该期间的总秒数－系统宕机的秒数)/该期间的总秒数

N个9	百分比	每月的故障时间
2个9	99%	432m
3个9	99.9%	43m
4个9	99.99%	4m
5个9	99.999%	26s
6个9	99.9999%	2.6s

什么可能导致低可用性：

1. 资源耗尽　　io&网络&内存等
2. 预期之外的压力变化　　黑客攻击，突发事件流量
3. 流动行为的增加　　一次上线协作的人越来越多，发生失误的概率也就越大
4. 外部依赖　　外部的资源是否可用可靠的影响
5. 技术债务　　对已知bug未修复的累计，未知bug的隐患，新需求的合理性问题

提高可用性的五个要点：

1.  时刻考虑应对故障
2. 时刻考虑如何伸缩
3. 缓和风险　　即使服务和资源无法不可用时，依然确保系统以最好的最完整的状态工作
4. 监控可用性　　
   • 服务器监控
   • 配置变化监控
   • 应用程序性能监控
   • 人为测试
   • 报警　　
5. 以可预期及明确的方式来处理可用性问题

风险管理

风险管理就是在消除风险的成本与风险发生的成本(缓和风险)之间保持平衡。

风险缓和指的是通过降低风险发生的可能性或者降低风险发生时的严重性，来降低风险的影响。

风险的重要程度就会风险发生的严重性和可能性两者之和。为了降低风险，至少需要降低其中之一。 

严重性：如果发生风险，所需付出的代价。

可能性：风险发生的几率。 

管理系统风险的基本步骤：

1. 识别风险　　创建系统已知风险列表即风险模型。
2. 消除风险　　找出需要解决的风险，制定解决计划
3. 风险缓和　　制定缓和计划降低风险发生的可能性和严重性
4. 定期检查　　定期检查风险模型，更新计划 

风险模型的风险项：模版地址(http://bit.ly/architectbookdl)

1. 风险ID：每个风险的唯一标识。
2. 系统：风险所属系统或者子系统或者模块的名称。
3. 所有人：风险负责人抑或团队，负责制定风险的缓和计划和解决计划。
4. 风险描述：风险的概要描述，便于查看和领会。
5. 标识日期：该风险入模型的日期。
6. 可能性：分高中低。
7. 严重性：分高中低。
8. 风险缓和计划：正在使用的或者已商定的用来降低该风险严重性和可能性的措施和策略。
9. 状态：该风险当前的状态。活跃，已缓和，正在修复，已解决等。
10. ETA：该风险预估解决日期。
11. 监控：是否对该风险进行了监控，监控方式策略，譬如人为监控，每周定位。自动监控，日志触发。
12. 触发计划：此风险发生后，是否有计划处理此风险。时间响应文档，应急手册等。
13. 备注：记录风险对演化历史，以便于回溯。
14. 跟踪ID：需求或者bug ID。

风险模型的作用域：

1. 团队管理
2. 公司战略
3. 系统模块
4. 个人
5. 售后支持
6. 安全威胁

维护风险模型：

风险模型最大挑战就是人的惰性和模型本身对过时，需定期变换检查风险模型对人员，可以有碰撞和崭新对视角。

1. 发现新风险
2. 删除旧风险
3. 更新可能性和严重性
4. 检查优先级高的风险　　计划是否生效  当前状态和频率
5. 检查优先级低的风险

构建低风险系统的常用手段：

1. 冗余　　增强可用性
2. 幂等　　降低出错的概率
3. 独立性　　冗余后却都部署在一个机房就不具备独立性
4. 安全　　攻击，误操作等
5. 自修复　　集群 主备切换等
6. 运维流程　　保持脚本自动化  可追溯 可重现 减少人为的参与　　 

 微服务

为何要用微服务：

所有者收益：让每个服务都有清晰的所有权，团队可以只关注于他们负责的模块，以及依赖服务的api约定。

规模收益：系统在不同模块上的伸缩性需求不一样。

如何决定服务的边界：

1. 特定的业务需求　　 监管 信用卡等业务
2. 清晰独立的团队所有权　　负责该功能的团队是否清晰和独立，在不同城市不同楼层能否帮助确定服务边界
3. 天然的隔离的数据　　其管理的数据是否天然与其他数据相独立？
4. 共享的能力和数据 　　是否需要被其他模块共享？代办，消息等。

服务故障的常见形式和解决方案

级联式的服务故障：一个服务故障可能导致整个系统发生严重的问题。

对服务api的响应约定：

1. 可预测的　　返回错误提示信息
2. 可理解的　　格式和结构要稳定和统一
3. 对当前情形是合理的　　需要的是可删除的用户，因为错误，不能返回全部用户，应当返回无或者无法返回结果。

对服务api的请求约定：

1. 服务约束　　服务的能力范围，入参的合法性约束
2. QPS　　服务所能提供的最高并发请求数

 服务故障的应对：

1. 优雅降级　　不重要的服务可选择提供有限的功能，舍弃故障服务提供的数据
2. 优雅补偿　　搜索销量前十的服务故障，可返还最流行的前十的数据
3. 尽早失败　　核心的依赖服务故障或者输入参数不合法，自身的服务在注定会失败的前提下尽早失败。 

微服务的伸缩性(保证两个失误的高度，即挂两个节点的伸缩性)：

1. 丢失一个节点　　QPS会不会爆
2. 升级或者重启一个节点(轮流部署)　　升级中丢一个节点QPS会不会爆
3. 数据中心的冗余和恢复　　一个中心可能有多个节点  即也须考虑多个中心的伸缩性   数据中心越多每个数据中心所需的节点越少
4. 隐藏的共享故障　　机架停电  城市断电

服务所有权的义务和权利：

1. API设计　　api的设计实现测试和版本管理工作
2. 服务开发　　业务逻辑的设计开发和测试
3. 数据　　数据展现，模型，访问方式以及生命周期
4. 部署　　负责决定服务是否需要升级以及部署
5. 部署窗口　　决定什么时间可以进行安全部署
6. 产品变更　　负载均衡器的设置和系统调优
7. 环境　　管理服务的生产环境以及所有环境
8. 服务SLA　　讨论确定并监控SLA，以及保障服务满足SLA的相关工作职责
9. 监控　　监控SLA IO CPU等
10. 值班/突发事件响应　　确保突发事件的响应速度能满足之前定的SLA
11. 报告　　向外部发送内部报告，以及服务的运行健康报告。

服务分级：

1级服务　　如果某个服务出现故障会导致用户或者公司业务产生重大损失。 登录服务，权限服务，订单处理服务。

2级服务　　如果某个服务发生故障，会导致用户体验显著受到影响，但是不会导致无法使用你的系统。 搜索服务，订单结算服务。 

3级服务　　对用户造成较小的不易注意到的影响，对系统造成有限的影响。用户头像服务，推荐服务，每日提醒服务。

4级服务　　即使失败也不会对用户体验造成任何严重的影响，也不会对业务和资金方有任何影响。 销售报告服务，邮件发送服务。

使用服务分级：SLA服务等级协议

1. 期望　　对这个级数的服务的期望，可成为沟通语言的一部分，描述用户对系统的期待(外部SLA)，服务调用方对服务提供方的要求(内部SLA)
   • 调用延迟
   • 流量QPS
   • 运行时长  一段时间的可用性
   • 错误率
2. 响应性　　对这个级数的服务的响应性要求
   • 问题的严重性
   • 出现问题的服务级别
3. 依赖 　　依赖的梳理归类
   • 关键依赖   你的服务级别高于依赖服务的级别  自身服务在关键依赖故障时需仍然尽力提供功能
   • 非关键依赖  你的服务级别低于依赖服务的级别  可以忽略你依赖的此服务的故障，因为此服务的可用性和响应性比你高。

ps:

排名SLA，tp90>20ms(前置条件相同的QPS下)

tp90：(抽样总数*10%)  需要排除的样本数量    排除掉这么多的耗时最高的响应样本

20ms：取剩下的样本中耗时最高的响应时间

云服务 

区域：云资源相连形成的一大片地区成为区域，表示一个特定的地理区域。描述和记录了云资源的地理拓扑多样性，网络拓扑多样性。

可用区：一个区域包含多个可用区，表示一个区域指定部分的云资源。

数据中心：一个可用区包含多个数据中心。一个用来放置系统资源(例如服务器)的指定楼层，建筑物或者建筑群。

云资源分配：

1. 基于固定额度的资源分配，指定实例的数量，服务器的大小等。
   • 根据业务特性，实际场景或者当前资源的使用情况调整分配。
   • 预留容量，固定100台的使用量，其他100台的使用按小时计费。
2. 基于使用量的分配，可按存储和传输的数据量来计费。

各种基于云服务的应用程序运行环境：

1. 云服务器　　比较基础的服务器技术
2. 计算分片　　与服务器独立的计算环境中以托管的方式运行应用程序。 譬如google app engine
3. 动态容器　　动态分配资源，在不同服务器中迁移容器。包装了完整的服务器功能，提供了快速启动停止服务以及迁移服务到新系统的能力。 譬如docker
4. 微计算　　体积小，高度可扩展，基于事件驱动的运行环境。 譬如aws lambda。