Uber 的Greenlight Hubs (GLH) 在全球擁有700 多個分支機構，為司機合作伙伴提供從賬戶和支付到車輛檢查和車主登記等各個方面的人力支持。為了給合作伙伴司機創(chuàng)造更好的體驗并提高客戶滿意度，Uber 的客戶優(yōu)先工程團隊開發(fā)了內部客戶支持系統(tǒng)，該解決方案可以通過GLH 實現(xiàn)更簡化、更快速的支持請求。

客戶支持系統(tǒng)由兩個主要功能組成：登記隊列系統(tǒng)，供我們的服務專家跟蹤駕駛員進入GLH；以及一個預訂系統(tǒng)，允許司機通過優(yōu)步司機應用程序安排人工支持預約。自2017 年3 月推出以來，這些工具改善了世界各地司機合作伙伴的支持體驗。

過渡到本地解決方案

隨著Uber 的發(fā)展，我們之前的客戶支持技術無法很好地擴展，無法為我們的司機合作伙伴提供最佳體驗。通過開發(fā)我們自己的GLH 客戶支持系統(tǒng)，我們提出了一個適合我們的可擴展性和定制需求的解決方案，同時改進了現(xiàn)有基礎設施以支持新功能。

開發(fā)我們自己的工具意味著我們可以：

方便地獲取客戶支持需求的信息：我們的注冊系統(tǒng)使客戶支持代表可以更輕松地獲取解決駕駛員問題所需的相關信息。這種集成有助于減少支持解決時間并改善駕駛員使用GLH 的體驗。

駕駛員溝通渠道的融合：Uber 各種支持渠道（包括應用內消息、GLH 本身和電話支持）的集中意味著GLH 專家擁有額外的上下文信息，可以在一處解決駕駛員問題。

減少司機伙伴在GLH 的等待時間：使用我們升級的系統(tǒng)，司機伙伴可以通過安排預約來避免高峰時段不必要的等待時間。

為了實現(xiàn)這些目標，我們?yōu)閮炔靠蛻糁С制脚_開發(fā)了兩種新工具：登記隊列和預訂系統(tǒng)。

更順暢的入住體驗

通過在我們的客戶支持平臺上設計和實施的實時簽到系統(tǒng)，為合作伙伴司機提供更加無縫的支持體驗。使用該系統(tǒng)，司機可以向禮賓人員辦理登記，然后禮賓人員根據(jù)與其帳戶關聯(lián)的電話號碼或電子郵件地址找到司機的個人資料。

一旦司機注冊，GLH 專家就會從站點的隊列中選擇他們。然后，駕駛員將在手機上收到一條推送消息，并在GLH 內部進行監(jiān)控，通知他們已與專家配對。一旦司機與支持臺通知中指定的專家會面，司機將退出簽到隊列。

我們的實時登記系統(tǒng)還聚合客戶信息，例如過去的旅行和支持信息，使我們的專家能夠盡可能有效地解決問題。

圖1: 在GLH中，與專家配對時監(jiān)控會向用戶發(fā)出警報

提供實時專家隊列

創(chuàng)建這個實時簽到解決方案時遇到了一些困難。我們面臨的一個挑戰(zhàn)是在專家宣布駕駛員已得到協(xié)助的情況下防止專家沖突。為了實現(xiàn)這一目標，我們的系統(tǒng)提供了一個等待支持的駕駛員隊列（稱為我們的GLH 站點隊列），通過該隊列，專家可以與等待的駕駛員配對，并在選擇駕駛員時實時通知他。

由于WebSocket 協(xié)議支持低延遲的長連接，因此我們利用它通過后端發(fā)送隊列更新。 Go 是許多Uber 后端服務的首選語言，它允許我們使用管道和協(xié)程技術，從而更輕松地向Web 客戶端提供實時更新。

