本次主题是通过ROS低代码CADT无代码和可视化能力管理云上基础设施。介绍使用基础设计代码和ROS的可视化编译器简化和加速云上架构的构建，分享分四个部分，首先简单介绍云上部署目前面临的一些挑战，然后介绍阿里云的自动化部署服务资源编排ROS，包括它的核心能力资源栈模板，还有Terraform托管，然后重点介绍ROS的可视化编译器，并且重点演示它的一些基本功能。最后将会讨论如何使用生成式人工智能来开发IaC模板。

 

一、云上部署挑战

首先讨论云上部署的一些挑战，在云上部署，如果使用手动部署的方式，将面临需要部署有依赖关系的多种云资源的时候，使用council或者API都非常耗时耗力，需要在不同的产品控制台和页面之间来回的切换，配置不同的地域和环境的时候，相同的资源缺少一键部署能力，缺少可复制性，在不同的环境里边配置相同的资源的时候，也很难保证一致性，很容易导致配置错误。将资源配置完成后。随着资源数量增加，使用控制台去管理云资源的时候也会变得越来越复杂。最后在整个部署环节中增加一些DevOps能力，很难在手动部署中增加版本控制，变更管理，并且无法实现敏捷的部署。

 

二、IaC自动化部署服务-ROS

业界和阿里云都推荐使用IaC来解决问题，作为一个解决方案架构师，首先会用规范化的模板文件，声明基础设施，并且通过版本管理和CI/CD来实现持续的维护。然后会将模板交给一个自动化部署服务，例如阿里云资源编排（ROS）来实现多地域、多账号的自动化部署。最后会交给IaC进行持续的基础设施维护，在业界已经出现很多IaC工具，如果按照服务类型的不同。

大概分为两类，一类是云厂商的服务，有代表性的是阿里云资源编排（ROS）还有AWS（CloudFormation） 以多云IaC为代表的是Terraform Community还有Pulumi。按照模版语言的方式不同分为两类，一类是声明式的IaC，IaC就是以特定的语言，比如JSON，YAML的方式描述基础设施，这是目前最为广泛的使用方式。还有一种方式，以Pulumi代表，使用编程语言的特性，例如函数、循环和变量描述基础设施，这可以带来更强的编排能力，但同时带来一些复杂性。

在阿里云目前推出的简单易用的云计算的自动化部署服务，即资源编排ROS，ROS有一些优点，首先相比较人工部署，作为一个自动化部署工具，它会有更高的效率。其次是使用模板的形式管理基础设施会带来标准化和一致性。标准化，一致性会降低部署成本和时间成本。同时标准化的一致性的流程也可以在流程中变得更加敏捷，并且对模板进行版本管理来实现基础设施的审计和回滚。

ROS的一些基本概念，例如ROS模板，它是一种可读性较强的JSON和YAML文件。作为一个典型的ROS模板，主要包含几个字段。首先是参数，参数就是定义资源架构中的公共变量和属性。资源则表示整个资源架构中所涉及的云资源和云资源之间的依赖关系，最后输出则是在将一个资源架构部署完成之后产生的一些信息，第二个概念是ROS的资源栈，ROS通过资源栈，部署和管理模板中的资源，这两张截图是一个典型的资源栈的详情页面，它包含着资源栈的基本信息是否删除保护，它的偏差状态，以及它的资源列表和资源的部署状态，还可以进行更改集合命令执行，同时的ROS也支持Terraform的云上托管，可以通过使用ROS来简化Terraform的管理，使用ROS云上托管，可以带来一致的控制台体验，并且兼容ROS原生API统一的身份认证，权限控制，ROS同时支持多种provide和多个Terraform版本。接下来介绍两个ROS的客户案例。

首先第一个是计算巢，计算巢作为一个面向服务商的一站式上云的平台，它使用ROS和Terraform模板，定义客户应用的环境部署脚本和应用部署脚本，通过这种方式，将服务商的应用部署效率从天别提高到小时级别和分钟级别。

第二个是钉钉，在疫情期间，钉钉作为企业首选的在线办公软件，当时面临很大的扩容压力，需要在十天内实现50倍的扩容，面临这个问题，时间非常紧，并且整个配置会非常的复杂，ROS帮助钉钉提升非常大的效率，在半天时间内扩容了36万的vCPU，并且实现多地域、多可用区的规模化扩容。同时ROS也帮助钉钉部署多种云服务，实现灵活的容量管理和变更能力。

