我们的邮箱地址:

stopped@126.com

致电我们:

13659630032

公司动态

  • Home
  • Freecharge 降低了他们身份管理系统的成本,并通过切换到 Amazon DynamoDB 提

Freecharge 降低了他们身份管理系统的成本,并通过切换到 Amazon DynamoDB 提

2026-01-27 12:02:07 29

Freecharge通过Switch到Amazon DynamoDB降低身份管理系统成本并提升扩展性

关键要点

Freecharge是印度的支付应用,日均处理约100万请求。他们通过将身份管理系统迁移到Amazon DynamoDB,显著降低了总拥有成本TCO达60并改善了系统性能。DynamoDB的无服务器管理模式使Freecharge的运营变得更加高效,减少了手动操作的复杂性。

Freecharge是Axis Bank的子公司,服务超过1亿用户的支付应用。多年来,Freecharge已发展成为印度领先的金融服务与投资应用之一,因其提供安全流畅的UPI支付、公共事业账单支付及移动/DTH充值等服务而广受欢迎。

由于市场营销活动、促销活动和现场活动等因素,Freecharge常常会遇到流量高峰。为了避免高成本的资源过度配置,选择一个能有效扩展以支持不可预测用户增长的数据库显得尤为重要。

在这篇文章中,我们将解释Freecharge如何将其身份管理系统负载迁移到Amazon DynamoDB,一个完全托管的无服务器NoSQL数据库,旨在以任何规模运行高性能应用程序。DynamoDB有效管理了流量波动的同时降低了总拥有成本TCO。

Freecharge 的身份管理系统

Freecharge的身份管理系统IMS负责处理每一个进入支付服务的请求令牌。这个系统也是所有在Freecharge注册用户数据的存储库,既起到令牌管理的作用,又担任用户管理系统。IMS使用Aerospike作为令牌管理的持久数据库,同时也作为用户管理的缓存层。

截至本文编写时,Freecharge的IMS平台每天处理约100万请求。确保用户在Freecharge上的身份验证至关重要。因此,确保IMS的可用性和弹性对于公司整体成功至关重要。

Freecharge的IMS架构采用异步消息处理方法,利用独立微服务在规模上进行运营,并保持独立和灵活性。以下图展示了传统架构。

Freecharge的IMS使用自我管理的Aerospike,这是一个NoSQL数据库,需要订阅或许可证才能访问其高级功能。Aerospike拥有以下架构组件需要管理:

组件描述节点Aerospike设计为分布式数据库,每个运行Aerospike的服务器实例称为“节点”。节点共同组成一个“集群”,一起管理和存储数据。命名空间Aerospike将数据组织成“命名空间”,作为集合的逻辑容器,有助于在同一集群内分隔不同类型的数据或服务。集合在命名空间内,数据进一步组织为“集合”,即关系数据库中的表。集合是将相关记录归组的方法,以便于管理和查询数据。存储引擎Aerospike使用闪存优化、内存为中心的存储引擎以高效存储和检索数据,在确保高速读写操作方面发挥了重要作用。索引Aerospike维护索引以实现快速数据访问,索引根据指定条件查找记录,增强查询的速度和效率。复制Aerospike提供复制,确保数据的可用性和容错能力,在复制模式下,数据副本存储在多个节点上,允许在节点故障时进行恢复。分片Aerospike使用无共享架构,通过分片将数据分布到节点。当增加节点时,数据库能够处理更大的负载。跨数据中心复制对于多数据中心部署,Aerospike提供跨数据中心复制XDR,允许在不同地理位置之间复制数据。

原始设计的挑战

Freecharge最初使用自我管理的Aerospike来管理用户会话负载。Aerospike被选择是因为其架构能够以低延迟的读写操作扩展到大量数据。

随着时间的推移,Freecharge的微服务和产品不断增加。在扩展和维护Aerospike数据库时,我们面临了一些挑战:

扩展性 Aerospike的授权是基于每个集群的存储使用。Freecharge在Amazon EC2上托管的两个集群,每个集群由六个节点组成,因此面临着在不额外支出的情况下扩展存储的限制。这种约束降低了原始设计的可扩展性。操作便利性 自我管理的Aerospike企业版本给Freecharge的团队带来了很大负担,包括打补丁、升级、监控底层实例、许可证管理、存储监控和备份管理等。这些任务共同导致了高昂的TCO。成本 使用Aerospike的整体成本显著较高,因为必须支付许可证费用,再加上在EC2服务器上托管的费用。双重支出模型加重了经济负担。

切换到DynamoDB

Freecharge评估了其他数据库解决方案,发现DynamoDB最符合我们的性能、规模和耐用性需求。此外,Freecharge在多个业务关键服务中对DynamoDB已有一定熟悉度。我们发现DynamoDB帮助我们的工程团队在以下方面变得更有效率:

在规模上的一致性能 DynamoDB在应用程序扩展时能够提供一致的性能,不论数据库大小或并发查询次数如何,读写操作的响应时间保持在毫秒级。简化数据建模 DynamoDB鼓励将相关数据组合在一起,避免了查询规划器解析复杂查询的需要。这使得随着规模的增长,可以获得低延迟查找和高效查询。开发者不必花费时间于性能调优、查询计划调试或解决扩展时的性能问题。自动扩展能力 DynamoDB提供自动扩展能力特性,根据用户流量动态调整数据库资源提供的吞吐量。这使得在流量突然增加时,无需预留资源即可实现无缝扩展,同时以经济实惠的方式保持一致的延迟。无服务器管理 DynamoDB消除了手动设置和管理任务的需要,采用无服务器模式,自动处理硬件供给、配置、复制、软件打补丁、数据库备份和集群扩展等任务。这减少了操作开销,维护了效率。

