微服务升级
微服务升级应该考虑下面几个问题:
- 如何确保整个升级过程中微服务可用,即服务不中断;
- 如何确保微服务的新版本可用;
- 如何实现升级出现问题时快速回滚;
滚动升级
滚动升级是在微服务不下线的前提下对微服务的版本进行升级,整个升级过程中微服务可用。滚动升级适用于需要定期对微服务进行更新升级的场景。
升级过程中Deployment同时维护版本V1和V2。版本V1的数量不断减少,而版本V2的数量不断增加,直到版本V1的数量为0。
滚动升级的优点是整个升级过程只需要增加很少硬件资源(25%)。但由于滚动升级过程中,对微服务的访问有可能被新服务或老服务处理,不能对调用的新旧服务进行指定,升级过程中会出现不一致现象。同时,如果升级过程中出现问题,不能确认是新服务的问题还是就服务的问题。
灰度发布
灰度发布是指在发布新版本微服务过程中同时维护2个版本,将服务访问按照流量权重或规则分发到新老服务。灰度发布能够在服务升级过程中检测新服务是否可用,对比新旧服务质量,并能指定新旧服务的比例。
金丝雀发布为灰度发布的一种。服务升级之前,先启动一个新服务实例并将少量访问流量导向新服务,查看新服务的反馈来决定是否升级。