软件|如何实现微服务的规模部署与批量发布?


【软件|如何实现微服务的规模部署与批量发布?】李鑫 架构头条 今天
软件|如何实现微服务的规模部署与批量发布?
本文插图

作者 | 李鑫
当微服务完成开发、测试后 , 就可以通过发布服务将其发布到线上 。 如果只看一个服务节点的部署 , 貌似是一项非常简单的工作 , 但如果同时发布成百上千个服务节点 , 尤其是需要在不影响线上业务的前提下完成发布工作 , 就会变得比较复杂 。
批量发布是风险度较高的事情 , 很大一部分线上事故都是由发布引起的 。 为了控制风险 , 需要对发布做足监控 , 将所有发布步骤在监控大盘上进行实时展示 , 如果出现发布问题 , 则应及时告警 , 并提供完善的回滚功能 。
1微服务的部署
包部署模式
以应用包或服务包的方式进行的部署工作 , 大部分是在非容器环境的物理机或虚拟机上进行的 。 如图 4.18 所示 , 在多机房情况下 , 每个机房都会有发布调度服务器 , 同时软件版本仓库在每个机房也都会有相应的镜像服务 。
软件|如何实现微服务的规模部署与批量发布?
本文插图

图 4.18 微服务的包部署模式
服务部署包分发
当发布指令从调度中心下发后 , 每个机房的发布调度服务器会通知本机房内应用服务器集群中的每个服务节点到本机房的软件版本仓库下载对应的服务发布包 。
这里要注意的是 , 如果服务节点过多 , 同时下载微服务的部署包可能会产生瞬时的“网络风暴” , 导致网络被堵塞 。 因此 , 在下载调度上需要做一些优化 , 让这些服务节点分批下载 , 或者控制能同时下载的服务节点的数量 。
服务状态检测
每个服务节点上新的服务部署包下载完成后 , 就要停止当前运行的服务进程 , 部署新版本服务 。
在停止服务时 , 由于服务上有正在运行的请求 , 需要等待这些请求处理完毕 , 同时不让新的请求进来 , 这就是所谓的“优雅停机” 。 可以通过服务注册中心将该服务节点直接删除 , 或者通过调整该服务节点的路由权重为 0 来控制不再有新的请求进入该服务节点 。 另一方面 , 可以通过一些系统钩子(如 JVM 中的 shutdownhook)来实现等待所有请求处理完毕再关闭应用的功能 , 同时做一些资源清理工作 。
新版本服务启动后 , 会自动到服务注册中心进行登记注册 , 并重新恢复路由权重 。 这样 , 新的请求会重新被路由到该服务节点 。
分批发布
微服务的发布如果要做到线上业务无感 , 就必须控制同时进行上、下线操作的服务节点的数量 。 因为如果一个服务集群中过多的节点下线 , 则剩余的节点可能无法负担当时线上所有的请求流量 , 所以针对服务发布 , 必须能控制同时进行上、下线操作的服务节点的数量或比例 。
服务发布执行
在图 4.18 中 , 发布调度服务器承担了“大脑”的作用 , 由它提供分批发布策略并向各个服务节点发出发布指令 。 微服务本身属于被操作的“物料” , 在服务节点上还需要有发布操作的“执行人” 。 承担执行人角色的可以是集成在服务节点中的 Agent , 这个 Agent 是一个独立的进程 , 在服务节点启动后同步启动运行 , 并不断监听发布调度服务的指令 , 收到具体发布指令后 , 由其执行具体的发布策略 。
除了独立部署的 Agent , 还可以采用以 Ansible 为代表的无代理的远程配置管理工具 , 以直接通过 SSH 协议对服务节点进行发布操作管理 。 使用 Ansible 的最大好处是 , 不需要在服务节点上部署 Agent 程序 , 减少了 Agent 带来的稳定性风险 , 降低了整体维护成本 。
不论是 Agent , 还是远程配置管理工具 , 在服务发布上基本都遵循相似的步骤 。


推荐阅读