停机部署
将所有服务全部停止，并上线所有新的服务，此时需要确保服务已经经过测试，验证。
优点：部署方式简单，不需要考虑系统切换带来的兼容问题。但需要考虑停机更新的时间。
缺点：一旦新版本出现问题，需要立刻停止新版本，重启旧版本，所以最好在测试环境经过多次测试之后再上线。
场景：适用于线上调用不频繁，允许停机更新的服务
滚动部署
①先发布一部分服务，让它与旧版本共同对外提供服务
②如果新版本的服务没有任何问题，逐次将剩余旧版本停掉，换成新版本。
③如果新版本有问题，会根据容错机制自动调用其他版本（包括旧版本），可以继续对外提供服务。
优点：发布时间停顿较短；节约资源；即使新版本出现问题也对线上用户影响较小。
缺点：由于需要逐步更新，部署时间更长；回滚困难，如果新版本不能使用，需要逐步淘汰，此时需要了解集群服务部署情况依次处理。新旧版本在同一系统内使用，可能会出现兼容性问题。
场景：适用于系统小功能升级，并不会涉及到服务架构方面的变动。
蓝绿部署
分别搭建两套系统，旧版本使用绿色代表，新版本使用蓝色代表。
①蓝色系统先不提供服务，用来做发布前测试，测试过程中发现任何问题，可以直接在蓝色系统上修改，不干扰用户正在使用的系统。
②蓝色系统经过反复的测试、修改、验证，确定达到上线标准之后，直接将用户切换到蓝色系统, 切换后的一段时间内，依旧是蓝绿两套系统并存，但是用户访问的已经是蓝色系统。这段时间内观察蓝色系统（新系统）工作状态，如果出现问题，直接切换回绿色系统。
③当对外提供服务的蓝色系统工作确定正常，绿色系统已经不再需要的时候，蓝色系统正式成为对外提供服务系统，成为新的绿色系统。原先的绿色系统可以销毁，将资源释放出来，用于部署下一个蓝色系统。
优点：减少发布时的中断时间，可以实现服务无缝迁移；回滚简单
缺点：需要搭建两套基本相同的环境，技术复杂性高；如果设计服务架构之间的变更，可能会导致服务部署的复杂性；如果数据库较大的变动，服务切换之后，数据之间的同步/回滚也是需要考虑的问题；如果一个系统配置变更，需要确保另一个系统有相同的变化。
场景：适用于停机时间较短，但是服务架构，接口，页面功能改动较大的场景。
金丝雀部署（灰度发布）
在蓝绿发布的基础上，提高系统的
①同时将一部分用户负载至新版本，其余用户继续使用旧版本。或者将为新版本设置较低的权重，控制并发流量，将一部分请求负载至新系统。
②如果发现问题，也只是影响了一部分用户，同时还可以接收用户的反馈，修复可能存在的bug。
③如果没有问题，逐步提高新系统的权重，实现平滑过渡。
优点：系统可用性最强；发布停顿时间与蓝绿发布基本一致；可以收集用户反馈提升系统可靠性和易用性
缺点：需要定义好用户/流量切入的权重
场景：适用于线上调用非常频繁。
