使用 Azure 建構解決方案
建立應用程式結構時，您需要了解功能性和非功能性需求的廣度，然後針對這些需求，搭配可解決這些需求的工具、技術和服務。
在搭公車案例中，有幾個主要需求:
- 監視公車即時位置的網站
- 公車接近時的通知
- 自動部署和調整
讓我們更深入探討此案例，以及您如何使用各種 Azure 服務來建構解決方案。
取出公車即時資料
很多城市透過通用運輸資訊規格 (GTFS) 來提供公共運輸資料，此規格也支援名為 GTFS 即時參考 v2 (GTFS RT) 的即時摘要。 摘要由 JSON 文件組成，如下列範例所示 (來自 King County Metro 摘要)：
{
"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 Database 儲存和處理資料
Azure SQL Database 很適合此案例。 讓我們了解原因。
Azure SQL Database 有原生的 JSON 支援，這有助減少透過資料庫處理傳送和接收資料所需的程式碼數量。 由於 JSON 的彈性本質，解決方案也更靈活且容易改善。 也可確保有效率地將資料陣列傳遞至 Azure SQL、將來回行程最佳化，並減少延遲。
Azure SQL 也提供完整地理空間支援的絕佳功能，因為處理地理空間資料實在不簡單。 透過在資料庫中擁有一個功能齊全的地理空間引擎，您可以避免與外部程式庫整合的複雜性。 例如，如果公車位於定義的地理柵欄內，您也不需要移動資料來找出資料。 因為 Azure SQL 遵守開放地理空間協會標準，您可以輕鬆整合 Azure SQL 中儲存的資料與視覺效果程式庫，例如 OpenLayers。
上述功能依賴關聯式模型的穩固基礎，經過多年來的改進發展，符合現代化應用程式的需求。 Azure SQL Database 可透過超大規模資料庫層擴充至 100 TB，這表示您可以將其用於需要大量儲存空間的應用程式 (例如大型資料庫)。 當您使用支援自動調整和暫停與繼續的無伺服器層時，Azure SQL Database 也符合成本效益。 Azure SQL 也支援疾速分析查詢的資料行存放區索引、簡化複雜物件關聯性管理的圖表模型，及持續改善的最先進查詢最佳化工具，這個工具甚至可處理最嚴苛的工作負載，例如當今大型多人線上遊戲所需的工作負載。
Azure SQL 讓您輕鬆存取可儲存在 Azure Blob 儲存體帳戶中的靜態資料，例如 GTFS 標準提供的路線資訊。 我們可以使用 Azure SQL 中的 OPENROWSET 函式，從文字檔匯入資料，而不需要其他服務。 這可讓我們將解決方案的複雜性降到最低。
基於這些理由，Azure SQL Database 很適用於搭公車之類的應用程式，因為您不僅需要處理 JSON 和地理空間資料，還想利用引擎內建的資料存取和程序功能。 Azure SQL Database 無伺服器是滿足自動調整需求的絕佳選擇，讓應用程式可以處理較多人趕搭公車的繁忙時段。 Azure SQL Database 也支援 Azure DevOps 和 GitHub Actions 等持續整合和持續傳遞/持續部署 (CI/CD) 技術，以簡化部署自動化。
使用 Azure Functions 建立 API 服務
不論是存取和取用 GTFS 摘要、在公車進入地理柵欄時通知使用者，還是提供資料給 Web 應用程式，您都需要 API。 由於 Azure Functions 的簡易性和無伺服器架構，您已將之選為最適合的服務。 Azure Functions 的無伺服器本質可自動調整，滿足所需，因而成為絕佳的服務，基礎結構的各方面幾乎都可交由 Azure Functions 處理。 Azure Functions 支援不同的語言，您可以選擇慣用的語言，或根據執行的工作選擇適合的語言，完全遵循微服務的方法。
使用 Azure Logic Apps 傳送通知
若要在公車進入地理柵欄時，通知您前往公車站，Azure 其中一個選項是使用 Azure Logic Apps。 Azure Logic Apps 擁有大量連接器，可讓您與其他服務進行整合。 例如，您可以使用 Azure Logic Apps 傳送手機簡訊，或從 Outlook 或 Gmail 帳戶傳送電子郵件。 Azure Logic Apps 的優異之處在於低程式碼/無程式碼平台，所以設定搭公車的通知服務很簡單，您只要按幾下滑鼠就能完成。
使用 Azure Static Web Apps 裝載 Web 應用程式
若要將地理空間資料視覺化，在地圖上顯示地理柵欄和公車位置，您可以使用知名的 jQuery 和 OpenLayers 程式庫，建立靜態 HTML 網頁。 靜態頁面需要從伺服器端的 REST API 擷取其他 Azure Function 將提供的資料。 由於視覺效果頁面需要用戶端和後端組件才能運作，您可以利用 Azure Static Web Apps。 Azure Static Web Apps 結合 Azure Web Apps 和 Azure Functions 的功能，並整合內建的 GitHub Actions，讓您輕鬆開發和部署解決方案。
使用 GitHub Actions 自動化部署
如您所見，完整的解決方案是數個活動組件構成：後端服務從即時摘要提取資料，資料庫儲存、處理和提供資料，還有前端視覺效果解決方案是由靜態 HTML 檔案和 REST API 端點組成。 只要透過 GitHub Actions 使用 CI/CD 管道，每次認可變更時，即可透過 GitHub 和 Visual Studio Code 自動部署所有程式碼片段。 任何資料庫變更及 Azure Functions 和 Azure Static Web Apps 變更，將會經過協調而完全自動部署。