1、假设我们的客户端App现在在市场上流通的版本是1.0.0，现在的布署图如下：

2、我们的版本规划是，下个发布版本是2.0.0。

3、通过一段时间的开发，现在我们2.0.0版本已经开发完成，测试和iOS审核过程中的布署图如下：

在这个时候，我们一定要确保，只有用户的操作系统是iOS和客户端版本是2.0.0的请求才能访问2.0.0服务。

这时候，我们的1.0.0版本的服务仍然在运行，市面上的用户仍然使用1.0.0的服务， 但是iOS审核人员用的是我们提交的2.0.0版本，他用的服务就是新的2.0.0的服务，并且只有他用的是这个新服务。 这就是灰度发布的策略。

4、当iOS审核通过后，我们可以继续采用灰度发布的策略，也可以采用让用户强制更新的策略， 下面是让用户强制更新的策略的布署图：

这时候，我们通过修改Ngnix的配置文件，将1.0.0服务切断（最好再运行一段时间服务，不要直接关闭服务，以避免出现问题后重新启动）， 切断1.0.0服务后，所有的用户只能连接到2.0.0服务了，这时候服务端发现客户端的版本是1.0.0就强制要求用户升级， 客户端会弹出强制升级的弹出框，不升级就用不了，所以用户只能升级到2.0.0版本。

4、最终的布署图如下：

到此为止2.0.0版本就全部升级完成了。