前言
大家都知道项目一般由下面几个过程，给出需求->讨论需求->产品经理制作原型图->讨论原型图->修改原型图->确定原型->产品经理提供设计图和验收标准->确定业务->技术经理(架构师)提供技术方案，其中包括技术选型和基础架构设计，测试去编写测试用例，项目发布当前阶段一般是持续集成部署 jekins+gitlab+docker+harbor或者是rancher,大型互联网公司会采用k8s方案，并且通过k8s做蓝绿部署。项目发布技术和流程一直在进步优化，鄙人最早接触的是 servlet+tomcat通过tomcat或者其他的web服务器部署，当时还没用到spring框架，接下来就是 spring+mybatis/hibernate+springmvc/struts2当时用strtus2的同学对struts2的漏洞应该还有所印象，下一个阶段就是我们这几年主流的springBoot+mybatis/jpa/mybatis-plus这时候开始使用嵌入式容器，这时候已经不用再独立部署web容器了。此时也有公司初步引进docker和持续集成，在后面就是当前阶段，绝大多数公司开始采用 springcloud，无视业务复杂度，无论项目性能要求如何，无论人员配置什么样的，但是这些还只是传统的部署即使引入了cicd也只是传统部署方式，如果要进行项目部署还是要晚上部署，因为怕影响用户使用，基于这些情况蓝绿部署，灰度发布(金丝雀发布)，滚动发布等概念。目前业内主要灰度发布主要框架 Nepxion Discovery github.com/Nepxion/Dis…
灰度发布
灰度发布，一部分用户使用稳定的系统一部分用使用新的系统，比较平滑。我们可以设置20%的流量到灰度服务，80%的服务仍到稳定系统
缺点
1.自动化要求高
优点
1.保证整体系统稳定性，灰度初期可以发现、调整问题，影响范围可控； 3.用户无感知，平滑过渡。
蓝绿发布
蓝绿部署中，一共有两套系统：一套是正在提供服务系统，为“绿色”；另一套是准备发布的系统，为“蓝色”。两套系统都是功能完善的，并且正在运行的系统，只是系统版本和对外服务情况不同。 项目发布逻辑分为蓝绿组，发布新的系统时候要把蓝组的系统流量切换到绿组，如果绿组提供的服务没有出现问题，则把蓝组的服务也升级成绿组，反之，立刻把蓝组流量切换到绿组
缺点
- 若出现问题影响范围比较大
- 需要资源倍增
优点
- 用户无感
- 升级回滚速度比较快
- 发布策略简单
