分享人: 游圣，阿里云资深技术专家
正文：
作为一款云上架构设计利器，云速搭CADT可以快速构建应用架构，自动化部署资源，轻松实现对云上架构的生命周期管理，是云时代强有力的生产力工具。本篇内容将从5个部分为读者介绍关于CADT的一些不得不知道的特性，希望可以让大家对CADT有更深入的了解，并可以将这些特性应用到项目中，达到降本提效的目的。
Ÿ 用户使用云服务的小挑战
Ÿ 云时代的生产力工具
Ÿ 零代码架构设计利器
Ÿ 加速架构构思到部署
Ÿ 架构图与生产环境的准确映射
一、用户使用云服务的小挑战
很多客户现在已经慢慢从线下向云做一些转型，在转型过程中我们不可避免地会使用到各种各样的云服务的产品，在使用产品中确实遇到了一些挑战。以下图左边为例，这些是我们阿里云上产品的一些分类，云产品的大类有计算、存储、安全、数据库、大数据、人工智能、网络，是非常丰富的。如果打开弹性计算，里面还会有ECS，GPU、神龙RPG、专业速读机DTH等丰富的云产品。
l 对用户来讲，阿里云提供了大量的云服务产品，将这些云服务配置成客户的应用架构是需要一定的专业知识的。
l 这些云资源如计算、支付、网络分散在不同的云服务中，很难从一个应用架构的角度来进行资源的配置、管理、开通，因为它是一个散点状图。
l 在使用这些丰富产品的时候，会遇到人才短缺的问题，因为现在做云服务的人的成本比较高。所以在缺人的情况下，很难去了解一些架构是如何进行部署的。虽然通过各种各样的分享，或者在网上看到的很多文章里也会有一些部署的架构图，但我们无法得知其中的细节，而且示例的架构图到真正的部署，中间还存在很大的gap。
l 从客户角度来讲，比如部署一个应用，一个OA，一个财务或者ERP，其实每一个应用是一个系统，里面可能都含有网络、计算、存储、数据库，那如何从这些独立的应用系统来看应用中包含的这些资源的健康度？这是有难度的。
l 刚才我们提到的这些，比如一个企业内可能有OA系统，ERP，还有财务，那整个系统在部署之前应该怎么去核算成本呢？
这些难点也是我们在设计这个产品之初要去解决的。
二、云时代的生产力工具
我们把云速搭定义成云时代的生产力工具。为什么这么说？
l 云速搭可以帮助中小企业在缺少架构师支持的情况下，利用一些模板或者做一些简单的学习，通过自助服务的方式使用阿里云服务。
l 提供丰富的云应用模板。通过模板可以做复杂的调整。对于架构师来讲，他可以不断的构筑自己的模板库，然后在遇到一些需要交付的项目中，可以根据自已的模板库和业务场景，快速的找出适用的架构。
l 在部署之前，我们可以通过工具快速计算出使用不同的规格、不同的服务模式的总体成本，这样可以快速支持项目的一些决策。
l 在部署过程中，可以不断的去增加我们云服务的产品，可以增删，在整个架构的演进过程中，架构师的工作量以及学习成本是显著降低的。
l 作为生产力工具，它涵盖了整个应用架构中的一些设计、构建、成本核算到最终交付。
三、零代码架构设计利器
CADT面向的是系统架构师，定义为零代码架构设计。
1、 所有的设计工作是基于网页的方式web图形界面完成的，所见即所得，可以去展现阿里云方案的整个架构，看到的架构和部署的架构是一致的。
2、 使用门槛比较低，无需学习任何脚本语言，几乎没有学习成本。
3、 在云产品使用中，你可能会去学习一些SAP，对阿里云的基础产品做些了解，这样我们就可以做一些架构设计了。利用标准化的模板，可以减少错误的使用方式，减少售后的沟通。通过CADT部署生产系统之前，我们也可以拿相同模板，比如使用后付费方式即按量付费，可以快速进行PoC验证。验证成功以后，我们就可以拿它来进行生产级部署，效率非常高。
4、 预制模板有非常多的分类，主要有我们团队的最佳实践的模板，同时官网有很多产品页，比如数据库、存储，计算等。产品页中有非常多的架构模板都可以用来复用。
5、 支持私有模板的定向分享。比如一个架构师的公司在北京，但是客户有可能在广州或者广西，在对客户的需求了解清楚以后，就可以远程进行整体的架构设计。架构设计完成并经过验证以后，可以直接定向分享给客户，让客户在他自己的账号中就可以去完成部署，所以也叫做空中架构师。
四、加速架构构思到部署
下面介绍加速架构构思到部署中间的环节。
第一，应用在部署之前，要先去了解应用对系统资源的要求。比如我们要部署一个SAP系统，它对计算、存储、网络、安全、数据库、大数据等会有一些系统性的要求，需要特别的规格。
第二，进行架构设计，可以通过CADT进行。
第三，系统规划。
第四，选择匹配的云产品，
第五，选择特别的规格，不同的区域，需要做库存确认。因为在不同的region，附属的产品不同。我们需要做一个全流程的校验，确认在当前所规划的架构图对应的区域，是否可以购买到。
第六，看下整体架构成本是否符合预期。
第七，进行加工部署。
整个流程如果是手动的方式，需要一定的时间，一般情况下可能一到两周。使用CADT，所见即所得，效率可以得到至少10倍的提升，一般只需要0.5-1天的时间。
五、架构图与生产环境的准确映射
CADT实现的是架构图与生产环境的准确映射。为什么这么讲？
下面看下当前的传统模式和使用CADT之后的对比：
1、 在绘制架构图时，可能使用收费的软件或者免费的绘制工具进行架构设计，和实际的部署一定是脱节的；使用云速搭，设计的架构图就是自己所部署的。目前已支持80+阿里云服务产品。
2、 受Region售卖的限制，设计时的资源与购买的资源是不同的。对架构师来讲，对库存可能是不太清楚的，只能在控制台上挨个查，效率是非常低的；通过云速搭，设计时对应的控制区，选择对应的Region 和AZ之后，购买的资源会在清单中清晰的列出，能确保设计与购买的资源是一致的。
3、 成本核算传统方式，架构师需要做一个有规格的配置表，然后再去控制台上查询相应的价格，形成配置报价单；在云速搭上，我们可以根据设计的规格、付费方式，可以一键式的进行整体测算。同时支持导出，方便架构师进行预算申报。
4、 在云产品的一些使用中存在一定的依赖性，比如ECS，通常会挂在SRB的后端；从数据库来讲，计算前端依赖ECS。这些依赖的关系实际上是依赖于架构师的经验。如果是一个错误的架构，类比如说SRB绑定RDS，在正常的生产环境正中是不应该出现的；在云速搭中，我们会把相对的依赖关系做相应的处理。对依赖关系做一些防代设计，即资源跟它连接的关系是要做相应的判断的，比如ECS一定是要放在vSwich里，不能放在Region级。因为它跟虚拟交换机有关联关系，SRB在连接ECS时，后端的监听会自动配置。
5、 一个生产系统一旦上线之后，随着时间的推移，会不断地买服务器，不断地补一些新的系统，上一些新的架构机。如果没有比较好CMDB，后面很难去做跟踪在什么时间段，上了什么新的应用，新的设备。在云上也存在相应的难点。这些服务资源如果在用了两到三年后，企业在不断的发展，需要不断地增加新的应用，最终可能看到的是一笔糊涂账，会有非常多的ECS、交换机、VBC等。中间的逻辑关系可能依赖于过去每上一个系统之前的那些架构图，这些图和应用部署实际上是脱节的。再加上人员流动，对于接手的同学来讲可能就是一笔糊涂账，很难去做一些清晰的梳理，而这个梳理也是非常耗时间的；如果通过云速搭来做，即架构部署以后，在原来的架构之上部署新的资源的时，或者去删除一些资源的时，这上面会有一个形成新的反应管理。同时对一个企业来讲，如果不同的应用之间没有依赖关系，那应用可以进行独立部署。比如部署一套OA系统或者一套独立的财务系统，或者说有些游戏客户，每一个游戏服务属于单一化的部署，可以按照一个单元的方式来进行独立部署，将来在做运维和维护的时候也非常的清晰和简单。