厦门物业备案建设局登什么网站,百度点击器找名风软件,百度知道在线问答,浙江省职业建设学院官方网站简介#xff1a;在日常和用户交流过程中#xff0c;我们也经常会被用户问到关于发布的问题#xff0c;比如不同职能团队之间应该如何配合、发布的最佳实践应该是什么样子的等等。今天我们就来聊聊常见应用发布方式的选择#xff0c;以及每种发布模式适合什么样的场景。 无论…简介在日常和用户交流过程中我们也经常会被用户问到关于发布的问题比如不同职能团队之间应该如何配合、发布的最佳实践应该是什么样子的等等。今天我们就来聊聊常见应用发布方式的选择以及每种发布模式适合什么样的场景。 无论从开发运维还是产品运营的角度来看任何一次上线都是有风险的。从最基本的应用停止导致流量丢失、服务不可用、服务QPS水位下降到步骤的遗漏、流程的不规范、开发过程中引入的bug以及新产品/新功能上线导致用户体验的变化都会导致线上风险。在日常和用户交流过程中我们也经常会被用户问到关于发布的问题比如不同职能团队之间应该如何配合、发布的最佳实践应该是什么样子的等等。今天我们就来聊聊常见应用发布方式的选择以及每种发布模式适合什么样的场景。
平滑升级滚动发布
分批发布通常指取出一例或多例应用实例将其停止服务、升级到新版本周而复始地重复这一过程直到所有实例都升级到新版本。使用滚动发布可以最大程度地避免因发布导致的流量丢失和服务不可用问题这一模式也是Kubernetes应用部署使用的缺省模式。
针对部署规模较小、领域边界较清晰同时面临业务快速发展变化的微服务应用滚动发布流程简易且可靠性较高。不过由于通常情况下缺乏强干预手段发布的可逆程度较差一旦在发布过程中觉察到问题往往需要进行全量回滚。
一般来说滚动发布适用于符合如下条件的场景
应用部署规模较小、启动和回滚的速度较快应用所关注的业务领域范围相对小、边界较清晰且易于进行线上回归验证发布人员充分理解、掌握平台所提供的滚动发布策略新版本引入的变更具有向下兼容性。
下面我们分别以ECS和Kubernetes为例展示如何在云效平台上进行滚动发布。
面向ECS的滚动发布
在云效中我们可以使用主机部署任务进行滚动发布。如图所示假设需要对以下由2台ECS构成的主机组进行滚动发布每次滚动更新1台主机 在流水线中配置主机部署任务 设置“暂停方式”为“不暂停”、“分批数量”为2即可实现滚动发布。 在进行ECS滚动发布时需要注意一点通常情况下滚动发布中的主机无法对外提供服务这意味着集群整体服务水位如可承接的QPS会降低——例如在上面2台主机分2批发布的过程中集群始终只有1台主机可以响应请求整体QPS水位下降了50%。发布人员需要仔细评估“由于发布而导致服务主机不可用”对服务水位的影响并选择合适的时间如业务低峰期进行发布。
原生支持Kubernetes YAML滚动发布
YAML发布是我们在使用Kubernetes时最直接的应用部署方式。在持续交付流水线中我们一般将这些用于描述Kubernetes资源的YAML文件通过Git进行统一版本管理通过云效CI/CD平台监听代码库的变更事件并通过流水线将这些YAML变更同步到集群当中。
例如下面的app.yaml
apiVersion: apps/v1
kind: Deployment
metadata:name: nginx-deploymentlabels:app: nginx
spec:replicas: 3selector:matchLabels:app: nginxtemplate:metadata:labels:app: nginxspec:containers:- name: nginximage: ${IMAGE}ports:- containerPort: 80
由于没有声明发布策略Kubernetes会缺省指定RollingUpdate策略也即滚动发布。
YAML文件中的占位符${IMAGE}是为云效流水线专门留出的替换变量发布时会被替换成具体的镜像。
如下图所示我们可以通过“Kubernetes发布”任务实现上述Deployment的滚动发布 具体的发布进度可以参考发布单中的展示 极简体验Kubernetes镜像升级
在一些开发团队与运维团队分工较为明确的场景中开发团队可能希望够尽可能少地理解Kubernetes相关概念由专职的运维团队负责完成应用环境的部署和初始化开发团队只负责完成代码开发并通过流水线自动化完成应用镜像构建并使用该镜像对集群中已有的应用进行升级。
如下图所示在云效流水线中我们监听应用代码库的变化并构建出相应的Docker镜像发布阶段只需要指定对集群中实例并关联前序任务产生的镜像即可完成应用的升级发布。与YAML发布相同缺省情况下镜像升级也使用了滚动发布模式 如上所述该场景适用于
开发和运维分离运维团队充分理解Kubernetes的原生发布策略开发团队只负责产出代码以及应用镜像由运维团队负责集群中应用的实际运维管理
过程可控分批发布
分批发布通常指取出一批应用实例将其停止服务、升级到新版本人工观察实际效果符合期望后再取出下一批周而复始地重复这一过程直到所有实例都升级到新版本。在滚动过程中新旧版本共存且同等地接受流量、提供服务发布人员基于对服务质量如请求成功率、响应时间等基础指标或特定的业务成功率等业务指标进行观察决定是否进一步扩大新版本部署比例或是放弃发布进行回滚。
分批发布的基本模式与滚动发布相似主要差异则在于允许人工控制新版本上线、老版本下线的过程。由于新版本的部署比例可控发布人员可以预先制定批次部署计划在少量部署的新版本上基于生产环境流量进行小规模线上验证若应用自身规模较大或逻辑较复杂维持一段时间的小规模验证也能起到线上回归测试的作用。另一方面人工控制部署批次使得发布整体具有较好的可逆性一旦在小规模验证中发现问题可以快速回滚已经发布的新版本。
分批发布通常适合
应用在业务链路中较为关键部署规模较大业务逻辑较复杂进行线上验证时难以圈定灰度流量需要使用较少比例的新版本部署进行验证以期控制风险影响面新版本引入的变更具有向下兼容性。
面向ECS的分批发布
在云效中主机部署任务也可以被配置为分批发布模式如下图所示 我们可以通过指定“第一批暂停”或“每批暂停”实现分批控制
若指定“每批暂停”则每一批发布完成后都需要人工确认后方可发布下一批。这种模式适合需要全程控制发布节奏的场景通过逐步观察线上指标逐步确认新版本的正确性或是有明确的发布计划如“先部署1批占比10%、夜间业务低峰期次日9-11点业务高峰期观察无问题后按30%、50%、80%、100%实例数递进部署每批停顿不少于30分钟期间观察线上指标若出现问题则回滚”。若指定“第一批暂停”则只有第一批发布结束后会等待发布人员确认一经确认此后的各批次将自动部署与滚动发布类似。这种模式结合了滚动发布的简便性以及分批发布的小规模验证、快速回滚能力通常适用于“先进行一批小规模线上验证验证通过后即可全量发布”的场景。
发布人员可根据应用的部署规模、重要程度及逻辑的复杂程度选用不同的分批暂停模式。
面向Kubernetes的分批发布
云效的分批发布中我们以Service为最小发布单元在发布开始阶段我们将基于新版镜像创建出应用的版本V2并根据当前应用的副本总数以及分批数量对新旧两个版本的应用实例分别进行缩容和扩容来控制实际进入到新版应用的流量比例从而可以实现小规模的发布验证在对发布进行充分验证后再逐步完全下线老版应用。
与ECS部署类似批次之间支持暂停和手动恢复用以对发布过程进行控制。 该模式适用于采用Kubernetes原生的服务发现机制并希望获得相比于原生Kubernetes发布更好过程控制性以及安全性的用户。
流量可控灰度发布
较之滚动/分批发布灰度发布加强了对线上验证影响范围的控制通常需要以同样的实例数部署新/老版本两套服务再通过流量分发控制手段将特定的线上流量导入新版本、其余流量仍然流入老版本线上验证通过后所有流量都将导入新版本实例而老版本实例则可用作下一次发布的模板。
常见的流量分发控制手段如
支持流量在新/老版本之间按比例分配支持匹配特定URL/cookie/header/业务字段如用户ID的流量流入新版本。
使用相对明确的规则进行流量分发控制从技术团队的角度来看意味着进一步的变更风险控制发布人员可以选定具有某种特征的请求用于在验证新发布的功能同时使得影响范围尽量容易识别。而从产品运营团队的角度来看灰度发布除了可以更精确地控制技术风险的影响面之外更重要的一点是可以辅助他们进行客户数据对比举例来说运营团队可以事先和某些有意向体验新功能的客户达成合作使用灰度方式为他们开通新功能进行试用另一类典型的例子则是A/B test, 通过灰度发布提供的流量控制能力收集新/老版本的用户数据用以评估新的设计是否更为合理。
灰度发布一般适用于
能够定义流量分发规则如header、cookie、用户ID等变更具有较高的技术风险或对业务有较大改动需要将受影响的流量控制在较为精确的范围内如先让内部员工试用进行线上验证产品运营团队希望使用线上的自然流量对新/老设计进行比较。
由于Kubernetes生态提供了很多方便的流量管控手段我们以kubernetes发布为例展示如何在云效上进行灰度发布。
Kubernetes外部流量Ingress灰度发布
一种典型的对外接收流量的场景是使用Ingress暴露服务。在云效流水线的Ingress灰度发布中我们以Ingress作为发布单元当触发部署后将会根据当前Ingress以及其关联的Service/Deployment资源基于新版镜像创建出V2版本的Service/Deployment并通过Nginx Ingress的Annoation完成对流量规则声明从而确保只有满足特定特征的流量才能进入到V2版本中。
例如在下图的流水线中我们根据cookie匹配流量进行灰度发布 当处于灰度状态时流水线将会等待人工验证以触发发布或者或者回滚操作。 Kubernetes内部流量Istio/ASM蓝绿发布
当采用微服务架构时大部分的后端服务只在集群内部开放微服务之间通过Kubernetes Service进行相互访问。在这种情况下如果希望采用灰度发布模式则需要在Service级别进行流量控制以确保指定的流量进入到灰度的链路而不对正常用户产生影响。
不过由于Kubernetes原生Service级别并不支持任何的流量控制规则因此我们需要在集群中部署Istio或者采用阿里云ServiceMesh来对服务之间的流量进行细粒度的控制。
如下图所示当使用Kubernetes蓝绿发布模式时可以设置灰度流量规则从而只有当请求中包含指定的Cookie配置的请求转发到灰度版本当中 该模式适用于采用Istio或者阿里云ServiceMesh的Kubernetes用户并且希望能够通过灰度的方式对发布进行验证。
原文链接 本文为阿里云原创内容未经允许不得转载。
