中材矿山建设有限公司网站,网络营销第2版课后答案,oneindex wordpress,wap建站系统php版作者#xff1a;邱鑫鑫#xff0c;王彬#xff0c;牟柏旭
公司背景和业务
数禾科技以大数据和技术为驱动#xff0c;为金融机构提供高效的智能零售金融解决方案#xff0c;服务银行、信托、消费金融公司、保险、小贷公司等持牌金融机构#xff0c;业务涵盖消费信贷、小…作者邱鑫鑫王彬牟柏旭
公司背景和业务
数禾科技以大数据和技术为驱动为金融机构提供高效的智能零售金融解决方案服务银行、信托、消费金融公司、保险、小贷公司等持牌金融机构业务涵盖消费信贷、小微企业信贷、场景分期等多个领域提供营销获客、风险防控、运营管理等服务。数禾科技通过自主开发的消费信贷产品连接金融机构与普罗大众赋能金融机构数字化转型迎接中国消费升级的大潮。
数禾当前有三款主要产品还呗还享花小店邦。每款产品都有大量的受众每天会产生大量的应用日志数据通过压缩后归档到阿里云 OSS 存储以达到最优的存储成本。
低效的数据处理
应用日志通过 SLS 收集压缩并归档到 OSS整个链路都非常顺滑。但日常有些业务需要查看详细的应用日志由于日志收集会将 APP 上不同应用的日志都打到一起。因此获取某个应用的日志需要从 OSS 解压大量的文件并从中过滤出特定的应用才可以进一步分析排查。这个过程在实效性和数据处理效率上都存在很大的问题为此数禾运维团队计划从源头重构整个任务处理链路以求以最低的开发成本最高的处理效率最优的资源费用最好的扩展性打造高可用易升级低维护的解决方案。
首先想到的采用容器自建的方案。自建的处理程序从 Kafka 获取数据并负责数据的处理K8s 集群保证任务的弹缩配合自建的发布平台初步能够满足设计的需求。
该方案的优势在于对于 K8s 的使用和任务发布平台数禾运维团队都有了不少的积累整体实施起来难度会比较小。但对比设想的链路目标却还有些欠缺主要表现在
1. 任务开发成本较高 从 Kafka 获取数据数据的业务处理、异步压缩上传任务的发布更新系统对接K8s 的弹缩策略都需要研发人员全新开发。
2. 链路弹性有限 一是 K8s 通过指标弹出资源速度需要 10s对于突发的日志流量可能会出现资源弹出不及时的情况二是 Kafka Topic 数据处理的并发度受限于 Topic Partition当消费程序达到 Partition 数目时消费程序没法继续水平扩大并发度。
3. 资源利用率不够极致 在业务低峰期特别是夜间存在流量很小甚至是无流量的时段但处理程序还是得最小保持 1 个实例的运行造成了一定的资源浪费。
4. 升级维护工作依然很多 业务处理逻辑的修改发布平台的更新对接K8s 平台的弹缩规则等都需要持续的维护。
就在数禾运维团队陷入选型沉思的时候阿里云函数计算后面简称 FC团队的交流让数禾运维团队眼前一亮阿里云函数计算在 Kafka-FC 的链路已经打磨多时对于数禾的业务需求正可以使用到函数计算很多的已有功能数禾的研发团队只需要专注在自身的业务处理逻辑就能快速的搭建一套高可用易升级低维护的任务处理链路。
函数计算的出现恰逢其时
函数计算是事件驱动的全托管计算服务。使用函数计算客户无需采购与管理服务器等基础设施只需编写并上传代码或镜像。函数计算会准备好计算资源弹性地、可靠地运行任务并提供日志查询、性能监控和报警等功能。
通过函数计算自带的 Kafka 触发器和定时触发器数禾运维团队架构出了一套理想的解决方案。架构图如下 函数的处理逻辑如下 数据拆分函数 通过 Kafka 触发器触发触发器会将 Kafka 数据攒批以 batch 的形式发送到函数计算函数计算处理逻辑负责将数据块通过标识字段拆分同一个应用的数据汇聚到一起在 NAS 目录形成独立的文件。属于 io 密集型操作。 数据压缩函数 在一批数据到达函数计算拆分汇聚之后先对数据进行压缩然后将压缩后的数据追加到 NAS 目录对应的文件在写 NAS 前借助 Redis 处理并发锁的问题大大减少了小文件的数量属于算力密集型操作。 数据上传函数通过定时触发器触发将第二步压缩完成的数据上传到 OSS 对应目录然后清理本地目录。属于 io 密集型操作。
通过将处理逻辑拆分将对资源要求不同的操作拆分到不同函数实现了每个函数资源利用率的最大化降低了总体实现的费用成本。
相比通过 ECS/K8s 自建的方案优势还是十分明显的 从对比可以看出采用函数计算的方式在开发效率弹性升级部署费用成本方面相对 ECS/K8s 自建方案都有明显的优势。
落地中的问题
Serverless 理念跟整个任务的架构十分的契合但在落地中还是可以看到有些处理不够优雅的地方总结起来主要有两处 函数计算同步调用的攒批大小是 16M异步调用的攒批大小是 128K为了降低调用函数的计算频率达到更好的攒批效果从而在成本和性能上都达到好的效果使得触发器配置时只能配置同步调用同步调用时函数计算侧的并行度取决于调用方这就要求触发器任务配置多任务分片造成了一定的资源浪费。 在第一个函数中主要处理逻辑是根据 Kafka 消息的应用 id 信息拆分数据将同一个 id 应用的数据聚合在一起由于本身 NAS 和 OSS 都没有提供文件锁所以当多个函数并发写同一个 id 应用文件时如果程序层面不处理文件锁的问题会导致写数据相互覆盖。对于每个函数实例拆分小文件的方案由于 Kafka 消息中应用的种类很多拆分数据总是会形成很多小文件数据合并需要很长的时间。经过多种方案的检验比较最终选择了通过 Redis 处理文件锁每个应用全局最多产生 10 个并发写文件函数计算运行实例写 NAS 文件时先去 Redis 获取文件锁获取成功才能真正开始写入。这种方案在写数据性能上有很好的表现代码复杂度得到了一定的增加但总体可控。
最终这些问题没有成为数禾方案的卡点通过交流和方案验证最终都得到了一定程度的解决。
出色的效果和进一步的期待
在全链路角度看整条链路非常的 Serverless资源使用效率也非常高再配合函数计算 2023 云栖大会推出的梯度计价整个方案在资源成本上也达到了非常好的控制。
在期望方面针对本次场景落地中遇到的问题还是希望可以得到更好的优化。异步调用放宽消息体大小可以以最少的触发器资源达到函数计算的大并发处理。通过 NAS/OSS 原生支持文件锁的能力可以减少文件的数量同时也减少业务层代码在这方面的处理复杂度。
任务从 10 月份上线以来数禾运维团队在该任务的运维投入上得到了人力释放几乎达到了 0 运维 在功能迭代上通过函数计算控制台提供的多版本和灰度能力快速的完成了升级的灰度。
后续数禾运维团队会将更多适合 Serverless 的业务采用函数计算方案最大限度将精力专注在公司业务逐渐剥离运维和底层资源的简单维护。数禾运维团队也十分开放的与函数计算团队探讨更多的场景希望将公司的业务架构在新一代的 Serverless 架构上。