ROS作为一种IaC化部署服务的优势。有些什么问题？IaC模板编写,开始编写的时候需要几个小时，注意到整个模板编写是一件非常难的事情，有几个问题。首先是学习成本较高，需要学习一门新的语言去写IaC的模板。其次，很多的模板的参数属性是需要参照文档编写，其次就是每个架构师在编写的模板的过程中，脑海中都是以一个架构图存在的，但无法在编写模板的过程中实时的给脑海中的架构图关联起来，最后是在模板的属性上有很多的动态的属性值，例如实例的规格，它是和库存有关的，在编写的过程中无法确定这些动态的属性值，这个问题下面，整个业界提出很多的解决方案。

例如，有些厂商会提供一些编译器的插件帮助校验模板写的是否正确。还有会提出像CDK工具，使用编程语言写资源架构，然后通过CDK生成模板，这个典型的外部网络架构，一个ALB和2个ECS还有mysql，就要编写几百行甚至1000行的模板代码。在巨大模板代码面前，每一个编写的同学都会变得心惊胆战。

 

三、IaC可视化-ROS可视化编译器

ROS推出了可视化编译器，希望通过可视化的方式帮助客户加速和简化云基础设施的架构和迭代，无需手写IaC模板，它的主要的功能包含一个画布界面，在这个界面上，可以去拖拽资源进入画布，同时可以在画布上连接和配置云资源，最后可以在编译器上直接进行一站式的部署，接下来介绍编译器包含的一些功能。

首先，在编译器的画布上，可以在导航上选择模架构图的内容管理和它的版本管理，然后在左侧去选择资源类型，以及一些网络架构去拖拽到画布上，当拖拽到画布上之后，还可以点击云资源进行连线，编译器已经内置很多连线的约束规则，会保证你的连线正确，当连线完成之后，可以点击具体的云资源，在弹出的表单中设置云资源的属性，这个表单已经将默认的属性配置好，它会简化模板生成，在表单上也可以切换已经存在的一个已有资源，当配置完连线和表单之后，就可以在编译器的模板视图上查看刚才生成的IaC模版，同时也可以在模板的旁边去配置模板应该具备一些公共属性和参数。

最后到部署环节，当点击右上角的资源栈视图的时候，可以进入真正的部署环节，首先填写资源栈的一些参数，然后查看整个资源架构所涉及到的资源价格。最后点击部署按钮，实时的查看资源的部署状态、事件和进度，除从头开始搭建一个架构图模板之外，也可以选择导入一个已经存在的架构图模板。这个编译器将会自动的将架构图模板编译，自动布局，生成一个资源架构图。

接下来将演示如何搭建一个基于云服务器的外部网络经典架构，它包含着一个负载均衡，云服务器，还有EIP，首先进入编译器的界面，点击创建架构图模板，在左边可以看到编译器支持的所有资源。可以搜索或直接拖入，拖入一个单可用区网络，能够看到它默认生成一个架构图的基本网络架构，并且将VPC，还有VSwitch的网段和基本属性已经配置好，这里选择一个需要的可用区，紧接着需要两台云服务器，从左侧拖入进来，在拖入过程中发现编译器会自动的提醒对应的云资源应该拖到什么区域，简单调整，让两台ECS在同一个安全组内。

紧接着拖入负载均衡，并且适当的调整它的美观度。这里拖入一个新的弹性公网IP，接下来进行连线，希望两台ECS绑定到负载均衡之上，将弹性公网IP绑定到SLB之上，现在的架构图已经初具雏形，接下来需要做的是点击具体的云资源去配置想要的属性，可以看到云资源已经自动的将刚才连线产生的资源关系配置好，这里IP和SLB已经在资源属性上关联，这里配置SLB的可用区，看到后端服务器已经有两台云服务器的相关配置，监听中编译器已经自动的将一些默认的监听属性配置好，这里不做修改，紧接着看到两台云服务器的基本属性里面已经已经配置好，包含实例规格，镜像，点击右上角的模板的视图，可以查看刚才通过拖拽和表单生成的ROS模板，可以同时查看JSON和YAML两种格式的模板，并且可以选择复制或者下载。

