应用场景

游戏单元化批量开服

在游戏场景中，往往会有一套标准的扩容流程来应对游戏用户的增长，每次扩容都有一套标准的基础设施部署配置过程，例如：

• 一组扩容包含5台ECS，部署在固定的网络及安全组中，每个ECS绑定NAT网关，配置DNAT/SNAT规则， EIP关联NAT 网关，EIP绑定共享带宽包。

• 上述架构需要部署在全国多个地域，需要一套模板能复用到多个地域。

• 扩容后需要能够支持原地缩容，按部署单元进行资源下线，配置解绑等一系列动作。

这一系列标准流程统称为云基础设施部署及配置的自动化，CADT以可视化部署模板为基础，简化了部署模型的一系列代码化编排过程，通过在模型中定义几个关键的变量，支持每次部署可以选择不同的ECS规格，不同的服务端口，以及选择不同的部署地域，快速完成业务的扩容。当业务需求下降时，将整个部署应用进行整体释放完成资源下线动作。

通过CADT 命令工具进行基础设施的部署配置，大致流程如下：

• 每次扩容会单独配置一个YAML文件，在配置中指定部署的模板ID，指定部署地域，指定网络组件，指定此次扩容的关键变量。

• 通过CADT命令行cadt appy -f 2nd-Scale.yaml完成扩容，扩容后生成一个应用ID。

• 如需缩容，只需要对该应用ID执行释放操作即可，cadt release -a <APPID>。

统一云管API对接

从基础设施运维角度来看，当云资源量达到一定规模后，特别是拥有多个云账号体系，多朵云的情况下，建设一套统一的云管理平台是有必要的，在多个账号，多个云之间不停的切换来进行资源部署配置是极为低效的，且非常容易出现人为失误，统一的云资源调度平台可以大大减少运维工程师的工作量，让基础设施交付更加地自动化，而且统一之后可以对权限进行收敛，可以进行更多的资源管控，成本管控等，例如每个资源申请之时必须指定资源组或者标签，便于秋后算账；资源申请只固定几个常用规格，控制资源成本；固定几个可选的自定义镜像，保障部署环境的安全可靠。

统一的云管理平台建设从功能定位上实际是包罗万象的，其中核心的一块功能是资源生命周期管理。在这一块能力上，云速搭CADT API提供简单而且通用灵活的对接方案。核心能力包括模板和应用，模板以可视化设计完成建模，模板对应了一个重复交付的最小化场景，例如ECS，或者ECS+EIP，或者ECS+CLB监听。模板中可变的部分通常会定义成变量。 而应用则是模板变量传参后生成的一个可部署方案，应用可以直接进行校验询价以及部署。

使用CADT API 对接统一的云管平台主要有以下几个优势：

• 对开发者而言，无需每个云产品的参数进行详细了解，这部分由运维以及业务方通过CADT建模过程形成相对固定模板，并留下几个关键变量供后续传参即可。

• 对接的API大大减少，CADT API完全屏蔽了产品间的差异，提供一套标准的流程接口，开发者只需要将这些标准接口封装成一套通用引擎，通过不同模板+变量的传参即可完成资源生命周期对接。

• 一旦对接完CADT API的核心接口，后续无论是新增云产品，还是云产品的API发生了变更，都无需修改核心代码，通过模板的微调即可完成适配。

资源审批创建自动化

大部分企业客户在IT内部流程管理中均有资源申请和释放的规范，便于内部进行资源成本管控，但是基本上都没有实现自动化，例如资源申请环节只是简要写了申请需求，和实际的云产品规格并不匹配，有些也只是做个截图。需求没有细化容易造成在创建资源环境出现重复沟通，运维需要反复在流程外和需求方确认细节。

企业的工单流程和云的API打通实现自动化，目前仍是一个难题，主要体现在需求的多样性和云产品的多样性上。

• 需求多样性：需求方的诉求是多变的，按需定制开发是无止尽的事情，需要尽可能形成一套通用逻辑能够应对多变的需求。在多变的需求背后需要形成一个个资源模型，以模板为基础原型，叠加可变的参数变量来满足多样化的需求。例如业务方每次申请RDS都只考虑高可用版本，可以沉淀一个RDS 高可用部署模型，具体的mysql版本号，实例规格，容量等就是变量。

• 云产品的多样性：多变的需求背后是云产品的多样性，对接众多的云产品的api需要进行封装后才能和审批流程接口对接，一个统一接口是必须的。

CADT可以很好的满足上述两点需求，模板定义能力，统一的流程接口可以快速和现有流程对接，无缝集成。

• 模板：一旦申请流程对接了模板接口，将来新增的需求只需要对应添加模板即可，模板支持变量，动态支持传参。

• 统一接口：CADT屏蔽了各个云产品的接口差异性，提供一套机制应对资源创建&释放流程。