感谢光老师的无私奉献~
1. 参考网址：
https://cloud.tencent.com/developer/article/1598403 微服务 | 推荐几种最佳「发布」实践方式
https://zhuanlan.zhihu.com/p/344513722 通俗易懂的微服务架构详解
https://cloud.tencent.com/developer/article/2143853 微服务的部署与发布：持续交付与持续部署微服务
https://blog.csdn.net/longlongriver/article/details/106941038 搞定微服务线上生命周期管理，同时发布上千个服务节点不是事儿
2. 常见的成熟发布方式有蓝绿部署、红黑部署、灰度发布（金丝雀发布）、滚动发布；其他发布方式有功能开关、A/B测试、影子测试。
3. 总结：
如果运维自动化能力储备不够，肯定是越简单越好，建议蓝绿发布；
如果业务对用户依赖很强，建议灰度发布；
如果是 K8S 平台，滚动更新是现成的方案，建议先直接使用。
关键词：负载均衡、集群、微服务、部署、发布、监控、其他（连续性、稳定，对外界无感知）
一、常见的成熟发布方式
蓝绿部署（Blue-green Deployment）
红黑部署（Red-black Deployment）—— Netflix
灰度发布（金丝雀发布）（Gray Release 或 Dark Launch）
滚动发布（Rolling Update）
1.1 蓝绿部署
概述：
2 个集群 AB，A 提供服务；
部署时，先部署 B 集群，验证通过后，将流量切到 B 集群；
部署 A 集群，确保验证通过；
可选操作：切回 A 集群；
优缺点：
优点：简单、稳定、平滑。追求稳定的可以用此方式
缺点：需要 2 倍资源部署服务，资源成本较高
1.2 红黑部署
红黑部署是Netflix采用的部署手段，Netflix的主要基础设施是在AWS上，它与蓝绿部署类似，红黑部署也是通过两个集群完成软件版本的升级。
当前提供服务的所有机器都运行在红色集群 A 中，当需要发布新版本的时候，具体流程是这样的：
先在云上申请一个黑色集群 B，在 B 上部署新版本的服务；
等到 B 升级完成后，我们一次性地把负载均衡全部指向 B；
把 A 集群从负载均衡列表中删除，并释放集群 A 中所有机器。
这样就完成了一个版本的升级。
可以看到，与蓝绿部署相比，红黑部署只不过是充分利用了云计算的弹性伸缩优势，从而获得了两个收益：一是，简化了流程；二是，避免了在升级的过程中，由于只有一半的服务器提供服务，而可能导致的系统过载问题。
1.3 灰度发布（金丝雀发布）——增量发布方法
新旧版本同时存在，由客户流量进行业务验证，没问题则逐步更新。
概述：
1 个集群的一小部分机器上先部署新版本，给一部分用户使用，以测试新版本的功能和性能；
确认没有问题之后，再对整个集群进行升级。
优缺点：
优点：如果前期出问题影响范围很小，相对用户体验也少；可以做到及时发现、及时调整问题，影响范围可控
缺点：对自动化以及运维监控能力的要求非常高。
1.4 滚动发布
滚动发布是指每次只升级一个或多个服务，升级完成后加入生产环境，不断执行这个过程，直到集群中的全部旧版本升级新版本。
红色：正在更新的实例
蓝色：更新完成并加入集群的实例
绿色：正在运行的实例
概述：
1 个集群的一小部分机器上先部署新版本，给一部分用户使用，以测试新版本的功能和性能；
确认没有问题之后，再对整个集群进行升级。
优缺点：
优点：更加节约资源
缺点：回滚复杂、困难，但是如果有平台管理例如 K8S，就不是问题
二、其他发布方式
功能开关（Feature Flag/Toggle/Switch）
A/B测试
影子测试
2.1 功能开关
概述：
同一套代码，存在新旧老套逻辑，通过功能开关控制，类似于 if、else；
在配置中心中打开开关，用流量验证，如果没问题，则发布成功，有问题则回退，关闭开关
优缺点：
优点：简单、快速，无需复杂的运维操作和能力
缺点：对用户有影响，代码侵入，需要回收老代码
2.2 A/B测试
原来主要用于产品功能的比对测试，收集用户反馈和对比数据做产品功能设计的决策
注意：需要负载均衡器（LB）具有通过某种方式分发流量的功能，将其中一种流量发到目的集群
概述：
2 个集群 AB，A 提供服务；
部署时，先部署 B 集群，将其中一种流量（例如 Web 端和手机端中的一种）切到 B 集群；
可以内部验证 B 集群通过后，再开放给外部用户访问；
可选操作：切回 A 集群；
优缺点：
优点：对用户影响小，可以做到针对某类特定目标用户进行测试；
缺点：搭建复杂度相对高，有一定技术门槛
2.3 影子测试
关键词：模拟生产环境，流量回放，结果对比
概述：
目标实现老的legacy服务迁移升级到新的experimental服务。
测试开始前，需要在测试环境部署一份legacy服务和experimental服务，同时将生产数据库复制两份到测试环境。同时需要将生产请求日志收集起来，一般可以通过kafka队列收集，然后通过类似goreplay[附录7.8]这样的工具，消费kafka里头的请求日志，复制回放，将请求分发到legacy服务和experimental服务，收到响应后进行比对，如果所有响应比对成功，则可以认为legacy服务和experimental服务在功能逻辑上是等价的；如果有响应比对失败，则认为两者在功能逻辑上不等价，需要修复experimental并重新进行影子测试，直到全部比对成功。根据系统复杂度和关键性不同，比对测试时间短的可能需要几周，长的可达半年之久。
影子测试因为旁路在独立测试环境中进行，可以对生产流量完全无影响。
影子测试一般适用于遗留系统的等价重构迁移，例如.net转java，或者sqlserver数据库升级为mysql数据库，且外部依赖不能太多，否则需要开发很多mock，测试部署成本会很高，且比对测试更加复杂和不稳定。
当当网有一个比较成功的交易系统.net转java迁移项目[附录7.9]，采用了影子测试技术，值得参考借鉴。
优缺点：
优点：
对生产用户体验完全无影响
可以使用生产真实流量进行测试（复制比对）
缺点：
搭建复杂度很高，技术门槛高，数据库的导出复制是难点
外部依赖不能太多，否则测试部署成本很高，且比对测试更加复杂和不稳定