当点击参数type的时候，能注意到架构图自动帮生成一个可用区的参数，但作为一个外部网络架构，希望两台运营服务器具备相同的实例规格，于是在这里点击提取参数，将第一个服务器的参数提取成一个新的参数，能够看到在参数上面已经出来新的ESC type参数，然后选择第二台实例，将值选为刚才提取的新的参数，现在两台云服务器将会引用相同的实例规格参数，点击参数看到一些基本信息。

现在已经基本做完配置，可以开始进行部署操作。首先进入创建资源栈的页面，在这个页面中。会看到刚才创建的实例规格的参数，这里选择一个想要的实例规格。点击下一步以后，开始进行询价，编译器会自动的将整个架构中所有的需要付费的资源自动进行询价，并且显示在这里。确认架构无误之后，继续点击下一步进行部署。在部署之前，它会自动保存成新的一个版本，以备以后查看，当部署开始的时候，在下方的事件栏会自动显示所有的资源的创建流程和它的创建状态。

同时左侧的架构图中，会显示资源的创建的状态和右侧是一致的。现在正在创建交换机和两个安全组，正在创建云服务器。云服务器和SLB的已经创建完成，紧接着会创建一些SLB和服务器的关联资源，整个资源栈已经完成，上面就是演示的使用编译器从零开始搭建外部网络架构，并且实现一键部署的整个过程。除使用编译器来人工拖拽来生成架构图之外,也可以选择使用生成式人工智能生成模板。

 

四、拥抱AIGC-利用生成式人工智能开发IaC模版

在AIGC生成的时代，肯定会想到是用AI生成代码，它和编译器如何结合。看下个演示。在编译器的右上角提供AI生成架构图的功能，这里可以输入最原始的需求，例如刚才的两个ECS的外部网络经典架构。首先告诉AI云架构师，需要两台云服务器，AI助手会自动生成完整的ROS模板以及对ROS模板的内容进行解释，同时在右侧会同步的生成架构图，接下来在右侧不断完善需求，比如希望两台ECS挂载到负载均衡之上，架构师会自动完善刚才生成的模板，并且在左侧架构图上自动进行连线。使用AI助手相比较直接使用基础大模型有两个优点。

首先如刚才演示的，这里是一种渐进式的修改，就是可以将AI生成和人工编写结合在一起，可以一边使用AI生成，一边使用人工，这样可以让整个生成变得更加自由。其次就是AI生成会和左侧的架构图结合在一起，在生成的过程中，可以随时检查AI生成架构图是否符合预期，第二个优点是相比较基础的大模型，AI的工具在背后接入更加准确的rag知识库，同时在整个的工作流中加入前置的错误检测和自动修复，保证整个生成会比技术大模型更加的准确，看到通过一步一步的修改，告诉大模型将整个的外部网络架构生成出来，在未来希望AI助手可以做到不仅能够像准确的一个架构需求完成它整个的构建，也可以完成一些模糊的、更具创新性的架构需求，并且可以在同样一个需求中提供不同的架构方案。

例如演示的一个外部网络的经典架构，使用云服务器或者使用Serverless的架构，并且分析不同架构的性能差异和成本估算。目前AI助手正在实验中，将会在未来不断去改进它，并且改进整个可视化编译器。希望给喜欢IaC并且需要写IaC模板的同学提供非常趁手的工具。

 

五、以架构图为中心

以架构图为中心，什么叫以架构图为中心？大家在很多时候只关注开资源，没有关注资源背后的逻辑，有的时候就会出现一些故障，以及会遇到一些问题，就是开资源的时候，资源和业务系统分布错误，举个最常见的例子。算力资源买在a孔区，数据库买在b孔区，SRB买在c孔区，通过代码做的时候是非常常见的。因为不知道库存，所有的云厂商都面临一个问题，在国内的机房规模不是超大体量的，所以可能不光是阿里云上，所有国内的云厂商都是一样的，比如在北京可能会超过十个孔区，因为它的机房空间是有限的，所以在做任何的架构的时候，既然有架构，就需要架构图，就像盖一个楼一样，比如工科出身的同学，可能盖一个平房是可以的，盖一层这房子基本上可以住的，但是要盖高楼，不是搞建筑出身的盖楼一定是没人敢进去的。

