aws消息服务器,经验分享：我们如何使用AWS构建无服务器架构 - hypertrack

我们的客户使用HyperTrack无需服务器即可访问实时位置。他们将我们用作实时位置的托管服务。他们不需要构建和管理服务器来摄取，处理，存储，提供和管理与其应用用户的实时位置相关的任何内容。

而我们自己则是使用AWS为我们的平台提供无服务器架构。用于从我们的SDK中提取数据流，准确处理它们，使位置可用于实时定位功能，以及在我们的数据湖中保存数据以进行分析和机器学习; 我们通过无服务器架构利用Amazon Web Services。

在这篇博客中，我们将向您介绍并分享我们的经验。

动机

HyperTrack是一个自助式平台，用于云中的实时定位。来自世界各地的数万名开发人员都在该平台上。开发人员在他们的应用中添加我们的SDK以开始跟踪。首先，他们使用此数据在测试环境中构建功能。测试结束后，该应用程序将推广给他们的用户。HyperTrack客户按使用付费，保持完全控制其使用量上升或下降，并期望它正常工作。

反过来，我们需要构建一个可以自动扩展和缩小的系统，而无需任何工程干预。我们无法预测，手动配置或取消配置服务，也无法深入了解客户在22个时区的推广周期。此外，这些服务需要具有低延迟响应，实时处理，高可用性平台和可靠的基础架构。

无服务器赢得胜利！我们使用的AWS组件旨在自动扩展，无需任何操作或管理工作。

定位服务详解

看看这个平台是怎么运行的：让我们看一下身份验证，摄取和处理部分：

1.客户应用程序中的HyperTrack SDK通过HTTP post请求向HyperTrack提取管道发送位置和相关上下文(活动，权限，电池等)。

2. API网关端点接收位置事件，检查授权标头并将数据记录放在我们的主Kinesis流上

3. Kinesis可靠地缓存数据，将我们的端点与处理资源分离，并使其可用于实时处理

4. Kinesis，DynamoDB流或其他lambda 调用各种形状和大小的Lambda函数来处理精确位置，过滤噪声并转换上游接口和应用程序的数据

5. DynamoDB仅存储实时位置，将有用位置存档到S3以供将来使用，并丢弃其余部分

现在，让我们回顾一下如何利用存储和存档的数据将其公开给我们的开发人员：

6.位置，上下文和设备数据转换为JSON格式，并通过公共REST API公开。使用基本访问身份验证控制对这些端点的访问

7.   AWS SNS验证订阅并处理Webhook调度

8. AppSync为各种Web和本机前端应用程序提供GraphQL端点，以便通过查询和订阅进行使用。

效果

我们对该平台进行了压力测试，然后自豪地向全世界宣布。一切都好。

与不同时区的客户一起抱怨抱怨API延迟和降低性能已经成为过去。成本控制良好，按使用付费的价格非常适合我们。在无服务器平台上托管的新版本的前几个峰值得到了优雅的处理，并没有在口袋中烧掉一个洞。所需的行政和监督也是最低限度的。

然后一个晴朗的早晨，API流量突然达到顶峰....

好消息是：API延迟、正常运行时间和实时性能都很正常。无服务器架构已经自动扩展，以处理比前一天高2-3个数量级的流量。但是，您不希望CFO看到这一点。

在最初几天内，数百万台设备注册了HyperTrack服务器。由于集成导致了错误：设备注册发生在应用程序启动时，而不是在启动跟踪的时候。我们的平台与位置时间序列类似地处理这些事件，并轰炸了我们的实时数据管道，虽然无意中，但它对我们的无服务器架构进行了令人敬畏的压力测试。

基础架构即代码和持续集成与部署

无服务器模式的好处是惊人的，我们发现自己很快就在我们的平台上使用它。现在我们运行数百个Lambda函数，在几乎同样多的DynamoDB表中存储数据，并利用其他几十个亚马逊服务来使我们的平台在我们的环境中工作。

管理大量资源并将它们相互连接起来的复杂性只能通过强大的自动化来管理。将所有基础架构定义为代码对于实现自动化至关重要。幸运的是，我们都非常信任自动化，并从一开始就使用IaC构建HyperTrack。

我们从Terraform开始使用配置文件定义所有资源。选择Terraform是因为开源性质和强大的社区支持。它帮助我们之前的一些人在其他项目中使用它。Terraform非常适合定义共享和静态基础架构。另一方面，必须单独定义每个资源太冗长(参见HashiCorp教程)并妨碍快速迭代产品功能。通过这种学习，我们转向无服务器框架，用于非共享基础架构部件。

Serverless是另一种开源工具，具有很强的采用率，专注于简单的开发人员体验。采用该框架减少了自定义自动化脚本和样板代码的数量。平台工程师能够更快地移动并更轻松地维护代码库。

无服务器服务通常需要了解Terraform部署的共享资源。为了支持这一点，我们将资源从Terraform写入AWS Systems Manager(SSM)并从Serverless读取SSM。与Serverless中此博客中描述的模式类似。

对于Terraform基础架构，开发人员正在运行Jenkins作业来部署更改。在应用基础架构变更之前，我们运行“terraform计划”以了解在不进行任何实际更改的情况下添加和删除哪些资源。此过程可降低共享和关键基础架构被破坏或受到其他影响的风险，但需要额外的工程监督。

对于所有其他服务，我们使用CircleCI持续构建，测试和部署。这是另一种无需服务器即可实现CI / CD实现全自动化而无需维护自己的基础架构的方法。此外，我们已经看到了允许平台工程师更快地迭代的巨大成功。