这是我参与「第五届青训营 」伴学笔记创作活动的第 11 天
前言
再学习了微服务的注册下线大致流程后，今天学习了微服务核心服务的发部方式和一些发布方法
服务发布
服务发布(deployment)，即指让一个服务升级运行新的代码的过程。即假设当前服务运行的是以前的代码，此时让当前服务运行新编写的代码，这个过程就叫服务发布。
服务发布的难点
服务不可用： 当下游服务故障或者停止运行时，上游服务无法调用，也会出现故障
服务抖动： 但部分实例需要进行维护或者更新时，该部分实例不可用，上游如何处理
服务回滚： 大量实例在更新后，功能出现故障，这时需要进行回退
服务发布的方法
蓝绿部署
1、部署过程：
（1）准备两个相同的应用运行环境，命名为蓝色环境、绿色环境，刚开始，蓝色环境和绿色环境都运行着相同的应用版本V1，只有绿色环境对外提供服务。
（2）我们开发了一个新版本V2，那么放到蓝色环境上进行反复的测试、修改、验证，确定达到上线标准后，将对外服务切换为蓝色环境。
（3）一段时间后，如果发生故障，那么迅速切换回绿色环境V1；如果运行没有异常，那么绿色环境更新版本到V2，版本再次一致。
（4）当需要开发下一个版本V3，重复前面的步骤，蓝色绿色相互切换相互备份。
2、特点
1）蓝绿部署无需停机，并且风险较小。
2）蓝绿部署要求在升级过程中，同时运行两套程序，对硬件的要求就是日常所需的二倍，比如日常运行时，需要10台服务器支撑业务，那么使用蓝绿部署，你就需要购置二十台服务器。
灰度发布（金丝雀发布）
- 准备好部署各个阶段的工件，包括：构建工件，测试脚本，配置文件和部署清单文件。
- 从负载均衡列表中移除掉“金丝雀”服务器。
- 升级“金丝雀”应用（排掉原有流量并进行部署）。
- 对应用进行自动化测试。
- 将“金丝雀”服务器重新添加到负载均衡列表中（连通性和健康检查）。
- 如果“金丝雀”在线使用测试成功，升级剩余的其他服务器。（否则就回滚）
在灰度发布开始后，先启动一个新版本应用，但是并不直接将流量切过来，而是测试人员对新版本进行线上测试，启动的这个新版本应用，就是我们的金丝雀。如果没有问题，那么可以将少量的用户流量导入到新版本上，然后再对新版本做运行状态观察，收集各种运行时数据，如果此时对新旧版本做各种数据对比，就是所谓的A/B测试。
当确认新版本运行良好后，再逐步将更多的流量导入到新版本上，在此期间，还可以不断地调整新旧两个版本的运行的服务器副本数量，以使得新版本能够承受越来越大的流量压力。直到将100%的流量都切换到新版本上，最后关闭剩下的老版本服务，完成灰度发布。
总结
这几种发布方法学习下拉，我认为灰度发布对整个系统的影响最小，可控，但是操作十分复杂，需要我们去权衡