这个楼随时可能会塌，不知道它里面的整个建筑结构承重，这个叫术业有专攻。现在几乎所有的厂子在谈AI，未来是不是需要程序员，什么都可能会发生。所以写代码并不代表技术高深。要先有这个认识，但如果大家的技术寿命要更长，对业务的逻辑，还有部署要清楚，会更延长技术的生命。所以能盖高楼大厦的人，比如盖中国尊的人，中国一定不会很多的，如果中国想再盖另外一个中国尊，他能找的设计师一定是有限的，但是能盖普通的平房，盖棚子，这个人很多，这人的工资一定是不高的。所以盖楼需要图纸。那规模化的用云，需要可施工的施工图，施工图其实就是可交付的架构图，这是非常重要的。

第二个是在同地域的高可用的架构图，这是左右分布的，在这里所有的资源，比如算力资源是两个地域，两个AZ，数据库包括的对象存储全部都是冗余。看云资源的架构图对架构师的价值有哪些，为什么要在云上部署这个资源，一定不是运维团队手里有钱，而是来自需求，什么叫需求，业务商要去做一个电商或者要做出海，上面要布什么样的业务系统，这个叫需求，有需求以后，就会知道需要买多少云资源做估算，这些都来自于需求，用架构图可以做需求沟通，所以说在云上，没有做过云的真正的架构设计，最差的情况下会设一张草图，不是会写一些代码做需求沟通，一定要有架构草图，比如刚才其他的几个公司的分享，画一个架构的草图，但图和最终交付的是不是一样就不清楚，所以在这里看到整个系统的结构。

第二沟通的时候，如果现在给相关的代码，是没有兴趣看的。一定要先看架构图，在沟通的时候，通过架构图是更清晰的。第三架构图上买的什么地域，在哪个可用区，上下关系一清二楚，避免错误和冲突。第四要去做一个资源的交付，比如成熟的架构师要去看资源购买是不是合理，架构图是可以做购买支撑的，可能刚才看的是合并的代码，人员的流动在IT行业非常常见，很有可能变成孤品。孤品是架构图之前是人随意画的，给一段代码，过了几年，没有人知道整个系统现在什么样。变成孤品没人敢动。系统不能变，没人可以对它做任何的调优，需要架构来进行内容的传承。

看分享的0代码，不需要懂任何一行代码，这里能做几件事情，第一是设计,阿里云有很多的原厂的架构师，有伙伴的架构师。还有些客户没有架构师，比如一个小型的企业，比如个体户，或者是创业者，需要在云上去购买一些资源，这些人都可以通过可视化的工具做架构的设计，比如一个架构上百上千个资源，到一台云资源都是可以的。第二是原厂提供非常多的架构模板，可以在上面直接复用这些模板，如果不懂可以看别人怎么设计。copy是最容易的。

第三是设计完以后，可以快速的进行交付，交付资源后图纸化的资源是一模一样的，是一比一的交付，最后在交付之前，要去核算成本，比如资源大概多少钱，比如预算五万块钱，但设计的架构图上面资源可能超五万块钱。意味着账里的钱不够，要调整架构。所以任何资源在交付的时候，要核算成本。看现在支持的云产品的数量，现在支持云产品数量还是比较多的，所有阿里云上公共云的产品现在基本都支持，支持225款，未来会更多，所有公共云上在控制台上可以购买的，通过云速搭可以把它用架构的方式组合出来，看图，将复杂架构按图施工。其实这个架构图还是比较简单的，因为客户在用的时候架构非常复杂，图是一个券商的典型的行间系统，券商是可以在公共云上部署它的行情的，比如客户要在海外去做出海，比如现在服务比较多的车企。

以行情为例，行情系统化国内至少布三套，在北京、上海和深圳就是北交所，深交所和沪市上海交易所。券商的系统通常行情不是自己开发的，行情在国内有几个专供应商，供应商的架构其实差不多，就是一个外网的网关，下面会有非常多的端口的监听，下面会有非常多的连线，很多的连线就是逻辑的挂载，按图施工是在北京布一套，上海布一套，深圳布一套，架构是一样的，只需要改地域，改成对应的AZ，就可以在对应的地域进行单元化的交付。不同的地域，以交易量为例，沪市，深市肯定大于北交所。所以在北交所，它的规格，比如ECS的规格要比其他几个地域要小，因为也要考虑成本，所这就是复杂架构。

