来源：哔哩哔哩技术
1.前言
为什么使用多云：
公有云因为其弹性、按需使用以及多地域的覆盖等优势，企业在高速发展的过程中往往会选择公有云来提供应用所需的基础设施；
为了高稳定性和成本最优的考虑，一般会引入多家云厂商；
多云部署防止单一云厂商故障导致服务完全不可用； 采用多云也提升了采购上的议价能力，避免单一厂商绑定，在价格谈判中处于劣势；
不同的云厂商在覆盖的地域、产品的能力上不一致，引入多云可以充分发挥各厂商的服务能力和产品优势。
多云带来的问题：
公司内因为云上资源使用的业务比较多，资源新增和交付主要依赖人工沟通并在控制台上进行操作，效率很低，在遇到大批量的资源交付、服务器、数据库和负载均衡等多产品联合交付等场景的时候，无法满足业务的高速迭代需求；
不同的业务使用的云产品不同，基本上都涵盖了主要的IaaS和PaaS类的云产品，资源分布在多个公有云、多个云账号下，无法准确掌握全部资源情况，寻找资源困难，难以区分哪个资源由哪个业务使用；
用户在公有云控制台上权限混乱缺乏管理，存在权限泄露问题，操作不同资源需要通过密码登录不同公有云不同账号，难以批量操作，高危操作缺乏审批流程；
网络配置复杂，需要学习和掌握很多专业的网络知识，难以排查网络连通性问题；
公有云成本逐步上涨，但缺乏成本的可视化，以及支持成本优化的能力
2.平台介绍
针对上面提到的问题，多云管理平台建设迫在眉睫，如何来帮助业务用好云，帮助云管管好云是多云管理平台建设的最终目标。通过调研一些业内的CMP平台，以及团队内部多轮的讨论、与业务用户的交流，对于多云管管理平台我们定义它应该至少具备：
体验友好，简洁易用；
包括以下功能：
资源管理
资源编排
用户管理
成本管理
从2022年4月开始规划和调研，7月份第一版本发布上线，到现在经过多轮迭代，B站的多云管理平台ARES已经在帮助业务用好云、云管管好云上迈出了坚实的一步，在降本增效方面发挥着重要的作用。
2.1 平台架构
图1：平台架构图
整体采用分层架构，最顶层面向用户，提供用户的统一入口，用户通过统一前端完成资源的整个生命周期的管理，同时也提供接口；
中间层为业务逻辑层，主要功能分为项目管理、资产管理、用户管理、资源编排和成本管理，涵盖云资源的增删改查等操作以及生命周期的管理，同时也管理了多云的账单以及云上的用户账号；
项目管理：主要是管理ARSE项目元信息，围绕项目管理多云资源、账号和账单； 资产管理：主要是管理资源的资产信息，通过标准化，统一多云资产管理，消除多云的差异； 用户管理：主要是全生命周期管理云上用户账号； 资源编排：通过资源编排能力，帮助用户既可以自动部署单个资源，又可以处理复杂的联动资源的部署需求； 成本管理：主要是对云上账单进行分析处理，提供成本可视化和用量数据，为平台运营提供成本优化的数据支持。
底层是引擎层，主要是通过IaC和api结合的形式对接各云厂商，完成所有上层动作的最终执行。
3.平台功能
3.1 项目为中心的全局管理
为什么以项目为中心？
在ARES立项阶段，最先考虑的一个问题是以什么维度来划分资源和权限，每个用户的资源管理边界在哪，基于现状，随着业务发展，公司组织和部门会相应的调整，导致资源的归属会经常变动，并且从成本角度，云上的资源需要比较细粒度的进行成本拆分，基于此，参考公有云的管理逻辑，我们定义了项目的概念，作为ARSE管理多云的核心。
3.1.1 项目与资源和账单的关系
首先，项目作为多云平台的管理中心，公司组织是预算执行以及成本归属的重要单位，所以我们需要先定义项目和公司组织的关系。通过分析公司组织的特点：
公司组织为树形结构，叶子结点为业务部门；
每个业务部门都会有多个业务项目，分别由不同的业务团队负责；
我们定义公司组织和项目的关系为1:N，一个项目只能归属为唯一一个组织，但是一个组织下可以有多个项目。
其次，云项目是云厂商控制台的概念，虽然不同公有云的名称不同但表示的含义是相同（比如A云叫资源组，B云叫企业项目），这里我们统一称为云项目。根据同一个账号下云项目是唯一的特性，我们定义项目与云账号、云项目之间的关系：
一个项目可以关联多个云账号；
一个云账号下，一个项目只能关联一个云项目；
云项目的名字必须和项目相同；
最后，在公有云中，资源是可以归属到云项目下的，可以以云项目的粒度在云上管理资源。但是，云项目有个问题就是无法关联所有的资源，我们这里采用定义一个云标签来辅助资源的管理，以bili_project为key，项目名为value，利用标签对于资源的覆盖范围更大这一优势来作为云项目的补充。针对项目与云资源的关系：
对于存量资源，经过治理，把资源按照云项目和云标签进行了正确的分组；
对于增量资源，在创建资源的时候根据项目和云项目的映射关系，自动归属资源到对应的云项目，同时打上对应的云标签；
从这里可以看出，通过云项目和标签作为中介，可以关联项目和资源，因为账单里可以根据资源的云项目以及标签来定义账单项的归属，所以也就定义了项目和账单的关系，由此可以把账单归属到公司部门。
3.1.2 项目与用户权限的关系
项目定义了四种角色：研发负责人、研发成员、运维负责人和运维成员，只有是这四种角色的用户才能对项目下的资源有限定的权限：
研发负责人角色权限：可以查看项目资源，发起项目资源的操作需求，作为操作工单的研发节点的审批人；
研发成员角色权限：可以查看项目资源，发起项目资源的操作需求；
运维负责人角色权限：可以查看项目资源，发起项目资源的操作需求，作为操作工单的运维节点的审批人；
运维成员角色权限：可以查看项目资源，发起项目资源的操作需求，作为操作工单操作前的安全确认和执行后的结果验收；
除了平台的用户权限是通过项目来定义边界外，云上账号同样是通过项目来定义权限边界的，怎么实现云账号权限的项目限定呢？
主要是利用了云上的自定义策略，对于项目级别定义了两种角色自定义策略：
研发角色自定义策略：对云上资源只读的权限
运维角色自定义策略：对云上资源的运维操作的权限
通过云上的项目和标签，利用自定义策略语法里的条件语法，如下，为项目A研发角色的自定义策略，然后把用户云账号关联自定义策略即可完成用户和对应角色权限的绑定。
{ "Version": "1", "Statement": [ { "Effect": "Allow", "Action": [ "*:Describe*", "*:List*", "*:Get*", "*:BatchGet*", "*:Query*", "*:BatchQuery*", "actiontrail:LookupEvents", "actiontrail:Check*", "dm:Desc*", "dm:SenderStatistics*", "ram:GenerateCredentialReport", "cloudsso:Check*", "notifications:Read*" ], "Resource": "*", "Condition": { "StringEqualsIgnoreCase": { "*:tag/bili_project": [ "项目A" ] } } } ]}3.1.3 项目与环境配置的关系
每个项目都有完整的一套或者多套环境，ARES支持用户在项目级别配置环境，这里环境包括网络环境、资源参数。
（1）网络环境，用户在提交项目创建的时候，可以按照业务需求配置：
生产环境和测试环境
选择资源规模，平台根据资源规模自动规划网络，创建业务子网
配置网络访问控制，平台根据访问控制自动配置安全组和选择对应的网络VPC，比如云上私网VPC、混合云VPC等
配置公网，自动关联NAT
项目创建后，根据配置自动在云上创建符合需求的网络环境，为后续资源创建提供正确的项目网络。
（2）资源参数，平台的出发点是降低用户的资源参数选择成本，提高资源申请的效率：
首先在项目创建完成后，用户可以根据业务场景和资源选型，配置云服务器、RDS以及Redis等资源的参数配置，比如云服务器的镜像、机型，RDS和Redis的版本和规格等，如图所示，预先配置这些参数可以在资源申请阶段，不必在云厂商提供的少则几十种，多则上百种选项中筛选目标配置。优化了用户体验，提高了资源申请的效率，以云服务器的镜像和机型举例可以看出前后数量对比。
图2：项目配置
图3：配置前后数量对比
除了配置这些参数作为资源申请时候的待选参数外，平台还提供了提前配置模板的能力，解决相同需求重复申请的问题，比如，对于某项目，可以把第一次资源申请的工单保存为模板，后续随着业务的发展，需要追加申请资源扩容，可以直接以模板发起，不需要重新提交资源需求工单，如图4：
图4：项目模板列表
综上，对于通过项目，可以高效的管理资源、权限以及成本归属，通过项目可以帮助用户提高资源申请效率，这也是ARSE选择项目作为整个平台的管理中心的原因。
3.2 统一的资产管理
通过上述项目的介绍，应该已经清楚整个ARES对于多云的资源是基于项目管理的，要做好统一管理，面临以下问题需要解决：
不同的云的产品叫法不一致，如何消除产品认知上的差异；
云产品的属性特别多，并且字段名也不一样，获取的方式也有差异；
对于同一种属性的value定义存在多云差异，如何统一；
对于上述的三个问题，我们分别从产品标准化、属性标准化以及数值标准化三个维度去逐个解决。
3.2.1 产品标准化
ARSE针对不同云的产品名称不一致的问题，ARES定义了云服务器、RDS、Redis、负载均衡、对象存储等30多种标准产品（如图5），并与云上对应产品进行映射，实现多云统一管理的需求。以标准产品中云服务器为例，将阿里云的ECS、腾讯云的CVM，华为云的ECS以及亚马逊云的EC2等公有云云服务器类产品统一在ARES平台定义的云服务器中管理，统一对外命名为云服务器，消除名称上的差异。
| 标准产品 |
A云 |
B云 |
C云 |
D云 |
|
云服务器 |
云服务器 ECS | 云服务器 CVM | 弹性云服务器 ECS | Amazon EC2 |
表1：多云下的云服务器产品
图5：ARSE定义的标准化产品视图
3.2.2 属性标准化
对于不同云的产品属性差异的问题，需要标准化，对外统一属性，如果将不同公有云的属性直接展示给用户，会出现表达相同含义的属性在不同位置展示的问题，无法实现用户无法统一筛选、排序和查看的需求。为此我们针对接入的产品，每个都对其属性进行了标准化，并且把每个云的属性和标准化的属性映射关系记录下来。如下表，是我们标准化云服务器部分属性的情况，对于未进行标准化的属性，我们也按照公有云提供的原始数据结构进行存储，满足少量高级用户管理需求。
| 标准化属性 |
A云 |
B云 |
C云 |
... |
| 云ID |
实例ID |
ID |
实例ID |
... |
| 名称 |
主机名 | 名称 |
名称 |
... |
| 云项目 |
资源组 | 企业项目 | 所属项目 |
... |
| 地域 |
地域 | 区域 | 区域 | ... |
| 可用区 |
所在可用区 |
可用区 |
可用区 |
... |
| 镜像 |
镜像ID |
镜像 |
镜像名称 | ... |
| 规格 |
实例规格 | 规格 |
实例规格 | ... |
| ... | ... | ... | ... | ... |
表2：属性标准化
图6：ARES云服务器的属性详情
3.2.3 数值标准化
经过产品标准化和属性标准化后，已经实现用户在统一视图下查看和管理所有资源的需求，此时仍然有一个问题：对于状态、类型、计费方式等枚举类型的产品属性在不同公有云的取值范围定义都不相同，直接暴露给用户不利于筛选，并且会造成误解。
以公有云服务器的『状态』属性为例，不同公有云的取值范围不同，ARES的方案是，按照表示的含义取交集，对于交集没有包括的部分设置两种状态：异常状态和其它状态，所以标准化后的云服务器的状态为：创建中、运行中、启动中、停止中、已停止、异常、其它。用户可以通过筛选查看对应状态的资源。
在经过产品标准化、属性标准化和数值标准化后，多云的资源在ARSE平台实现语义和展示上的统一，再结合项目管理章节的介绍，用户可以在ARSE上基于项目全局上查看到同一个项目下的资源分布，以及在单一资源类型下，基于统一的认知，可以多维度检索资源列表信息和详细信息，对于用户而言，ARES“消灭了”多云，把自己打造成了云平台，ARSE就像是编程语言中的“接口”，对外都是标准化的，没有歧义的，而实际执行操作是每个云对于这个接口的实现。
图7：项目ARSE平台的云服务器列表
3.3 基于IaC的资源编排 Promise 的背景介绍
资源编排是多云平台的核心功能之一，好的资源编排能力既可以单账号多资源联动部署，又可以跨账号部署资源。ARES是基于Terraform为主，API为辅来实现资源编排的，这里重点介绍Terraform。
3.3.1 Terraform介绍
IaC
IaC（Infrastructure as Code）基础设施即代码，就是用代码来定义和管理基础设施，Hashicorp 公司创建Terraform是IaC中的优秀代表，尽管它不是唯一的 —— 所有主要的云提供商都有自己的 IaC，谷歌提供 Google Cloud Deployment Manager，AWS 提供 CloudFormation，微软的 Azure 提供 Azure Resource Manager，Terraform因为是开源的并且和平台无关，所以广受欢迎。
Terraform
Terraform提供了一套基础设施管理的声明式的框架，主流云厂商都实现了各自云的Provider，Terraform 通过provider与不同的云集成。provider是 Terraform 插件，用于与外部 API 进行交互。每个云供应商都会维护自己的 Terraform provider，使 Terraform 能够管理该云中的资源。provider使用 Go 语言编写的，并作为二进制文件分发到Terraform注册表上。它们负责进行身份验证、发出API请求以及处理超时和错误。在这个注册表中，有数百个已经发布的提供程序，它们协同起来，使你能够管理数千种不同的资源。
这里以A云Provider为例介绍如何利用Terraform的resource来创建一台云服务器
利用Terraform来创建云服务器
# 创建后端服务器resource "Acloud_instance" "server_attachment" { count = 1 image_id = "ubuntu_18_04_64_20G_alibase_20190624.vhd" instance_type = "ecs.n4.large" instance_name = "test" security_groups = "sg-mj7itgyeohjw2ebvyrl" internet_charge_type = "PayByTraffic" internet_max_bandwidth_out = "10" availability_zone = "cn-hangzhou-A" instance_charge_type = "PostPaid" system_disk_category = "cloud_efficiency" vswitch_id = "vsw-uf66iu2bxce23ityocdx"}3.3.2 Terraform实践
介绍了Terraform后，我们接下来讲解ARES如何利用Terraform的能力，经过优化来支持B站的云资源编排和管理，主要分为三个方面。
多云统一：
Terraform虽然可以使用代码管理基础设施，但是面对公有云，Terraform并没有解决多云异构的问题，还是需要每家厂商提供完善的Provider，需要用户针对不同的Provider去写tf文件，所以对于用户还是没有屏蔽多云的差异，ARSE从业务层去解决了多云统一的问题。主要思路为：
对于第三节介绍的产品标准化和属性标准化，把经过标准化后的属性作为变量名，前端按照变量名对产品属性进行定义，对于多个厂商只需要定义一次，所有前端用户选择的value对于不同的厂商赋值给相同一份变量
前端赋值后经过后端接口根据云厂商的不同，根据映射的对应云厂商的terraform的字段进行赋值，调用实际的厂商的Provider插件进行资源请求的执行
如图以云主机为例，不管选择的账号，ARES需要用户填写的label都是一致的，不因多云而改变，提供一致的用户体验。
图8：云主机的申请
参数模板：
每一次用户提交需求，前端变量值映射到后端的tf文件都需要重新生成一份tf文件，这里有两种方案：
根据Terraform的语法规则，自动生成对应产品的resource
本地化配置产品的Terraform模板，按照模板生产Terraform文件
考虑到基于语法自动生成Terraform相关文件有一定的难度，我们选择第二种方案，我们利用Terraform的variable关键子，定义多云下每个产品的模板，比如main_alicloud_template.tf文件，所有变量的value引用variable进行填充，这里有两个关键点：
value为多云统一后的变量名，比如云主机的机器名均为var.hostname
每个变量名按照variable文件的格式生成对应的变量声明和定义
做到如上两点，每当用户提交需求的时候会自动生成含有每个变量声明和定义的variable.tf文件，同时实例化一份模板文件main.tf，组成一份可执行的完整tf环境
多产品编排：
云上资源的申请场景中，会经常存在负载均衡和后端服务器一起申请的情况，对于这种多资源统一部署和编排，ARES利用了Terraform的原生编排能力，通过在负载均衡监听器的后端服务组的attachment的resource中声明云服务器的resource id来实现，如下（以A云为例）：
resource "Acloud_slb_server_group_server_attachment" "server_attachment" { ... server_group_id = Acloud_slb_server_group.server_attachment.id server_id = Acloud_instance.server_attachment[count.index].id ...}利用Terraform的编排能力，我们支持了以下多种场景的编排能力：
负载均衡关联同工单创建的后端服务器；
CDN部署管联DNS自动做CNAME解析；
CDN部署关联负载均衡或者对象存储作为源站。
如下图9、图10是ARES上支持负载均衡关联后端云服务器以及CDN关联对象存储作为源站的例子
图9：负载均衡申请关联后端服务器
图10：CDN关联对象存储域名
3.4 安全可靠的用户管理
由于ARES还在迭代中，对于云上资源的运维操作接入并不完善，用户还是会需要采用云账号登录控制台进行资源的运维，比如调整数据库的参数，配置告警策略等。所以当前现状下，云账号还是用户运维资源不可或缺的辅助手段。
由于云账号属于公有云，它的安全性相对于内部平台的账号不可控，比如用户的权限和密码的管理，账号的回收等等。为此，ARES针对云账号全生命周期管理进行了设计和支持，保证云账号的安全可靠。
3.4.1 云用户账号申请
对于云用户账号的申请需要满足以下条件：
必须是项目的四种角色之一
必须选择项目，不能是全剧账号
除了条件之外，最主要的还是云账号的获取必须走申请流程，流程里配置了用户的直属领导审批，如下图所示。
图11：云账号申请流程
3.4.2 云用户账号登录
使用云用户账号登录存在以下问题：
如果某个用户需要申请的账号比较多，管理账号密码就显得很痛苦；
由于密码是用户自己管理，容易泄漏，造成云上资源存在一定的安全风险。
通过调研业界的做法，ARSE基于云厂商原生支持的SSO能力和公司内部的单点登录，实现了基于内部IDP认证的云上账号单点登录，整体逻辑如图，优点是把云账号的登录跳转到内部的身份认证，只需要用户扫描登陆内部企业微信就可以实现一键登录到云上进行资源的管理。不需要键入密码，因为云上开启了SSO的功能，及时密码泄漏，外部用户也无法登录到云控制台。
图12：单点登录流程
3.4.3 云用户账号回收
对于拥有云账号的用户，一旦存在工作变动，云账号的存在就转变为一个安全漏洞了，平台是如何及时处理工作变动用户的云账号？
首先，因为单点登录的开启，云上的账号的申请都是和用户内部的唯一身份名进行绑定的；
其次，ARES利用公司内部接口，可以获取到离职人员的名单列表。
基于以上两点，平台可以定时获取离职人员，并且和云账号所绑定的用户进行比对，一旦发现用户处于离职状态会第一时间自动关闭云账号的控制台登录权限，为了防止误操作，关闭登录权限后一段时间内才会去清退删除账号。（如图13所示）
图13：云账号的在离职状态管理
3.5 多维度的成本管理
整个成本的管理包括业务前期的需求评估阶段，厂商和产品选型阶段，资源创建阶段，资源的巡检以及账单的分析。
图14：资源不同阶段的成本优化方式
3.5.1 申请阶段
需求评估
需求评估的主要流程：
对于业务的上云需求，我们会跟业务方进行技术侧的沟通，了解业务的架构，从技术上给出资源选择建议以及可能满足需求的云厂商；
业务技术侧对于至少三家云厂商的产品进行技术测试；
采购侧根据测试结果以及云资源的成本，给出性价比最高的厂商；
资源选型
资源选型主要包含两个方面；
性能测试：云资源的基准测试是评估其性能的最主要途径，通过Unixbench和SPECCPU我们针对主流厂商的常用云服务器进行了基准测试，并且测试数据作为智能推荐的参考因素，帮助业务合理的选择云服务器的类型，后续也会针对MySQL和Redis等云资源做性能测试;
智能推荐：对于业务用户来说，在选择云服务器的机型的时候并没有足够的数据支撑，同时在不同的厂商之间如何决策该选哪一家性价比最优一直是一个头疼问题，为此ARES针对该场景提供了智能推荐的功能；
以云服务器智能推荐为例，通过调研各大云厂商提供的机型选择相关的参考指标：
| 因素 |
作用 |
| CPU |
可以作为筛选项，主要用于定位用户的对于规格的需求 |
| MEM |
同上 |
| 规格类型 | 主要用于业务场景的分辨，不同的规格类型适用不同的业务场景，可以作为筛选项 |
| 内网带宽 | 主要是体现云服务器的内网网络带宽性能 |
| 内网收发包 | 主要是体现云服务器的内网网络吞吐能力 |
| 成本 |
云服务器的价格（折扣后） |
| 性能测试数据 | 性能测试数据，作为业务选型的参考 |
我们选取CPU，MEM以及规格类型作为推荐时用户可以筛选项，根据筛选项输出满足用户需求的按照成本排序后的机型，整体逻辑如图15所示。
图15：资源选型智能推荐流程
图16：资源选型效果图
3.5.2 运行阶段
资源巡检：
在资源运行阶段，对于成本优化我们一般从两个方面着手：
低利用率资源降配；
闲置资源及时清退；
首先，低利用率资源降配的主要流程是：
定义业务和成本关心的监控指标，例如：云服务器和云数据库，我们主要关注CPU和内存的利用率，所以选取两个监控项来体现资源的使用情况；
利用云上的接口获取利用率的监控数据，因为考虑到云上的接口查询频率，我们定义每5分钟查询一次数据，每天对这些数据进行峰值和均值的计算并且持久化；
这里出于数据存储的成本考虑，我们只把统计后的数据保存下来，这样对于单个实例，每天三个数据（最大值，最小值以及均值），数据量相当于全部保存的缩小了100倍，可以保存更长时间的数据；
定义巡检的规则，例如：设置云服务器的CPU利用率均值<10%，内存利用率均值<10%；
按照规则每天对数据库中的利用率统计数据进行分析，并且生成满足规则条件的实例列表；
拿到实例列表后会输出给业务方，作为业务方降本的数据支撑
其次，对于闲置资源，根据实际使用场景，我们定义了以下几种闲置资源：
未绑定云服务器的云硬盘；
未绑定实例的弹性公网IP；
没有监听器的负载均衡实例；
持续状态异常的云服务器；
结合前面介绍的资产管理，根据本地数据库中的资产信息就可以实现闲置资源的定期巡检。
从低利用率资源到闲置资源的巡检，ARSE不断探索资源优化和技术降本的可能性，助力业务更加合理的使用云上资源。
账单分析：
通过导入账单，对账单进行分析，可以能够可视化的展示成本的总体情况，项目维度以及组织维度的成本构成，并且通过定义每个资源类型的计量标准计算用量用于业务确认：
成本可视化：按照时间，展示成本的变化情况，方便成本和采购团队关注业务在公有云上的成本；
成本构成：展示基于一个项目下的成本的构成情况，并且能够多级下钻，有利于用户分析业务的成本构成，及时知晓成本大头，确定降本的方向；
用量确认：在账单里存在多个计费项（例如：云服务器有实例规格的计费项，公网带宽的计费项，云硬盘存储计费项等），为了方便业务用量确认，我们定义了用量标准（例如：云服务器，我们定义CPU核数作为云服务器的用量标准），每个月平台按照既定的用量标准计算用量后，业务可以针对该用量数据和业务实际使用的资源用量作对比，确认账单用量无误。
4.展望
ARES多云平台从业务日常的需求出发，结合一线资源交付人员的经验，参考业界的CMP产品的能力，建设成一个符合B站业务用户使用习惯和云管用户管理方式的平台，最大程度的支持业务”用好云“，云管”管好云"，利用平台化的能力和数字化运营助力降本增效。
目前，ARSE多云管理平台还处于不断迭代和完善的过程中，未来平台的主要建设方向包括：
持续完善成本优化相关的能力，帮助业务降本增效；
基于容器服务和云原生架构，实现多云环境下的自动迁移和伸缩能力；
托管私有云，建设成统一的混合云管理平台。
5.参考资源
*-安全断言标记语言：%E5%AE%89%E5%85%A8%E6%96%AD%E8%A8%80%E6%A0%87%E8%AE%B0%E8%AF%AD%E8%A8%80
*-SAML 2.0：SAML_2.0
Terraform：https://developer.hashicorp.com/terraform
Provider：
https://developer.hashicorp.com/terraform