使用 Azure 构建解决方案

5 分钟

要创建应用程序体系结构，需要了解功能性要求和非功能性要求的范围，然后将这些要求与可满足这些要求的工具、技术和服务进行配对。

在乘车场景中，有几个主要要求：

用于监视公交车实时位置的网站
公交车驶近时的通知
自动部署和缩放

让我们更深入地探讨此场景，了解如何使用各种 Azure 服务构建解决方案。

检索实时公交数据

许多城市通过通用运输提要规范 (GTFS) 提供公共交通数据，该格式还支持称为 GTFS 实时参考 v2 (GTFS-RT) 的实时信息源。信息源由 JSON 文档组成，如下例所示（来自金县公交信息源）：

{
      "id": "1618418866_4318",
      "vehicle": {
        "trip": {
          "trip_id": "49195161",
          "direction_id": 0,
          "route_id": "100001",
          "start_date": "20210414",
          "schedule_relationship": "SCHEDULED"
        },
        "vehicle": {
          "id": "4318",
          "label": "4318"
        },
        "position": {
          "latitude": 47.64524,
          "longitude": -122.370171
        },
        "current_stop_sequence": 228,
        "stop_id": "2010",
        "current_status": "IN_TRANSIT_TO",
        "timestamp": 1618418841
      }
    },

在知悉此类信息源可用后，接下来需要弄清楚的是如何在公交车离你足够近时收到通知，以便及时步行到公交车站以准时赶上公交车。为此，我们可以在预定的车站之前创建几个公共汽车站的地理围栏。这样，当公共汽车进入或离开地理围栏时，你会收到通知。如果在发生这种情况时可以获得通知，甚至无需一直在地图上查看公交车的位置。收到通知时，你就会知道是时候离开了。

使用 Azure 服务构建解决方案

根据场景和理想解决方案，下面是一个可能的体系结构：

乘车微服务体系结构示意图。

该体系结构使用几种不同的服务来尽量减少需要编写的代码量，并最大限度地利用 Azure 提供的可伸缩性和基础结构优势。

已知文本 (WKT) 是一种纯文本标记语言，用于在地图上表示矢量几何位置。 WKT 是一个开放地理空间信息联盟 (OGC) 标准，用于以文本格式表示空间数据。大多数符合 OGC 的系统都支持已知文本。

在这里，你将大致了解选择了哪些解决方案组件及其选择原因。然后在本模块中，你将重点了解数据库服务。

使用 Azure SQL 数据库存储和处理数据

Azure SQL 数据库与该场景非常契合。让我们了解一下原因。

Azure SQL 数据库具有原生 JSON 支持，这有助于减少操作数据库发送和接收的数据所需的代码量。得益于 JSON 的灵活性，它还使得解决方案更加敏捷、更易于改进。此外，它还确保你可以有效地将数据的数组传递给 Azure SQL、优化往返并降低延迟。

Azure SQL 还提供完整的地理空间支持，这是一项很好的功能，因为操作地理空间数据并不是一件非常容易的任务。通过在数据库中包含一个功能齐全的地理空间引擎，你可以避免与外部库集成的复杂性。你也不必四处移动数据来确定一些内容，例如某辆公交车是否在定义的地理围栏内。由于 Azure SQL 遵循开放地理空间信息联盟标准，因此可以轻松地将存储在 Azure SQL 中的数据与 OpenLayers 等可视化库集成。

上述功能建立在关系模型坚实的基础上，经过多年的改进，以满足新式应用程序的要求。使用超大规模层的 Azure SQL 数据库可缩放最多 100 TB，这意味着它可用于存储密集型应用程序（例如大型数据库）。使用无服务器层（支持自动缩放和暂停和恢复）时，Azure SQL 数据库也很划算。 Azure SQL 还支持用于快速分析查询的列存储索引、用于简化复杂对象关系管理的图形模型，以及持续改进并可处理最严苛的工作负载的最先进查询优化器，例如当今大型多人在线游戏所需的工作负载。

使用 Azure SQL 可以轻松访问静态数据，如 GTFS 标准提供的路线信息，这些数据可以存储在 Azure Blob 存储帐户中。我们可以使用 Azure SQL 中的 OPENROWSET 函数从文本文件导入数据，而无需其他服务。这样，我们就可以最大程度地降低解决方案复杂性。

出于这些原因，Azure SQL 数据库非常适合像乘车应用这样的应用程序；在这类应用中，你要处理 JSON 和地理空间数据，但还希望利用引擎中内置的数据访问和过程功能。 Azure SQL 数据库无服务器是满足自动缩放要求的极佳选择，它使应用程序能够处理一天中更多人试图乘车的繁忙时段。 Azure SQL 数据库还支持持续集成和持续交付/持续部署 (CI/CD) 技术（如 Azure DevOps 和 GitHub Actions），这使部署自动化更简单。

使用 Azure Functions 生成 API 服务

你需要 API 来访问和使用 GTFS 信息源，从而在公交车进入地理围栏时通知用户，并向 Web 应用程序提供数据。由于 Azure Functions 的简洁和无服务器体系结构，你选择了它作为首选服务。 Azure Functions 是一项很棒的服务，它的无服务器特性可自动缩放到你所需的功能，将基础结构的几乎所有方面都留给 Azure Functions 来处理。 Azure Functions 提供对不同语言的支持，因此你可为正在处理的任务选择你喜欢的或最适合的语言，这按照纯微服务方法实施。

通过 Azure 逻辑应用发送通知

若想收到通知来知道公交车进入地理围栏中且你需要起身步行到公交车站，Azure 中的一个选项是使用 Azure 逻辑应用。 Azure 逻辑应用具有大量的连接器，因此你可与其他服务集成。例如，你可使用 Azure 逻辑应用发送短信，或者从 Outlook 或 Gmail 帐户发送电子邮件。 Azure 逻辑应用的出色之处在于它是一个低代码/无代码平台，因此设置乘车通知服务很简单，鼠标操作几下即可完成。

使用 Azure Static Web Apps 托管 Web 应用程序

若要直观呈现地理空间数据来表示地图上的地理围栏和公交位置，可使用熟知的 jQuery 和 OpenLayers 库创建一个静态 HTML 页面。静态页面将需要从服务器端 REST API 获取数据，该 API 将由另一个 Azure 函数提供。由于要使可视化页面生效需要客户端和后端部件，因此可利用 Azure Static Web Apps。借助 Azure Static Web Apps，可轻松地开发和部署解决方案，因为它结合了 Azure Web 应用和 Azure Functions 的功能，还与内置的 GitHub Actions 相集成。

使用 GitHub Actions 自动部署

如你所见，完整的解决方案由几个活动部件组成：从实时信息源提取数据的后端服务，用于存储、处理数和提供数据的数据库，以及由一个静态 HTML 文件和一个 REST API 终结点组成的前端可视化解决方案。如果通过 GitHub Actions 使用 CI/CD 管道，每次提交更改时，都会通过 GitHub 和 Visual Studio Code 自动部署所有组成部分。数据库更改（如果有）连同 Azure Functions 和 Azure Static Web Apps 更改将以完全自动化和协调的方式进行部署。