按图施工就是先有图，在施工的时候，孔区不是随意选的。以阿里云为例，在上海会有非常多的孔区，那哪个孔区离交易所最近？在行情系统里，机房必须要离交易所最近才可以，因为追求的是时间最短，可以通过网络同学告诉哪个孔区最近，但是它不见得有对应ECS的规格，库存能力这里有，判断在交付之前，地域能不能买到对应的ECS的资源，不要说把网络资源全买完，最后发现对应的孔区没有ECS。要跨孔区时间优势就没有。所以可能需资源的库存的校验，现在集成基本主流，所有的库存都已经集成。第二通过连线可以看到挂载关系。就是谁可以上外网。比如它的逻辑是不是错误，架构师要干这件事情，架构师要了解业务系统映射到资源，对于架构师来讲是非常有价值的，要对业务系统更清楚，这才是价值。第三个不需要关注里面的依赖关系，依赖关系在图上已经设计。在交付的时候，依赖关系的部署先后顺序是由软件云速搭自动实现。举个最简单的例子，要去交付ECS和数据库，要加一个白名单，意味着ECS要先创建出来，两个都创建完以后才能做挂载。

ECS的创建时间和数据库的创建时间是不一样的，ECS的创建时间是一分钟，比如poloDB，它的典型创建时间是十分钟，它是有先后顺序，创建完以后才能做挂载，逻辑是在里面自动实现的，引擎是自研的。

 

六、云速搭提供多种可视化架构图生成方式

还有另外一个能力，可以做多种云的架构的架构图的复原，很多人不知道架构图在云上怎么设计，那么云上大概提供400个模板，这个模板来自于哪里？一个是最佳实验团队提供，第二是有对应的解决方案团队，也会设计架构图。第三是由产品团队设计。所有人都可以看到里面有对应的配置，可以看里面是逻辑什么样子，配置什么样子，为什么云资源都不是免费的，开任何的资源都需要花钱，看一个存量的架构图，比如最近有非常多大的客户，在国内在海外用阿里云，不知道阿里云的架构图，不知道云上架构图，有个能力叫存量云资源，因为很多资源不管是通过IaC还是通过控制台开的，资源分布在整个控制台是平铺式的。中间逻辑关系没有。可以用资源探查的能力把架构图反向生成，不用人工去画，人工画一定是错的，没有一个客户的架构图是准的，因为有上百个资源的时候是搞不清楚的。以这个图为例，上面都是ECS，上面是网络都是搓堆的。上面其实都是归属于不同的AZ，归属于不同的交换机，在这上面知道上下的关系，这是阿里云提供的一方的产品，不需要提供任何的ASK，比如客户是几千个资源,体量非常大,一张图肯定放不下，放下也看不了。可以基于各种各样的过滤的规则，比如VPC，地域，资源组，安全组，基于这来进行过滤。比如有的客户的标签打的不错，想基于标签过滤，按标签把对应的标签的业务拿出来用，然后在整个逆向探查的时候，这个是业务无损的，通过配置审计，有些产品配置审计是没有的，通过API，因为是只读的方式获取，所以是百分之百无损的。这是阿里云的，现在有很多客户是多云的。只需要提供其他几朵云的只读的AKSK，现在支持的国际加上国内的四朵云，都可以做架构的反向生成，这是行业内独有的能力，每家支持大概30到40款产品。

根据国内的易购云的友商图，也能看出它整个的挂载关系，比如想往阿里云做搬迁的时候可能需要知道，需要先做盘点，过去手工拉出账单，方式很慢，效率很低，而且里面的挂载关系，需要先提前排查清楚，到控制台上一项一项盘点，可以用这种方式，这是面向大客户定向邀约的，如果要想用需要邀请码，去找到对应服务的IaC,就是服务这个企业的架构师找他获取，不是免费随意提供的，但是功能现在是免费的，定向邀约。也是业务无损，因为提供的是只读的AKSK，只读的方式去获取的，而且是由用户自服务，不是由阿里云帮你操作，是提供AKSK用云速搭产品，然后自助操作。