盡管如此，我們在使用WebSocket 時遇到了一些有趣的挑戰(zhàn)。為了使我們的站點隊列實時工作，我們決定維護特定站點到固定主機的所有WebSocket 連接和隊列寫入。這樣，當隊列中的注冊或預訂更新時，所有相關的連接客戶端也會更新。使用單個主機來處理這些請求需要在我們編寫WebSocket 并將其連接到主機之前在應用程序層進行分片。

我們使用了Ringpop-go，這是我們?yōu)镚o應用程序提供的開源可擴展且容錯的應用程序層分片，它有助于配置分片鍵，以便具有相同鍵的所有請求都將被路由到同一主機。對于我們的分片鍵，我們使用了GLH 站點ID，因此同一GLH 上發(fā)生的所有注冊都會轉到同一主機并更新相關客戶端上的所有站點隊列。

圖2: 我們的面對面支持架構利用前端WebSocket 連接到具有特定GLH 的主機。來自活動數(shù)據(jù)中心的GLH 專家前端和移動客戶端的請求通過Ringpop 進行拆分，并分配給擁有給定GLH 的主機。來自非活動數(shù)據(jù)中心的請求將被重定向到活動數(shù)據(jù)中心。與個人支持相關的數(shù)據(jù)存儲在Uber 的內部數(shù)據(jù)存儲Schemaless 中

實現(xiàn)跨數(shù)據(jù)中心的高可靠性

為了保證我們的GLH軟件順利運行，我們需要保證高可用性。為此，我們的服務在多個數(shù)據(jù)中心運行，處理來自世界各地的請求。如果數(shù)據(jù)中心因某些不可預測的原因（例如中斷）而宕機，服務將自行恢復并繼續(xù)從其他數(shù)據(jù)中心運行。

鑒于我們使用WebSocket，在多個數(shù)據(jù)中心運行該服務會帶來一系列困難。如果數(shù)據(jù)中心出現(xiàn)故障，我們就必須重新思考如何正確處理WebSocket。雖然Ringpop 分片在跨數(shù)據(jù)中心運行良好，但它會增加延遲，因為每次主機離開或進入環(huán)時都會發(fā)送跨數(shù)據(jù)中心請求。

為了解決WebSocket 降級問題，我們配置了系統(tǒng)，以便每個數(shù)據(jù)中心都有一個環(huán)；這樣，如果具有相同唯一GLH ID 的兩個請求到達兩個不同的數(shù)據(jù)中心，它只會更新隊列數(shù)據(jù)中心中我們的托管站點站點隊列。無論請求來自哪個數(shù)據(jù)中心，我們都會將所有請求轉發(fā)到固定的數(shù)據(jù)中心。如果數(shù)據(jù)中心出現(xiàn)故障，我們會將請求轉發(fā)到其他數(shù)據(jù)中心。我們還將終止與故障數(shù)據(jù)中心建立的所有WebSocket 連接，并重新建立與新數(shù)據(jù)中心的連接。

添加預約

為了減少GLH 的等待時間并確保我們在高峰時段提供足夠的支持，我們推出了一項新功能，讓我們的司機合作伙伴只需在Uber 應用程序上輕松點擊幾下即可提前安排GLH 預約。

圖3: 我們的面對面支持預約安排流程使司機合作伙伴能夠

在我們的綠光中心輕松安排預約

圖4: 當合作伙伴的應用程序到達Greenlight Hub 時，他們會在Uber 合作伙伴應用程序中收到簽到通知。

盡管作為司機安排預約很簡單，但為了使整個過程盡可能順利，幕后還有很多工作要做。例如，GLH 經(jīng)理可以隨時指定在其中心工作的專家數(shù)量，以確保其團隊不會超額預訂；然后，當司機進入應用程序時，他們只會看到基于專家數(shù)量的可用預約數(shù)量。例如，如果某個GLH 周二上午9 點只有四名專家在工作，該中心的經(jīng)理可以設置當時的預約容量為4 人，從而限制可用預約的數(shù)量。

