部署是将服务的某个版本投入生产环境的过程。部署的总体目标是:对系统用户产生最小影响的情况下,把服务的升级版本投放到生产环境中。

服务变更的主要原因:

  • 1、修复错误
  • 2、提高服务的质量
  • 3、增加新的功能

服务变更需要注意哪些(或者说如何产生最小影响)?

SRE 经验告诉我们,大概 70% 的生产事故由某种部署的变更而触发。变更管理的最佳实践可使用自动化来完成以下几点:

  • 1、部署尽可能在用户少的时候。
  • 2、每次部署前备份原始数据。
  • 3、采用渐进式发布机制。
  • 4、迅速而准确地检测到问题的发生。
  • 5、当出现问题时,安全迅速地回退改动。

常用部署方式存在以下几种:

  • 蓝绿部署
  • 滚动部署
  • 灰度部署/金丝雀部署

蓝绿部署

定义:

蓝绿部署(部分称大翻转或红/黑部署),首先准备N台提供版本A服务的机器,同时准备N台提供版本B的机器。一旦版本B的N台机器配置好并准备好服务请求,通过切换路由到版本B,例子如下所示:

1、绿色表示当前的生产应用程序V1

2、现在,当您准备对app2进行更改并将其升级到v2时,您将在”蓝色环境”中执行此操作。在该环境中,您可以部署新版本的应用程序,运行冒烟测试以及任何其他测试(包括操作系统,缓存,CPU等)。当结果看起来不错时,您可以将负载均衡器/反向代理/路由器更改为指向蓝色环境:

方法:
  • 可以通过切换域名服务器(DNS)
  • 更改负载均衡器路由切换
优点:
  • 更新过程无需停机,风险较少
  • 回滚方便,只需要更改路由或者切换DNS服务器,效率较高
缺点:
  • 需要部署两套机器,费用开销大
  • 在非隔离的机器(Docker、VM)上操作时,可能会导致蓝绿环境被摧毁风险
  • 负载均衡器/反向代理/路由/DNS处理不当,将导致流量没有切换过来情况出现

滚动发布:

定义:

现生产N台机器都为版本A的机器,部署取出一个或者多个服务器停止服务,执行更新版本B,更新后重新将其投入使用,继续不断更新其他机器,直到集群中所有的实例都更新成版本B。

流程:
  • 1、负载均衡或者路由移除一台或者多台实例(正常监控也需要移除)
  • 2、移除后的实例开始更新
  • 3、上线测试后无异常开始接入负载均衡器或者路由
  • 4、新增实例监控
  • 5、继续上线后一批实例,直到集群中所有的实例都更新
优点:
  • 更新过程体验影响少,风险较少
  • 费用对比蓝绿花费开销较少,无需额外新增机器
缺点:
  • 上线/回滚完成时间相对较慢
  • 需要监控和负载均衡器的移除和接入能力

灰度发布

定义

灰度发布(又名金丝雀发布)是指在黑与白之间,能够平滑过渡的一种发布方式。在其上可以进行A/B testing,即让一部分用户继续用产品特性A,一部分用户开始用产品特性B,如果用户对B没有什么反对意见,那么逐步扩大范围,把所有用户都迁移到B上面来。灰度发布可以保证整体系统的稳定,在初始灰度的时候就可以发现、调整问题,以保证其影响度。(类似地下采煤使用的金丝雀方法,当金丝雀遇到有毒气体时候,产生痛苦信号)A/B testing和金丝雀的差别在于A/B 测试对于特定业务的关键绩效指标来说,确定那个版本执行得更好。

方法
  • 首先部署少量服务器密切
  • 观察是否因为版本产生预期结果
  • 当结果满意时候再全量部署

优缺点可以参考上面

关于CAP定理

  • 一致性(Consistence) (等同于所有节点访问同一份最新的数据副本)
  • 可用性(Availability)(每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据)
  • 分区容错性(Partition tolerance)(以实际效果而言,分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性,就意味着发生了分区的情况,必须就当前操作在C和A之间做出选择[3]。)

我们这里只讨论一致性问题,其他你们可以自行思考下:

  • 建议无状态(session等信息存放在缓存数据库)
  • 如果新版本的操作涉及到数据库更改,建议保持只新增不删减字段操作

要是存在多版本同时存在,注意考虑以下:

  • 1、功能开关
  • 2、前后版本兼容

参考资料包括以下:

Comments

2018-07-29