VelocityLight/不上班你养我啊.md Secret

## 不上班你养我啊.md

      
    Raw
  

              不上班你养我啊.md
            
          
    【完整版本，可提交初赛评审】
【项目仓库代码链接：https://github.com/VelocityLight/yunji】
团队介绍

队名：不上班你养我啊?
口号：省点钱养你！
团队成员：

叶鋆郴 @VelocityLight : 工程效率研发工程师（队长 + 技术设计）
李煜超 @MimeLyc : 工程效率研发工程师 （前端 + 数据分析）
莫飞虎 @Codingpoeta : 工程效率研发工程师 (后端 + 前端)
张月 @heipark : 版本发布经理 (业务需求 & 场景设计)

背景&动机

云技术技术浪潮下，企业一方面享受云上完善的基础设施的福利，一方面苦恼于云上资源与成本的管理。
忘记关闭资源、程序泄漏资源、安全泄露导致瞬时费用暴增引起资金损失等等问题，都让企业人员都头痛不已。亚马逊将勤俭节约（Frugality）作为领导力准则之一，可见成本对于一家企业的重要意义。而这对于创业公司更是如此，成本优化不是一个公司的任务，每个云上开发人员都需要具备的技能，极致优化才能诞生伟大的软件。
本项目的目的是解决企业在云上部署架构下统一成本分析、关键指标监控告警的问题。2022 年上半年工程效率团队面向 AWS 云上资源&成本的复杂难题，联合兄弟团队和云厂商合作伙伴，通过集群自动回收、EC2 泄漏专项治理、冗余云上账号关闭、常态化报表监控等方式。但是这过程中，有很多人工支持的投入、费用均摊的难题、难以实时分析的无奈，我们期望通过本项目，可以将一部分人工经验转化为自动化的系统，通过对大数据的存储与实时性分析，实现一个从：云上账单明细获取与存储 -> 云上资源与成本实时性分析&费用分摊 -> 云上实时资源与成本的监控和异常告警 -> 云上资源与成本优化及管理，这样一个完整的闭环！
因考虑到数据量巨大，统计分析实时查询、告警要求多，我们采用 HTAP 数据库的 TiDB 作为存储和计算引擎，发挥 TiDB 在应用场景下的价值。期待可以通过此项目，节约你的金钱"亿"点点！
项目介绍

项目名称

云迹 (含义：分析与监控云上资源与成本的痕迹)。
为什么要用 TiDB

云上资源与成本账单明细，远比想象中的庞大与复杂；
以贵司的日常 AWS 云上开发账号为例，单纯一个月共计账单明细就有: 15,413,142 条（约1500万），每日明细就有: 1500万/30  = 50万条！
如此庞大的数据量，人工分析是几乎不可能的。诚然目前 AWS、GCP 等云厂商都有提供自己的资源与成本分析工具，例如 AWS 提供了 Cost Explorer、Athena 等工具服务，GCP 提供了 BigQuery，但这些工具服务存在各自的使用壁垒；同时还有一些三方平台和创业公司，提供了 cloudcheckr、klarity 等产品进行云上资源管理，但这些产品本身也需要收费。
但每条明细又实实在在关乎于真正的钱，若资源与成本不可控，那么后果不堪设想。我们的需求是：支持账单明细的大数据量存储、兼顾数据的实时性分析，前期考虑实现相对简单的定制化需求：账单数据获取与存储、分析与按团队费用分摊、实时性异常告警，TiDB 完美契合"大数据量、实时性分析"的 HTAP 要求。
在本项目中：数据亦是金钱，兼顾大数据量与实时性的高要求，这是 TiDB 在本场景中发挥的关键价值！
技术设计详情

云迹最简化的设计主要由三个层次: 数据接入层、数据处理层、数据消费层组层，每层包含若干组件，组件下包含多个模块。整体结构如下图(蓝色箭头代表数据流向)：

关于数据接入层:

data-fetcher 组件: 微内核模式，包含 data-provider 模块，调用 data-provider 的接口获取数据、格式化数据、按照云迹指定的格式将数据持久化，并且注册数据相关的事件到事件中心等待事件监听器获取并进行处理。其中：