當司機安排預約時，他們將出現(xiàn)在GLH 的當天預約列表中。當司機到達預定的約會地點時，他們可以通過應用程序輕松登記并通知指定的專家他們已經(jīng)到達。構建我們的預約系統(tǒng)包括在后端實施調度系統(tǒng)、在移動設備上添加預約功能以及為GLH 經(jīng)理開發(fā)基于瀏覽器的日歷界面。

建立全球調度體系

受到Martin Fowler 關于重復日歷事件的論文的啟發(fā)，我們決定使用核心日歷服務來構建我們的調度系統(tǒng)，該服務具體實現(xiàn)可用的時間間隔（簡化為日歷間隔），系統(tǒng)將其視為處理這些規(guī)范的規(guī)則。

在Fowler 模型中，這些規(guī)則可以由GLH 管理器指定和修改，從而實現(xiàn)更靈活的調度。由于調度系統(tǒng)通常需要考慮許多邊緣情況，因此我們逐步構建調度系統(tǒng)以避免范圍模糊，并為每個步驟提供一個功能系統(tǒng)：

我們的第一次迭代使用了GLH 管理員最初設定的運行時間以及每個站點指定的三名專家的全球容量，使我們能夠慢慢推出該軟件的測試版。

我們的第二次迭代使用GLH 管理員設置的日歷間隔，允許他們定期設置專家池容量。

我們的第三次迭代結合了現(xiàn)有的日歷時間間隔，但也允許GLH 經(jīng)理設置GLH 關閉時間（即非工作時間和節(jié)假日）。

然而，由于Uber 的國際影響力，我們很快就遇到了與時區(qū)相關的問題，而系統(tǒng)的各個組件需要協(xié)調所使用時區(qū)的環(huán)境（例如GLH 時區(qū)或合作伙伴的時區(qū)），從而加劇了這些問題。時區(qū)。此外，我們需要考慮夏令時的變化。為了滿足這些需求，我們采用了以下規(guī)則：

所有與主要后端服務API 交互的客戶端均采用其所選GLH 的時區(qū)。

所有預約時間將以UTC +0 時區(qū)保存在我們的數(shù)據(jù)庫中。

主要后端服務有一個內部層，用于處理持久層和API 層之間的所有時區(qū)轉換。這使我們能夠抽象出日歷邏輯并調用內部與日歷相關的方法，而不必擔心時區(qū)。

需要注意的是，時區(qū)（即UTC 偏移量）不存儲為GLH 對象的屬性。如果是這種情況，那么夏令時更改將導致之前安排的預約時間向任一方向移動一小時。為了正確處理這個問題，將根據(jù)每個GLH 的物理坐標動態(tài)計算UTC 偏移量。

時區(qū)邊緣的情況

在構建我們的調度系統(tǒng)時，我們遇到了一些有關時區(qū)的特殊情況。當我們的系統(tǒng)將日歷間隔轉換為本地時區(qū)時，會出現(xiàn)問題。由于UTC 和當?shù)貢r間之間的時區(qū)變化（取決于相關網(wǎng)站的時區(qū)），日期可能不正確。例如，11 月20 日凌晨5:00 UTC（世界標準時間）實際上是11 月19 日太平洋標準時間晚上9:00。因此，重要的是，我們不要對相關時間段的日期做出假設，并測試時區(qū)何時跨越多天。

此外，在將GLH 營業(yè)時間從UTC 時間轉換為當?shù)貢r間時，我們遇到了類似的時區(qū)問題。我們使用當?shù)貢r間可以節(jié)省時間，因為如果沒有日期，我們就沒有足夠的上下文來將其保存為UTC。例如，周一上午9 點到晚上9 點的GLH 可能會導致UTC 工作時間從周一的5:00 開始，到周二的凌晨5 點結束。由于沒有日期，因此不清楚這些當?shù)貢r間指的是一周中的哪一天。因此，每當創(chuàng)建新的日歷間隔時，我們都必須將打開時間從存儲的本地時間轉換為UTC 時間。根據(jù)業(yè)務邏輯所在的位置，這些場景可能需要在Web 和移動客戶端以及服務器端進行廣泛的測試。

