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

可用性

可靠性：系统是否具有无差异的执行预期操做的能力。主要指标：是否经过了全部测试套件。 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。