为了在云中创建一个真正可靠和高度可扩展的平台，企业往往发现他们必须结合技术来满足他们的实时需求。许多企业都在为实时流功能而苦恼，因为要优雅地完成并满足有效的数据转换和数据移动的要求是很有难度的。
为了创建一个基于云的动力源，你需要结合能够互补彼此优势的工具。我们最喜欢的组合之一是AWS和Confluent。AWS是可扩展性和灵活性的标准云供应商，特别是对于那些使用AWS无服务器服务的人。Confluent是满足消息传递、流媒体和实时需求的最佳选择。它们共同创造了一种协同效应，帮助企业应对其数据敏捷性需求。
AWS的优势
单独结合AWS服务，对您的企业来说是一个坚实的解决方案。但是，当与Confluent适当结合时，这些优势可以大大扩展和增强AWS的功能。
数据转换（特别是在规模上）
AWS在管理大规模的数据转换和并行处理方面表现出色。
Amazon EMR、Amazon Batch和AWS Lambda都适用于此，各有各的用途。
- 如果你想把一个集群专门用于大型数据转换，可以使用Amazon EMR 。
- 亚马逊Batch 可以用于大型批处理，以自动扩大和缩小规模。
- AWS Lambda 可以用来以无可比拟的速度并行执行自定义数据转换。
Confluent作为入站或出站连接点，是AWS数据转换流程的优秀合作伙伴。如果源很容易使用预建的Confluent源连接器连接到Confluent，如Salesforce，Confluent可以作为一个入站网关。
另一种相反的情况是使用Confluent为转换后的数据提供出站连接。在这种情况下，AWS会将处理后的数据发回给Confluent。然后，Confluent Topic通过Salesforce Sink Connector的方式将促进数据发送到Salesforce。
APIs
亚马逊的API网关允许开发人员快速创建RESTful APIs，并轻松地将它们与其他RESTful APIs或亚马逊服务集成。这个功能只以亚马逊API网关为中心。
API是Confluent是亚马逊方程中完美的 "另一半 "的另一个案例。Confluent不提供创建API的能力，所以当你使用Confluent时，你需要一个能创建API的工具。对于这个目的，AWS是一个自然而然的合理选择。
以这种方式与Confluent结合，AWS作为API提供者，亚马逊API网关与AWS Lambda等服务集成，接受请求，执行数据清理和处理。然后，Lambda可以将请求发送到Confluent Topic，允许将数据发送给该主题的订阅者。
值得注意的是，这对于异步API响应来说是很好的，但对于需要同步响应的API来说就不一样了，因为在这种情况下，数据是立即需要的。异步响应之所以有效，是因为亚马逊API网关在向Confluent主题发送事件后可以提供一个202接受的响应。
长期存储
很少有集成是不需要长期存储数据的。无论你是为了多年后的查询而存储事件，还是为了信息的分类账、系统事件和日志，或者有其他需求，长期存储都是必须的。
AWS有几个服务可以帮助解决这个问题。
- 亚马逊S3
- 亚马逊RDS
- 亚马逊ElasticSearch
将这些存储解决方案与Confluent结合起来，可以满足许多用例。
- **Confluent日志存储。**Confluent的日志可以被运送到AWS并存储在ElasticSearch中。然后，你可以为你的系统定义KPI，并使用ElasticSearch仪表盘对这些KPI的性能进行可视化。
- 原始消息的存储和处理。亚马逊API网关可以接受原始消息并将其存储在S3中，这样数据就不会丢失。然后，如上节所述，API Gateway可以通过AWS Lambda将事件发送到Confluent。
- 与SQL配对。Confluent有一个MySQL连接器，还有其他几个。事件可以在Confluent Topics上接收，然后通过管道传输到运行MySQL的Amazon RDS。
处理层
许多Confluent客户需要一个处理层来托管Kafka KStream应用程序，或者对通过Confluent平台的消息进行额外的处理。这并不是一个不常见的要求。这几乎是每一个集成项目的基本需求，可以根据架构的最佳实践来实现，将消息传递或流媒体层与处理层解耦。
在亚马逊方面，AWS Lambda和亚马逊EC2是使处理层成为可能的两项服务。
当与Confluent结合时，有两个明确的用例。
在第一个案例中，Confluent使用Java Kafka KStream API接受消息和流到驻扎在Amazon EC2上的KStream应用程序。然后，KStream应用程序在亚马逊生态系统内处理数据，并将消息发回给Confluent。否则，这些消息可以在AWS生态系统中降落，并坚持到AWS数据库中。
第二种是使用Confluent的AWS Lambda Sink连接器，将消息从Confluent发送到AWS Lambda。在这种情况下，Lambda被调用，以便用你选择的语言处理消息。它可以将消息送回Confluent，或者如上所述，它可以将消息放在AWS生态系统中，并将其持久化到AWS数据库或其他存储中。
DevOps
DevOps应该被纳入任何现代集成项目。我们对这一想法深有感触，所以我们写了一本电子书，帮助企业在无服务器环境下实施DevOps。
AWS为DevOps流程提供了优秀的工具，包括CI/CD管道和源控制的自动化。有大量的亚马逊服务可以很好地发挥和支持DevOps。
- AWS CodePipeline
- AWS CodeBuild
- AWS CodeDeploy
- AWS CodeCommit
- AWS Elastic Beanstalk
- AWS SAM
- AWS上的客户脚本
自动化是将AWS DevOps工具与Confluent相结合的一个重要好处。例如，AWS可以为您系统中使用的所有代码进行自动化治理、测试和部署。例如，如果你使用Java KStreams API来开发KStreams应用程序，你可以将该代码检查到AWS CodeCommit中，并使用Elastic Beanstalk或CodePipeline、CodeBuild和CodeDeploy的组合将该代码自动部署到自动扩展的亚马逊EC2集群。
你也可以使用Confluent API或CLI来自动创建Confluent主题。你为实现这一目标而创建的客户脚本可以在AWS上运行，并通过CI/CD服务进行管理，以实现Confluent部署的自动化。
服务器、网络和文件系统
对于有严格的网络安全需求的组织来说，AWS是一个不折不扣的选择，或者如果你需要为你的集成工作使用一个文件系统。AWS提供多种服务器、网络和文件系统解决方案，这取决于您的具体要求和使用情况。
- 亚马逊EC2
- 亚马逊ECS
- 亚马逊EKS
- 亚马逊EFS
- 亚马逊VPC
当Confluent与亚马逊解决方案相结合时，您的KStream应用程序可以被部署到EC2自动扩展集群。KStream应用程序可以访问生活在Amazon EFS上的共享文件系统。同样的事情也可以使用Amazon ECS和EFS而不是Amazon EC2来实现。在这两种情况下，你都可以使用亚马逊VPC组件，包括安全组和网络ACL来锁定你的网络安全。
Confluent的优势
你可能会从另一个方向来看待这个组合；也许是Confluent的价值让你考虑如何让它对你的业务更加强大和有价值。下面是Confluent的一些优势，以及AWS如何加强这些优势。
数据暂存和聚合
对于集成来说，将一个对象与另一个对象，甚至与许多其他已经通过集成系统历史的对象联系起来是很常见的。Confluent在这方面表现出色，因为你可以在KTables或ksqlDB中维护所有的历史日志。这样就有可能把那些新事件和旧事件联系起来，汇总数据，并在滚动窗口中分阶段发送，以等待新的更新，比如，10分钟或任何适合你的应用的时间。
与此相关的Confluent服务包括。
- KTable
- ksqlDB
同样，数据暂存和聚合是Confluent大放异彩的一个领域。与AWS配对，Confluent可以接收从AWS发送过来的用于暂存和聚合的数据，在这些事件通过API被接受之后。然后，Confluent可以通过Confluent Lambda Sink Connector将这些聚合和分阶段的数据送回AWS进行进一步处理，并通过RESTful HTTPS连接发送到下游的Web服务器。
有序的事件
对于许多集成模式，包括系统同步，参考完整性是一个需要解决的巨大组成部分。大多数工具在发送对象到目标系统之前，都会面临确保数据引用有效的挑战。Confluent用KTables或ksqlDB完成了这一点。
在Confluent这边，对有序事件很重要的服务包括。
- KTable
- ksqlDB
- KStream
- 主题
AWS如何能让这一切变得更好？想象一下，Confluent使用Confluent Salesforce Source Connector接受来自Salesforce的平台事件。如果一个子数据对象首先从Salesforce到达，Confluent可以在等待父对象的同时将其保留一段可配置的时间。一旦父对象到达，它可以重新排列Confluent Topic中的事件，然后将这些事件按顺序发送到AWS，这样AWS就可以将这些消息正确地传递给下游的Web服务器：先是父对象，然后是子对象。例如，这可以适用于员工和主管之间的关系。
连接器
在今天这个快节奏的世界里，加速集成连接是最重要的。交钥匙解决方案有助于推动创新，这是集成的一个重要驱动力。Confluent专注于他们的连接器生态系统，以帮助实现这一目标，并从社区采购连接器。这使他们能够与一些需求量最大的解决方案建立连接，如Salesforce、MongoDB和Oracle。Confluent Connectors和Confluent Topics的结合使得这些集成能够被无缝地、优雅地设置起来。
在与上述类似的情况下，请求可以在AWS上通过Amazon API Gateway接受，然后在Lambda中处理。然后Lambda可以将消息发送到Confluent Topic，这样Confluent就可以使用其连接器之一将数据发送到目标系统，如MongoDB。
实时流
实时流在集成领域变得越来越普遍。随着使用量的增加，需要更多的实时数据，而Confluent是满足这些需求的完美解决方案。Confluent在提供出色的可扩展性的同时，还提供低延迟的消息处理，即使是轻量级的转换和数据充实。这意味着Confluent可以满足最苛刻的实时流媒体的需求。
使用Confluent Topics和KStreams使之成为可能。在这种情况下，AWS开始发挥作用，支持Kafka的可扩展性。Kafka需要强大的基础设施、内存使用和文件系统使用：这些都是AWS可以提供的。Kafka可以安装在AWS EC2自动扩展组、Amazon EKS或Amazon ECS上，并与Amazon EFS相结合，形成一个高度可扩展的文件系统，使Kafka能够每秒处理数百万条记录。使用confluent Topics和流式数据到AWS上托管的KStreams支持这个用例的实现。
总结
Confluent是数据移动和数据流能力的缩影。AWS是Confluent技术的完美合作伙伴，因为它用高度可扩展的服务完善了Confluent的数据敏捷性专业知识，以支持实时流的高要求。AWS还解决了Confluent在数据存储和静止数据方面的需求，这些都是强大的集成战略所必需的。
