服务
关于
CloudProse博客
无服务器

将传统数据库变成无服务器事件源

在此处输入一些摘录以显示在卡片上
安迪·沃宗(Andy Warzon)Trek10
安迪·沃宗(Andy Warzon) | 2018年11月16日
5分钟阅读

2018年11月16日,星期五

在本文中,我将概述一种通用方法,当您依靠旧系统中的数据时,可以在AWS上构建事件驱动的无服务器架构。如果您试图弄清楚如何在AWS中构建新的前沿架构,但又依赖于旧数据库中的数据,那么这是给您的。

事件驱动系统和旧版SQL

在无服务器的世界中,对架构进行不同的思考很重要:再见了,大家好 事件驱动,甚至更进一步, 基于流的架构。您的各种计算组件(即Lambda),数据存储(即DynamoDB或S3)和路由(即SNS或API网关)需要通过以下方式相互关联 大事记。事件驱动的思维还可以帮助您理解核心业务流程,并使扩展架构变得更加容易。如果您使用旧的整体结构,则会错过无服务器架构的许多好处:可伸缩性,效率和灵活性。

也就是说,很少有真空设计的新架构。企业中几乎总是有一些其他数据对于新应用程序很重要。通常,这些数据位于SQL数据库中。该数据库通常是本地的。从高层次看,这是问题所在:

这一新挑战是我们在Trek10上多次应对的挑战。如何将内部部署数据近实时地带入新的无服务器应用程序中?解决此问题的方法遍布整个地图,并且始终是自定义的:本地代理查询数据并将其推送到AWS,自定义复制到AWS中的数据库或特定于供应商的解决方案。这些都有其缺陷,但更重要的是,它们始终是从头开始定制的,从而增加了项目时间和成本。

解决此挑战的通用模式可以快速轻松地应用于绝大多数情况。这将导致更快的实施和更多经过实践检验的解决方案。这是一种这样的模式的概念……

DMS事件总线架构

通过这种体系结构,旧式SQL数据库中的所有更改(支持各种DB供应商)都被推送到Kinesis事件流中,随时可以使用。剩下要做的唯一事情就是使用这些事件的自定义业务逻辑……例如,使用Kinesis Analytics运行警报,使用Lambda函数处理数据,或使用Kinesis Firehose将其归档到S3数据湖中。

All of your database changes will come onto the stream with a representation of the old data (if any) and the new data, both in JSON format. The beauty of this is that if you choose to replicate * columns in your tables, schema updates automatically flow through the system: it automatically identifies new columns and adds keys to the JSON.

因此,最终,面向行的SQL数据将最终在Lambda函数和其他使用者的Kinesis流中作为JSON元素,并为添加,编辑和删除的每个记录都带有“旧”和“新”记录。

(如果您熟悉这些组件,您可能会想知道,为什么不仅仅将Lambda从DynamoDB流中删除?我们将在下面进行解释,但简短的答案是:将多个表统一为一个流。)

让我们更详细地介绍系统的某些组件。

数据库迁移服务

这是我们以通用方式提取数据的关键。正如AWS的一些人会告诉您的那样,该服务的名称已被错误命名:最初旨在专注于一次性迁移,但由于许多客户已开始将其用于长期复制,因此应将其名称更改为“数据库复制”。服务”。 AWS接受了这一点,增加了生产就绪型复制所需的功能,例如多可用区故障转移。现在,它是长期复制的常见选择。

当然,DMS支持 各种来源清单,包括所有旧的收藏夹,例如Oracle和SQL Server。至关重要的是,由于它使用的是Change Data Capture,因此它将对源服务器的负载降至最低。这种方法比构建将读取添加到数据库中的自定义代理要有效得多。

DynamoDB

DynamoDB为我们提供了一个方便的数据航路点,原因如下:

  • DMS支持它作为目标数据存储
  • 使用NoSQL不会强加任何架构设置要求
  • 它具有一个称为 DynamoDB流 这会将对DynamoDB表所做的所有更改推送到Lambda函数可以使用的事件流中。

此功能是我们到系统下一个组件的链接。

运动学

如果您的处理需求很简单,则可以跳过此步骤,而仅在DynamoDB流之外的Lambda函数中进行数据处理。但是,在我们的参考体系结构中,通过使Lambda函数从DynamoDB流接收事件并将其放到Kinesis流中,我们将Lambda函数用作DynamoDB流和Kinesis之间的粘合剂。这有一些好处:

  • DMS为每个SQL表创建一个新的DynamoDB表,该表具有自己的流。您将需要消耗许多流才能获取所有数据。但是,Lambda函数可以放置所有表中的所有事件&流传输到单个Kinesis流,从而简化了下游消耗。
  • 运动学支持多个同时使用的使用者和一些内置的使用者类型。因此,您可以轻松地同时使用该事件,包括将其路由到…。

注意事项

需要牢记的一些重要事项:

  • 为了使DMS能够使用Change Data Capture进行工作,通常需要对源数据库进行一些调整。请仔细阅读DMS文档,以确保您可以满足这些先决条件。
  • DMS绝对是 不是没有服务器,很不幸!您必须确保适当设置磁盘空间和实例大小以处理数据量。
  • 注意DynamoDB的容量。 DMS设置表格时,默认值为一些很高的数字(200次读取&写入),如果您有很多表,将导致过多的费用。另一方面,源数据库活动的高峰可能导致DynamoDB写限制。您可能需要启用DynamoDB自动缩放功能以适当调整这些成本。

下一步

此处的所有组件都支持CloudFormation,因此下一步很重要的一点就是对该架构进行模板化,以便可以重复应用。在这种情况下,由于DMS动态创建了目标DynamoDB表,因此增加了一些复杂性,因此自动化必须足够灵活才能适应动态创建的表。但是一旦完成,该系统就可以在几分钟内启动并运行,从而使构建者可以专注于源系统配置和业务逻辑来处理传入事件。 Trek10希望在未来几个月内按照这些思路开源解决方案。

我们很高兴听到您对这个建议解决方案的想法。看到孔了吗?您是否尝试过类似的方法并且可以报告您的经历?让我们知道 @ Trek10Inc,并继续建设!

作者
安迪·沃宗(Andy Warzon)Trek10
安迪·沃宗(Andy Warzon)

创办人& CTO

创办人&CTO Andy一直在AWS上进行开发已有十多年,并且是AWS认证解决方案架构师-专业人士。