持续演进的Cloud Native (读书笔记03)

可用性设计

可用性和可靠性的关系

• 可用性（Availability）是关于系统可以被使用的时间的描述，以丢失的时间为驱动（Be Driven by Lost Time）。

• 可靠性（Reliability）是关于系统无失效时间间隔的描述，以发生的失效个数为驱动（Be Driven by Number ofFailure）。

• 可用性公式：A=Uptime /（Uptime+Downtime）。其中，Uptime是可用时间，Downtime是不可用时间。

• 可靠性公式：A=MTBF /（MTBF+MTTR）。其中，MTBF的全称是Mean Time Between Failure，即平均无故障工作时间，指上一次故障恢复后开始正常运行到这次故障的时间平均值。MTTR的全称是Mean Time ToRepair，即平均故障修复时间，是指从出现故障到完全恢复的这段时间。

可用性的衡量标准

   可用性通常以N个9的方式来量化衡量

什么降低了可用性

• 发布。当应用需要升级的时候，为了得到更好的用户体验，应用不能中断，如果需要迁移数据，会导致整个流程相当复杂。为了降低复杂度和开发成本，我们通常会暂时中断服务。

• 故障。发生故障的时候，系统可用性会受到影响，例如出现内存溢出，可能导致整个服务不可用。当然并不是所有的故障都会导致不可用，例如一个商品详情页中的推荐购买不显示了，实际上并没有影响可用性，但是如果价格不可见了，那么用户不能提交订单，这就影响了购买商品的可用性。

• 压力。很多宕机都是因为突发的事件导致的，例如某某明星在微博发布“介绍一下我的女朋友”信息，预期之外的访问压力会造成系统宕机，而预留太多冗余资源又比较浪费。所以部署到公有云或者基于公有云做混合云是一种既可以应对超预期的流量又省钱的办法。

• 外部强依赖。如果外部依赖的服务发生故障，则会导致调用异常，进而导致系统的不可用。外部依赖的服务越多，做到高可用的挑战就会越大。

  要实现高可用，需要在设计阶段考虑如下几个比较重要的方法：

• 20/10/5，设计系统的时候，以实际流量的20倍来设计；开发系统的时候，以实际流量的10倍来开发系统；发布系统的时候，以实际流量的5倍来部署。这只是一个通用的原则，可以根据实际情况来确定，不需要严格按照倍数来执行。

• Design for failure，预测可能发生的问题，做好预案。例如当流量高峰的时候如何限流、伸缩、隔离故障节点。

  提升可用性方法：

逐步切换

• 影子测试

• 影子测试是一种常用的在生产环境中通过流量复制、回放和比对的测试方法。

• 蓝绿部署

• 蓝绿部署是一种以可预测的方式发布应用的技术，目的是减少发布过程中服务停止的时间。

• 灰度发布/金丝雀发布

容错设计

• 消除单点
• 特性开关
• 服务分级
• 隔离策略

• 线程池隔离。
• 进程隔离。
• 集群隔离
• 用户隔离
• 租户隔离

• 超时重试

• 简单重试模式——try-catch-redo
• 策略重试模式——try-catch-redo-retry strategy
• 重试策略的逻辑是通用的，早已经有人把这个逻辑抽象出来了 Spring-tryer和Guava-retrying

• 熔断器
• 降级设计

• 降级方式

• 关闭某个功能，页面显示不全或不能点击某个按钮
• 请求短路，直接返回缓存结果
• 简化流程，放弃某个操作，如给用户发注册成功短信。
• 延迟执行，停止定时任务，如某些结算。

• 降级的方法

• 页面加开关，通过JS控制功能是否隐

• 关闭低级别服务前端页面。例如一些运营系统，为了统计、反馈，这些运营系统可能会访问某个核心服务，可以直接关闭前端页面应用。

• 预先定义降级逻辑。在配置中心定义一个变量，预先定义好变量的含义，例如变量的值为3，则要求所有的3级以下的服务都不调用，可以结合微服务框架，通过框架的隐含参数来实现。在紧急情况下，可以启用此按钮。

• 降低精确度。例如在电商中，库存可以显示为有货或者无货，而不是具体的数量。价格可以不那么及时更新，当提交订单的时候再计算最新值，毕竟浏览的人多，下单的人少。

流控设计

• 限流算法

• 漏桶算法（Leaky Bucket）
• 令牌桶算法（token bucket）
• 漏桶算法和令牌桶算法的对比

• 流控策略

• 请求入口处 比如nginx
• 业务服务入口处

• 基于Guava限流

• 平滑突发限流
• 平滑预热限流

• 基于Nginx限流

• 连接数限流模块ngx_http_limit_conn_module

• 请求限制模块ngx_http_limit_req_module

容量预估

• 互联网公司普遍采用全链路压测的方式，如京东的ForceBot、阿里巴巴的全链路压测平台
• 全链路压测平台在请求入口进行真实流量复制，开源实现可以参考TCPCopy

故障演练

• Netflix开源了Chaos Monkey,Chaos Monkey是一个在生产环境随机选择并关闭服务的工具,Chaos Monkey属于Netflix的Simian Army产品中的一员，Simian Army由一组工具构成.

• 阿里巴巴也开始进行故障演练，它的工具名称叫MonkeyKing，为每年的“双11”活动做准备。MonkeyKing可以模拟硬件故障、API故障、分布式故障、数据库故障等。

数据迁移

• 逻辑分离，物理不分离 逻辑分离，物理不分离的优点是足够简单，缺点是隔离性差，容易引发全局故障。
• 物理分离 物理分离的优点是隔离性好，缺点是数据同步比较复杂
• 如果逻辑分离，物理不分离可以满足，则采用它，它更简单高效。如果采用物理分离，以下几种方案可以实现数据库同步。

• 利用数据库同步工具通过读取binlog实现数据双向同步

• 在业务应用上同时双写两个数据库。

• 老系统在写数据库的同时，发送消息到消息中间件，消费消息从消息中间件实现同步。

• 无论采用以上哪种方式同步数据，都不可避免地会遇到一致性问题。

关注公众号 获取更多精彩内容