请问你们是如何实现服务不中断的代码发布更新的

[brader]

目前我知道的一个自动化的方式就是 k8s 的滚动更新。

大家实际生产中，应该不是每个人都有使用 k8s 吧？
像你们 java 、go 这些语言，发布新版本的时候，如果不用 k8s ，你们是怎么实现平滑更新过度的，还是直接暴力重启？

[Features]

@tmtstudio PHP 是会受到影响的，高并发场景一堆的 502

[whileFalse]

你有负载均衡器吧！

[Ericcccccccc]

我估计你想找的是 服务发现, 搞明白了这个以及相关问题滚动发布就差不多解决了.

[cdlnls]

用 docker swarm / service ，比 k8s 简单，方便管理多个节点。发布也是滚动更新。

[lincanbin]

@samun 那就等他跑完了再发布啊，这种发布工具很容易设计的。

[runze]

@brader #31 APISIX 之类的网关适合这个场景

[daysv]

问题在于你们运行 DDL DML 怎么实现两个服务无缝切换的? 是搞了两套库吗?

[xiaowoniukai]

apisix

[samun]

@lincanbin 要搞成自动化这就是一个不确定因素了

[hhjswf]

@pengtdyd 搞不中断部署就是为了不在半夜部署啊。。

[hhjswf]

@brader 你们业务量不够吧，单表数据亿为单位，你修改表结构会锁表很长时间，这段时间怎么代码层怎么处理这张表 crud ？还是要通过数据库集群做

[dreamusername]

微服务间调用有服务发现，不论是 nacos 类的还是 kubernetes service 类的，这样保证服务间调用可以访问到可用服务；
服务需要有优雅退出，这样保证任务执行完毕后退出，防止任务中断。
对外服务，一般为 API 类，有负载均衡，服务在异常状态不路由流量（未就绪、退出等状态）保证用户访问到可用节点。

[chrosing]

我们是搞到预发 也和楼上说的两个环境类似。 预发和正式都是同一个库 先更新到预发 然后引导流量慢慢迁移过来 测试没有问题后 在同步服务到正式 然后进行更新 再之后服务完全没问题 流量再引导过去

[bushenx]

项目背景 基于 grpc 的后端业务
1. 必不可少的就是服务需要支持优雅退出，现在项目用到得 grpc 框架流支持。
2. 对于无状态服务直接发布一个新节点，将旧节点从注册中心移除就可以了。
3. 有状态服务我们采用主备机的方式发布新版本。

[lincanbin]

@samun 所以说服务开发要同意框架，框架要跟运维系统打通。
这种耗时操作在框架里挂钩子，执行完框架通知运维系统就完全打通了。

[brader]

@hhjswf 这个就要具体情况具体分析了，即使你的项目非常庞大、访问量非常多，那么也不太可能出现你一个项目的所有表都是很大数据量的情况，所以只是偶尔会接到需要更新这种表的需求，以下两种方案我都在生产中实践过并取得成功：
方案一：在低峰期更新表结构（看自己的项目情况，像我们在 22 点-05 点都是低峰期）
方案二：copy 出一张新表并改好新表结构，然后 insert 新表，（ insert 新表，rename 旧表，rename 新表）,注意前面有 2 个 insert 过程，第一次 insert 完看下最大 id ，然后这就是第二次的条件，分 2 次 insert 是因为第一次 insert 数据量大，耗时久，后续又产生了很多增量数据。

[brader]

@daysv 我日常的做法是分 2 步走，代码发布前，先更新表结构，思考做前后兼容的变动（实在实现不了的另做打算，很少这种情况吧），新代码里也做版本控制判断，这样我新旧版本都不影响

[hhjswf]

@brader 方案二你只考虑 insert 吗？有没有可能第二次 insert 期间，系统对第一次 insert 的记录进行删改操作，能同步过去吗

[brader]

@hhjswf 首先不排除这个可能，因为每人的业务情况不同，对于我来说，几乎没有这样的烦恼，因为第一次 insert 的一般是时间比较靠前的历史数据，不会变动，第二次的近期数据，因为操作时间非常短暂，出现概率就低。
如果你的业务对历史操作频繁，或者其他不适用情况，就建议你晚上更新，要求强一致就和领导申请锁写。
没有一套能解决所有问题的一成不变的方案，在于你怎么灵活应用和变通。

还有你们有使用阿里云的 RDS 、收费版 DMS 的话，建议把他们的工具利用起来，他们有个无锁变更功能还是很强大的，阿里介绍的实现原理大概就是 建新表->追全量->追期间变动的 binlog ，全程自动化透明，我们只要递交变更任务就好