優步的緊急按鈕及其背後的技術

banq發表於2022-04-06

uber的緊急按鈕的第一個版本於 2015 年在印度推出。原始系統允許乘客和司機在留在應用程式內的同時聯絡當地警察當局，並自動提醒區域支援團隊主動聯絡使用者。2018 年，該團隊利用增強功能改進系統，例如在應用程式中顯示實時位置資訊、與當局共享旅行詳細資訊以及製作緊急按鈕可在全球市場的 Rider 和 Driver 應用程式上使用。從那時起，該團隊透過引入使用者可以謹慎地向當地警察傳送簡訊而不是僅呼叫選項的功能，在特定市場進行了額外的改進。此外，在特定市場，我們推出了互動式語音響應解決方案，為我們的使用者提供後續服務。

點選緊急援助功能後，您將看到您的 GPS 位置、汽車品牌和型號以及車牌。如果您刷卡撥打 911並連線到緊急排程員，這些行程詳細資訊將在美國和墨西哥的許多城市以數字方式提供給他們，並可用於促進緊急響應。優步的支援團隊將跟進辦理登機手續，以確保您的安全。               

在緊急情況下，幾秒鐘都很重要。重要的是要確保人們在正確的時間擁有正確的資訊（實時位置和行程資訊），這樣他們就能迅速與當局分享。如果出行資訊和實時位置能自動與當局如911中心共享，那將更有幫助。

RapidSOS 整合和持續位置共享
團隊與第三方RapidSOS合作，後者將數百萬連線裝置的潛在救生資料直接提供給 911 和緊急情況下的第一響應者。
緊急按鈕與RapidSOS 的緊急 API整合，並向 911 急救人員提供行程資訊（汽車品牌、型號、車牌和請求者姓名）和實時位置更新。 

當有人點選應用程式中的緊急按鈕時，移動客戶端透過閘道器代理向緊急事件後臺服務發出請求。然後，緊急服務將行程資料傳遞給RapidSOS的API。同時，移動客戶端上的位置工作者每隔幾秒鐘就會收集並上傳位置資料到位置服務。這些實時位置更新透過Kafka流向緊急服務。Emergency Service不斷向RapidSOS的Location API發出HTTP請求，以提供實時位置資料。我們非常重視使用者的隱私，所以系統嚴格尊重使用者的許可，與RapidSOS和當局等第三方分享行程和位置資訊。

這個來自華盛頓特區的NBC片段強調了這種整合如何幫助解決現實世界中的緊急事件。目前，RapidSOS的整合在大約1200個市場中可用，覆蓋了美國74%以上的行程，以及墨西哥的幾個城市。該團隊正在繼續努力將這一功能擴充套件到美國和全球越來越多的地區。

使用 Apache Kafka 進行可靠的再處理和 DLQ
警報通道採用技術堆疊實現，強調冗餘和彈性。Uber的Kafka團隊在Apache Kafka之上開發了內部的Kafka APIs，Uber的內部服務可以與之整合，以產生和消費Kafka事件。Kafka APIs提供了一個至少一次的交付保證：一個Kafka事件至少會被交付給它的消費者一次--換句話說，沒有資料損失。另外，消費者可以為Kafka主題啟用DLQ（死信佇列）功能。

內部的Kafka APIs很適合增強應急服務的可靠性，以實現可靠的處理。對於每個警報通道，應急服務透過Kafka APIs向特定的Kafka主題生產和消費。對下游依賴的RPC在消費者處理程式中處理，緊急服務將向Kafka API返回ACK（成功）或NACK（失敗）。對於緊急服務的伺服器錯誤或網際網路故障返回的任何型別的可重試錯誤，對Kafka伺服器來說都會轉化為NACK。Kafka伺服器將繼續重新處理該事件，進行配置的重試次數。如果在所有重試之後，Kafka事件仍然不能被成功處理，事件將被推送到DLQ中。儲存在DLQ中的訊息如果是壞訊息可以被清除，或者在系統恢復後被合併（由消費者重新處理）。

一次性傳遞和DLQ機制有助於應急服務的容錯性，沒有資料損失，並且能夠在恢復期間快速重新處理。

冗餘是關鍵
任何系統都有可能出現一些意想不到的錯誤，緊急服務為每一個RPC或訊息傳遞（Kafka）建立了多層冗餘和備份，以便在處理緊急請求時盡最大努力。

每個RPC都是透過重試來實現的，重試的結果是指數級的。在Kafka APIs不可用的情況下，緊急服務會回落到對下游的RPC呼叫，並有一定數量的重試作為優雅的降級。

詳細點選標題
 

相關文章