从0设计新架构图，这是20年底上线，它有很多种方式，第一种是可视化的拖拽。可视化拖拽是一个非常传统的方式，这个图是oracle rank上云的一个架构，这个图在云速搭模板里，确实很多存量的大的企业客户用的就是oracle，在云上想自带liCense上云，阿里云有对应的ECS实例，对应的支持多机挂载的云盘，整个方案模板都在云速搭模板里，现在有12c，19还有11G的完整安装步骤，这是属于客户自服务，如果是经验丰富的人，可以从0开始画。如果经验不丰富，可以用应用资源规划的能力。应用资源规划能力里面带有库存判断计算，然后生成架构图，最后一种叫AI智能架构图向导，不需要代码，做任何事情都是零代码，这里是满足架构师从零，现在只有一个蓝图想去画架构图，用这个功能快速画出一张架构图。

 

七、AI智能架构图向导

这是用于初期构思专用，第一功能是免费的，所有人都可以去用，在这里只需要选择对应的区域，有没有需要网络，在设计蓝图的时候需要哪些产品，就打几个勾，最后就能生成架构图，架构图拿鼠标简单调一调，做一些连线就可以用于内部的沟通汇报包含上下和需求方，包含需求方还有运营团队沟通架构要什么样子，从业务承载来看，是不是满足需求。有多种方式来生成架构图。

 

八、云管/OA集成能力

最后一个是云管集成，现在内部的大客户包含外部的客户非常多，云管集成非常多的方式直接去对接裸API。通过Terraform，通过Ros提供，另外一种通过CADT来做。两个案例，第一是云速搭，在中间是一个中间层，把云产品的API做一个抽象，只需要非常少的API，就是计价，校验加上部署，还有最后的释放。其实最少的API就7个，能实现库存校验，这很关键，因为现在所有的产品都没有库存校验的能力，就是用自动化的方式。在这里自动做合价，合价完以后来判断账号里的钱够不够交付整个架构，因为经常遇到一些客户，按顺序买资源，结果买到中间的时候发现账号里没有钱，那这时候怎么办？要不充值，要不就把这些资源退掉，因为现在资源没办法全交付，这是很多的企业库非常常见的，这个时候会造成资损，按顺序开资源可能开一堆资源，要开几天，前面开出的资源其实都是浪费，因为在那空跑，所以要把时间花在设计上，而不是花在开资源上，开资源没有价值。

从云厂商的角度来讲，云一定会越来越简单，往业务上理解为什么要用这套架构，而不是资源怎么开通，那是云厂商要干的事情，这里有几个大的模块，有管理模块，运维，计量计费，内置CMDB，还有告警，然后加监控。云速搭在上面对接下面IAAS和pass的产品，只要通过云速搭单就对接刚才225款产品，只要对接一次，只需要写一次代码，看两个案例，都有官方授权，下面都有link，这两个客户是比较典型的，一个是满帮，一个是诺基亚，满帮是一个偏互联网的企业，为什么没有选择其他的IaC的方式，有自己的考虑。诺基亚是按照单元化的方式来交付业务系统，会有非常多的开发运维的系统，在分享环节里之前评估过另外一种的Terraform，后来改成用CADT，如果用Terraform，就尽量不要换其他的入口，因为各个IaC有一些限制。如果用Terraform，不能用控制台，这样会导致它的状态和系统里不一致。

用CADT的好处是解耦的，只通过它创建。现在有些外企的客户，写Terraform脚本非常费时间，做一些抽象东西把更复杂代码降低到50%。外企客户，Terraform没问题的。交付时间可能很短，就一周时间，他可能评估需要一月去写代码。现在用CADT交付所有的资源，然后再import到Terraform里。所以用云速搭产品非常灵活，可以前面交付云速搭，后面去解耦，用Terraform ，ROS，或者用控制台，内置的CADT会自己维护一套数据，同时会反向从配置审计里拿到资源状态变更的信息,并且不会强绑定，架构希望分享一个理念，对所有的运维团队来讲，如果真的理解业务的架构，为什么要从业务用这套架构，对于技术的生命延长会更多好处。因为技术总是要做迭代，对于架构里面，不管阿里云或者国内的其他云，或者国外的云，是终身受用的，如果盖过中国尊，再盖一个和中国尊一样的楼，他只能找你，他不会找一个盖房子的人来盖这栋楼。所以很多时候代码是可以用自动化生成。