data-provider 模块: 定义数据采集和转换的接口，各个云平台数据接入时实现标准接口。接口需要提供调度配置、数据处理成指定格式、数据获取等能力。典型的 data-provier 如:

AWS 离线数据 provier，我们可以直接利用 TiDB Cloud 自带的功能从 S3 导入离线数据并进行处理。
AWS 实时数据 provier，我们根据 AWS 的实时 计量信息接口 和 报价信息接口 , 计算实时计价信息。


关于数据处理层:

事件中心组件: 包含监听器模块，负责注册事件监听器对事件的元数据注册，轮询实时或离线数据获取事件，根据元数据信息触发相应的监听器执行事件监听，处理数据，其中：

监听器模块: 提供监听器接口，供事件监听器实现。向事件中心对元数据(如账单用户、tag、region...)信息进行订阅，当元数据信息满足订阅条件时会通知相关监听器处理数据。比较重要的事件监听器如:

对所有实时数据的汇总监听器，会根据特定元数据对实时数据进行卷积汇总，并持久化到离线数据表中，保证数据展示层能同时获取到历史及实时的数据。
告警规则监听器，会根据用户注册的告警规则配置的元数据对实时数据进行监听，当满足告警条件时根据告警订阅信息发送告警通知。


数据服务组件: 包含 实时数据服务模块 和 离线数据服务模块，两个模块会接受数据消费层的请求，返回指定格式的数据。指定格式的数据可以是对应数据消费层的裸 sql，以类似 OSSInsight 的形式提供数据消费能力。

关于数据消费层:

告警中心组件: 包含告警规则模块、告警通知模块，用于支持用的告警规则定义、告警事件订阅、告警消息通知。具体模块设计：

告警规则模块: 用户对指定账单的元数据进行规则定义，当满足规则的账单事件发生时触发规则相关的订阅告警。告警规则由监听的元数据集合和触发条件组成，如订阅元数据信息"region:us-west-2"下的触发条件"一分钟内创建集群数达 N 台"。
告警通知模块: 根据对告警规则的订阅信息，在触发告警时通知目标订阅用户/订阅组。


数据展示组件: 提供多种类型的数据展示图表，同时支持根据图表进行数据下钻，展示目标数据范围内的相关明细信息，辅助进行问题挖掘。

场景演示


实时成本分析与展示效果如下：


按团队成本均摊效果如下：


实时异常检测配置 & 告警效果如下：


未来拓展与场景思考

云上资源与成本管理是一个非常复杂的问题，甚至是云上最难的问题之一（资源成本、网络、安全、权限控制，云上使用难点巨头）。本项目实现了初步的云上资源与成本实时性分析与监控，实际上它还拥有更广阔的场景——"多云场景下云上资源管理"。
现在的许多公司使用云，不会单纯只依赖于一朵云，而是多云场景下的业务需求，例如贵司就有 AWS、GCP、Azure、阿里云等多云上业务支撑。每朵云上由于云厂商提供的产品服务不同，所以上面的问题会在不同云厂商依赖的情况下反复出现。
而对于创业公司研发人员来说，每次都要重新了解一朵云的资源与成本优化、资源管理的知识，学习成本实在是太高了，对公司来说云知识的了解也是一种非常大的投入。于是，在现在云的潮流下，就催生出了一些专门面向云上资源管理的创业公司，例如前面提到过的 cloudcheckr、klarity 等基础设施的创业团队，他们将云上资源与成本分析、监控能力涵盖其中，同时还提供了多云场景下的云上资源管理能力，通过对云上能力的封装，简化多云场景下资源与成本管理的复杂性。但是这些公司貌似没有使用 TiDB 而是自建数据仓库，其实 TiDB 的能力与其非常契合，这是贵司的一个非常好的推广场景 & 契机哈哈！
这就是本项目最初的口号："省点钱养你"。怎么省钱？通过使用 TiDB 来省钱，更通过基于 TiDB 上搭建应用来省钱，最后省许多许多钱，支持大家的共同美好未来！