如果您是金融机构或银行的开发人员,您就会知道,速度和可靠性不仅仅是好东西,而是必不可少的。在金融领域,毫秒之差就意味着盈亏。无论是执行交易、处理交易还是提供实时分析,都需要分秒必争。更快的处理时间可直接转化为更好的用户体验、每秒更多的交易量,并最终带来更多收入。
我们的一位客户需要处理数以亿计的数据密钥,同时满足严格的性能和正常运行时间服务水平协议。在本篇博客中,我们将介绍Akamai如何帮助客户以较低的延迟摄取大量数据,以及为什么Akamai也可能是您的正确选择。
容量:处理海量数据
大数据中的第一个 "V "是指产生和收集的数据量。对于银行等金融机构来说,由于交易、账户更新、客户互动和其他金融活动源源不断,有效处理这些数据量至关重要。
Akamai不断检查进出数据中心的流量,检测互联网拥堵、中断或其他可能影响客户的问题。这一点对我们的客户来说意义重大,因为他们需要将用户发送到最近的数据中心或高性能数据中心,以确保低延迟。他们根据实时数据设置了自定义规则,以确保流量尽可能高性能。.
让我们来看一个工作流程示例,演示Akamai的Global Traffic Management (GTM)如何处理海量流量。Akamai GTM在多个数据中心之间分发进入的流量。
在本例中,位于顶部的数据中心 2 处理 40% 的流量负载,而位于底部的数据中心 3 处理其余 60% 的流量。在本例中,假设数据中心 1 因停电而瘫痪。这种分布可确保没有一个数据中心成为瓶颈,从而保持高性能和可用性。GTM 还会根据当前负载情况智能引导流量,由于数据中心 1 停机,因此会将更多流量引导到数据中心 3。
让我们一步步来了解这个示例。首先,终端用户将发送访问银行移动应用程序或网站的请求。
然后,DNS 解析器使用标准 DNS 程序,向网站的名称服务器请求 IP 地址。
这就是Akamai发挥作用的地方。解析器获得的不是直接的IP地址,而是一个CNAME别名。
名称服务器将为该用户返回通往银行的最佳路径。
GTM 会查看您设置的所有自定义规则,检查其全球传感器网络,并返回最佳数据中心的 IP 地址列表。
这可以是Akamai数据中心、云提供商,甚至是您自己的数据中心。然后,解析器会将优化后的IP地址传回用户的浏览器。
最后,用户连接到您的网站,他们可能完全不知道刚刚在幕后发生的复杂舞动,因为这一切都发生在毫秒之间。这不仅为管理全球流量省去了很多麻烦,还确保了高可用性。此外,由于可以设置自定义规则,您可以灵活地优化银行最关心的任何指标。
这种动态负载平衡有助于防止任何单个数据中心超载,确保即使在高峰期也能持续提供服务。此外,我们还看到了故障转移支持。由于数据中心1出现故障,Akamai的GTM会自动将流量重定向到可用的数据中心(数据中心2和数据中心3),无需用户干预。这种故障转移功能对银行来说至关重要,它可以确保银行的服务在一个或多个数据中心出现问题时仍可继续访问。
速度数据处理速度
大数据的第二个 V 是速度。速度是指数据生成、处理和分析的速度。通过战略性地将计算资源放置在离最终用户和数据源更近的地方,Akamai大大缩短了数据穿越网络所需的时间。这种方法使计算和数据存储更接近需求点,从而大大加快了数据处理时间。对于这家金融机构来说,当客户通过他们的移动应用程序发起资金转账时,交易请求传统上需要传输到中央数据中心,而这个中心可能位于数千英里之外。有了Akamai的边缘计算,该请求的初始处理可以在附近的边缘服务器进行。这就将交易处理时间从几秒缩短到了几毫秒。
让我们使用 Akamai 与AWS 进行性能比较。在比较中,我们使用 ThousandEyes 监控服务及其 11 个位于美国的测试代理。我们的团队配置了一个控制测试,通过 HTTPS 从AWS API Gateway 请求一个类似大小的对象,该测试在一个 Lambda 函数前进行,该函数从托管在 US-East-1 的 DynamoDB 返回一个 KV 对象。实验测试通过 HTTPS 向通过 Akamai 计算分发的 NATS.io集群请求对象。
现在,让我们比较一下AWS 和 Akamai 的响应时间。从上面的仪表板中,我们来分析几个关键的性能指标。Akamai的NATS.io对象的总下载时间(7天平均)为55毫秒。而AWS的 DynamoDB 对象的下载时间为 233 毫秒。与AWS 相比,Akamai的总下载时间缩短了76%,这凸显了Akamai在数据处理速度方面的优势。
Akamai NATS.io 对象 | AWS DynamoDB 对象 | |
总下载时间 | 55 ms 细分:DNS 解析:~3 msTLS 握手: ~15 msTCP 连接:~7 msTime to First Byte (TTFB) :~20 ms内容下载:~10 ms | 233 ms 细分:DNS 解析:~10 msTLS 握手: ~40 msTCP 连接:~25 msTime to First Byte (TTFB): ~120 msContent download:~38 ms |
等待时间 | 5-8 毫秒 | 30-50 毫秒 |
吞吐量 | ~100 Mbps | ~40 Mbps |
延迟(往返时间) | ~15 毫秒 | ~60 毫秒 |
互动时间 (TTI) | ~70 毫秒 | ~280 毫秒 |
缓存命中率 | 98.5% | 92%(CloudFront) |
全球服务器负载平衡 (GSLB) 效率 | 99.99% | 99.95% |
从上述指标中,我们可以得出结论,Akamai的架构为金融机构满足严格的服务水平协议(SLA)提供了更坚实的基础。明显降低的TTI(70毫秒对280毫秒)确保了更灵敏的用户体验,这对金融应用至关重要。Akamai的架构不仅加快了速度,还提供了满足金融机构严格的SLA所需的可靠性。
多样性:管理数据类型
大数据中的最后一个 V 代表多样性。多样性指的是企业必须处理的不同类型的数据。如果您在金融机构或银行工作,您可能每天都需要处理多种类型和来源的数据。你有结构化数据,如交易记录、账户余额和客户信息。还有实时流数据,如股票市场馈送和在线支付交易,这些数据都在不断变化。
Akamai的Global Traffic Management 对管理这些不同类型的数据至关重要。对于资金转账等高优先级交易数据,GTM可以持续监控网络状况,将这些请求路由到响应速度最快的数据中心。现在,对于不经常变化的静态内容(账户报表或金融产品信息),GTM 会将这些请求导向离用户更近的边缘服务器。这样可以减轻中央系统的负担,加快访问速度。
GTM 将所有这些数据(网络条件、服务器健康状况、您的自定义规则和当前流量模式)结合在一起,并利用这些数据对如何路由每个传入请求做出瞬间决策。它不断优化和重新优化这些路由,确保每种类型的数据(无论是简单的余额查询还是复杂的国际电汇)都能以最高效的方式得到处理。这种级别的智能路由选择意味着,即使数字交易的数量和复杂性不断增加,您的银行也能保持高性能和可靠性。
总结
在毫秒级的时间和数据复杂度较高的情况下,Akamai以边缘为重点的解决方案能够提供所需的速度、可靠性和效率,使您的业务保持领先地位。凭借先进的GTM和智能缓存,Akamai通过在其广泛的网络中分配负载,有效地快速处理海量数据。
金融机构的工程师可以利用Akamai改造他们的基础架构。通过利用Akamai广泛的全球网络,您可以获得无与伦比的速度和可靠性,让您的用户满意,让您的业务无缝运行。
如果您想了解Akamai的尖端技术如何帮助您的应用程序平稳高效地运行,您可以申请最高5,000美元的积分,以满足您严格的性能服务水平协议(SLA),并为您的客户提供良好的体验。
注释