计算巢支持对服务实例进行升级操作，服务商在修复之前版本服务存在问题，或有新功能发布时，可以发布新版本的服务。新版本服务发布后，用户可以按需将低版本服务创建的服务实例进行升级，升级后的服务实例可以使用新版本服务的功能。
服务升级原理
服务升级目前支持两种升级方式资源栈升级和应用升级，下面分别介绍具体的实现原理。
资源栈升级
计算巢创建服务实例时，主要依赖服务模板（Ros模板）进行资源栈创建，进行服务升级时，资源栈升级会按要升级服务版本的Ros模板进行对应资源栈的更新，可以同时实现云资源和软件应用的升级。这种升级方式只需定义好不同版本的服务，升级时会对比两个服务版本对应的Ros模板差异，进行对应的更新操作。
下面以一个例子来说明资源栈的升级过程，假设一个服务有两个版本，版本1服务模板定义包括资源A、B、C，版本2服务模板定义包括资源A、B、D， 其中资源A的定义完全不变，资源B属性发生变化，升级过程如下图所示。
结合上图，对资源栈升级规则进行总结如下：
新老模板中完全一致的资源，保持不变，例如资源A
新老模板资源名称相同，但属性发生变化的资源，进行更新操作，例如资源B
老模板存在，新模板不存在的资源，进行删除操作，例如资源C
新模板中存在，老模板中不存在的资源，进行新建操作，例如资源D
应用升级
应用升级通过OOS来进行，是通过在服务实例ECS资源上执行脚本命令，更换ECS镜像、更换软件包等方式进行升级，这种方式不是直接在资源栈上进行修改，而是以运维操作的方式，对服务实例中的软件应用进行升级。该方式只适用于软件应用的升级，且只适用于ECS部署场景，不适用ACK部署场景。
应用升级需要用户对新老服务版本进行diff，配置要做的升级动作，通过在原有服务实例上执行配置好的OOS升级动作，达到升级的目的，这样整体配置会复杂一些。
由于应用升级不是在资源栈上进行升级操作，资源栈对此并无感知，这时候在资源栈上执行其它更新操作，这个升级动作可能会被覆盖。因此，应用升级目前不推荐使用，建议使用资源栈升级。
服务升级规则
升级时，要升级的版本要支持当前服务实例的服务版本进行升级才可以
低版本只能往高版本进行升级
服务商自己同账号（发布服务账号和创建服务实例账号相同）测试时可以将其它版本升级到draft版本、beta版本
draft版本认为是最新版本，不能再向上升级
beta版本从逻辑上应该认为第二新的版本，可以升级到draft，已发布版本也可以升级到beta版本
服务升级操作
服务实例升级支持单个升级和批量升级，具体操作参见 升级服务实例：
单个升级：在服务实例页面进行升级操作
批量升级：在服务详情页面运维管理页面进行升级
服务回滚
服务回滚可以认为是服务升级的反向操作，将服务实例从高版本回滚到低版本，回滚只支持回滚到上一个版本，可以通过服务升级历史查看可以回滚到的版本。