在移動設備上使用日期時間庫

為了讓司機合作伙伴真正使用我們的調度系統(tǒng)，我們需要為移動設備構建新的用戶體驗。這涉及修改支持表單屏幕，為合作伙伴提供除提交按鈕之外的其他選項來獲取幫助，以及顯示他們可能即將進行的任何預約的主幫助屏幕。

還有與特定活動相關的新屏幕：選擇附近的GLH 進行預約、根據(jù)該地點可用的選項選擇預約的具體日期和時間、確認您的選擇以創(chuàng)建預約、查看有關預約的詳細信息預約和取消，并查看有關網(wǎng)站詳細信息的信息，例如地址。

由于我們正在處理日期和時間，并且因為我們希望服務器API 返回結構化數(shù)據(jù)（例如ISO 8601）而不是預先格式化的本地化字符串（即用戶首選語言的日期）以供我們顯示，因此我們假設將使用java.util.Date 標準。在此標準中，日期和相應的日歷類在處理時區(qū)時存在許多已知問題，因此我們想探索其他選項是否可以更好地工作。例如，Joda-Time 標準（Java 8 API）聽起來很有趣，但它尚未與Android（驅動程序合作伙伴設備上廣泛使用的系統(tǒng)）兼容。

我們終于找到了ThreeTenBP——Joda-Time 的后繼者，它將Java 8 的時間和日期API 帶到了Java 6 和7。然而，之前在Android 上使用ThreeTenBP 的嘗試遇到了啟動問題。啟動時，這些庫從磁盤加載時區(qū)數(shù)據(jù)庫信息，解析它并將其注冊到庫中以供以后使用。該庫的Android 特定包裝器以更友好的方式加載數(shù)據(jù)，但仍然存在阻止應用程序啟動的重要磁盤操作。在中低端設備上進行測試時，這使得Uber 合作伙伴應用程序的啟動速度減慢了200 毫秒以上。

我們嘗試以多種方式優(yōu)化ThreeTenBP，例如，在不同的線程上執(zhí)行實際的磁盤操作，以便Application.onCreate 的其余部分可以并行發(fā)生，并在最后加入線程，以便Uber 合作伙伴應用程序可以安全地使用圖書館。我們還嘗試使用其他類似的庫，這些庫嘗試在啟動時執(zhí)行很少或不執(zhí)行IO，但無法將啟動時間降低到合理的延遲。

我們嘗試使用方法分析器，令我們驚訝的是，通過解析代碼，我們發(fā)現(xiàn)啟動期間的大量時間都花在了string.split 等常見字符串方法上。根據(jù)我們對源代碼的閱讀，甚至來自Application.onCreate 的步驟調試器，這似乎沒有發(fā)生。在探查器中，重量級操作被匯總到ZoneRulesProvider 類中的靜態(tài)初始化程序中，（理論上）在其中注冊惰性時區(qū)數(shù)據(jù)庫提供程序代碼。由于正在加載此類進行注冊，因此即使正在注冊的對象是完全惰性的并且在注冊時不執(zhí)行任何I/O，也會運行靜態(tài)初始化塊來嘗試從ServiceLoader/META 加載時區(qū)數(shù)據(jù)庫META-INF。這是Java 服務器而非Android 中的典型模式。它使用與我們由于其在Android 上性能較差而避免使用的資源下載相同的資源。

我們最終修改了ThreeTenBP 本身，以便可以輕松覆蓋此靜態(tài)初始化塊的行為。默認實現(xiàn)將保持不變，但將被抽象在新的ZoneRulesInitializer 類后面。 Android 應用程序或庫將能夠提供自己的實現(xiàn)，以便在首次使用該庫時通過Android 資產(chǎn)加載時區(qū)數(shù)據(jù)庫。