解决方案概述

本节强调了推动我们迁移到DynamoDB的关键点。

单表设计

在原始数据库架构中,每个特定实体的数据存储都有单独的表。维护用户数据的表有七个。

基于我们对多个微服务使用DynamoDB的经验,我们决定将这一架构简化为一个统一的DynamoDB表。这有效地将相关数据合并到一个表中见下图,进一步提升了性能。

这种数据建模策略还降低了成本,特别是在读操作上,因为单次读操作现在可以检索到所有所需数据,而不需要针对不同实体进行多次查询。

迁移方法

我们从Aerospike向DynamoDB过渡的方法旨在减少停机时间,实现操作的不中断。应用层被修改成一个开关,以将流量复制到一个或多个数据库。这允许支持双写数据库,其中流量可以双向切换。以下图展示了每个阶段的细节:

采用分阶段策略,在第一阶段,我们实现了双写到源数据库Aerospike和目标数据库DynamoDB,仅从源读取。在第二阶段,我们开始向目标数据库写入,并从源和目标数据库读取。在第三阶段,当新数据被写入到目标数据库时,旧数据由后台进程复制并补充。在此阶段,应用层启用了数据验证。读取来自两个数据层的记录进行比较,确保准确性和一致性。这使得任何数据不一致都得到修复。在第四阶段,我们启动了从源到目标的切换,期间没有停机。在这一阶段,新的数据仅写入目标数据库。此时,Aerospike离线以便最终退役。

我们担心由于令牌存储在Aerospike中而可能导致用户登出,但随着记录成功迁移到DynamoDB,我们提供了良好的客户体验。这个指标确保了整个迁移过程中的数据持续可用,保持了对关键信息的不断访问。

迁移结果

在本节中,我们讨论了通过这一解决方案实现的操作便利性、扩展性增加以及成本优化。

操作便利性

由于Aerospike是一个自我管理的数据库,我们需要执行很多手动任务,如前所述。与自我托管的Aerospike相比,DynamoDB在操作便利性方面卓越。DynamoDB提供一个完全托管的服务,自动化诸如扩展、备份和安全性等任务,响应时间在单数毫秒。DynamoDB简化了数据库管理,提供无忧体验,使用户能够专注于应用程序开发而非基础设施的复杂性。

扩展性

DynamoDB实现了无缝且高效的扩展,提供灵活的解决方案以匹配变化的工作负载。其无服务器架构消除了手动干预的需要,允许用户根据需求轻松扩展。自动扩展功能根据流量变化调整吞吐能力,提供最佳性能和资源利用。在我们之前的解决方案中,扩展操作需要额外努力,而DynamoDB自动处理扩展,减少了手动干预的需求。下图显示了吞吐量的波动情况,可以方便地按需扩展。

下图显示了写入TPS。

我们希望在此特定应用程序中实现读写TPS的可扩展性,而无需任何固定的运营支出和手动干预,这在之前的解决方案中是不可能的。

成本

在新的DynamoDB解决方案中,我们只需为所用服务付费,而Aerospike要求我们为突然的流量高峰超额配置数据库。通过将我们的计费系统从Aerospike迁移到DynamoDB,我们降低了60的成本。

结论

在这篇文章中,我们讨论了Freecharge如何通过利用Amazon DynamoDB,一个完全托管的无服务器NoSQL数据库,改进IMS应用程序的会话管理层。Freecharge成功迁移自Aerospike,消除了自我管理授权模式所带来的运营阻碍。DynamoDB的“按需付费”定价使得该负载的拥有成本降低了60,其模式灵活性允许统一的表设计,进一步优化了查询性能。总体来看,这对Freecharge来说是一笔理想的交易。

想要了解更多如何在使用DynamoDB时最大化性能并最小化吞吐量成本的信息,请查看设计和架构DynamoDB的最佳实践指南。

安易加速app官网入口

关于作者

Vikalp Singh是Freecharge基础设施的高级总监,主要负责实施新方案,设计并开发可有效处理海量数据的健壮且可扩展的解决方案。

Kapil Saneja目前担任Freecharge的副总监,负责自动化软件开发生命周期的各个环节。他热衷于利用技术和自动化简化基础设施流程,解决部署挑战并推动架构创新。

Shubham Sharan是AWS在印度德里的技术客户经理TAM,专注于云架构、基础自动化及系统工程。Shubham在协助大型金融服务机构、全球系统集成商和媒体客户设计迁移和现代化战略上积累了丰富经验,提供架构与运营指导。

Dharam Thakkar是AWS在印度孟买的企业解决方案架构师,专门帮助银行、金融服务和保险客户应对数字化转型之旅。他在容器领域富有专业知识,设计革命性解决方案以优化运营,推动在云计算动态环境中实现商业增长。

Freecharge 降低了他们身份管理系统的成本,并通过切换到 Amazon DynamoDB 提

发表评论