我們更新了lazytritenbp，另一個適用于Android的ThreeTenBP包裝器，以利用這個新接口，而ThreeTenABP的等效項尚未更新。使用該庫的啟動延遲為零，從而實現(xiàn)低延遲。然而，時區(qū)數(shù)據(jù)庫的加載發(fā)生在靜態(tài)模塊初始化期間，這意味著在需要時區(qū)數(shù)據(jù)之前不需要執(zhí)行任何操作，這甚至可能不會在典型的用戶會話期間發(fā)生。 （Uber 應用程序非常大，很少有功能需要操作使用時區(qū)的日期和時間）。

圖5: GLH 經(jīng)理的日歷UI 指定在任何給定時間段內特定站點上有多少專家可用。

我們還為GLH 經(jīng)理構建了一個日歷應用程序，以便輕松靈活地配置其站點的運營時間、可用預約時間以及任何給定時間的可用專家?guī)臁？捎脮r間只能在工作時間內創(chuàng)建。日歷中的休息時間變成灰色。日歷還顯示當前安排的約會。

在日歷的周視圖中，站點管理員可以從開始時間拖放到結束時間以創(chuàng)建可用時間。此外，他們還可以在移動應用程序中添加假期和午餐時間等關閉時間，以防止站點管理員在現(xiàn)場關閉期間意外增加可用時間。

為了設計這個界面，我們使用了Node.js、React/Redux、用于內聯(lián)樣式的Styletron、用于JavaScript 的ES2017 (ES8)、用于存儲monorepo 的可重用組件的Lerna，以及其他一些Uber 庫/框架，如Bedrock 和Superfine。設計可提供出色用戶體驗的日歷功能非常復雜，因此創(chuàng)建日歷功能并保持高性能是一項重大挑戰(zhàn)。然而，我們不想損害我們簡單、可讀和可擴展的代碼庫。此外，我們希望創(chuàng)建一些可重用的React 組件，這些組件可以適用于將使用這些組件的其他前端項目。

在我們軟件的測試版中，每次拖動日歷時，日歷中的許多元素都會重新呈現(xiàn)。因此，小時范圍是動態(tài)顯示的，即使這些元素中的大多數(shù)在視覺上不會更新。由于渲染日歷中有很多DOM 元素，因此我們利用React 的虛擬DOM，通過調整shouldComponentUpdate 生命周期方法來減少需要渲染的元素數(shù)量。

然后，我們使用react-dnd的拖動源檢查日歷中的元素是否在開始和結束時間的范圍內，并僅重新渲染這些元素。此外，我們使閉包和可用時間DOM 元素不可更新，因為它們不允許重疊，從而稍微提高了性能。結果，拖放過程中更新造成的200ms 延遲減少，接近于0。

由于日歷應用程序對服務器進行了大量調用并包含許多性能調整，因此自誕生以來代碼復雜性顯著增加。為了保持代碼干凈簡單，我們將代碼提取到可重用的組件和HOC 以及一些環(huán)境設置中，并將其轉換為前端monorepo。我們使用Lerna 進行monorepo 并發(fā)布包。通過使用monorepo，多個包存儲在一個存儲庫中，這可以節(jié)省引導新項目的時間，并且可以一次更新多個組件，從而更容易添加跨組件功能或修復錯誤。此外，為了增強React組件的可重用性，我們使用Styletron代替CSS進行內聯(lián)樣式。這確保其他開發(fā)人員不需要自己添加CSS，從而不必擔心樣式?jīng)_突，因為所有樣式都直接應用在JavaScript 代碼中。

Uber 現(xiàn)場支持工程的未來

該產(chǎn)品的開發(fā)有助于改善合作車主在GLH上的體驗，從而提高客戶滿意度。遷移到新系統(tǒng)后，等待時間平均減少了15% 以上，與客戶支持專家匹配后，問題解決時間也減少了25%。最重要的是，這些新功能意味著與GLH 預約的司機幾乎無需等待。

這只是我們?yōu)槭澜绺鞯氐暮献骰锇樗緳C和客戶支持專家提供的眾多產(chǎn)品中的一個示例。我們不斷探索新技術，以改善用戶的GLH 體驗，從改進我們的分析到在合作伙伴提交申請之前主動為其提供支持服務。