設計優步打車服務
阿新 • • 發佈：2019-12-31
要求
- 為全球的交通運輸市場提供服務
- 大規模的實時排程
- 後端設計
架構
為何要微服務？
Conway定律軟體的系統結構會對應企業的組織結構。
| 單體服務 | 微服務 | |
|---|---|---|
| 當團隊規模和程式碼庫很小時，生產力 | ✅ 高 | ❌ 低 |
| 當團隊規模和程式碼庫很大時，生產力 | ❌ 低 | ✅ 高 (Conway定律) |
| 對工程質量的要求 | ❌ 高 (能力不夠的開發人員很容易破壞整個系統) | ✅ 低 (執行時是隔離的) |
| dependency 版本升級 | ✅ 快 (集中管理) | ❌ 慢 |
| 多租戶支援 / 生產-staging狀態隔離 | ✅ 容易 | ❌ 困難 (每項服務必須 1) 要麼建立一個staging環境連線到其他處於staging狀態的服務 2) 要麼跨請求上下文和資料儲存的多租戶支援) |
| 可除錯性，假設相同的模組，引數，日誌 | ❌ 低 | ✅ 高 (如果有分散式tracing) |
| 延遲 | ✅ 低 (本地) | ❌ 高 (遠端) |
| DevOps成本 | ✅ 低 (構建工具成本高) | ❌ 高 (容量規劃很難) |
結合單體程式碼庫和微服務可以同時利用兩者的長處.
排程服務
- 由geohash提供一致的雜湊地址
- 資料在記憶體中是瞬態的，因此不需要複製. (CAP: AP高於CP)
- 分片中使用單執行緒或者鎖，以防止雙重排程
支付服務
關鍵是要有非同步設計,因為跨多個系統的ACID交易支付系統通常具有非常長的延遲.
- 利用事件佇列
- 支付介面整合 Braintree,PayPal,Card.io,Alipay 等
- 通過詳盡的 log 來記錄所有 event
- 使用具有等冪性、指數退避和隨機抖動的API
使用者檔案服務和行程記錄服務
- 使用快取降低延遲
- 隨著 1) 支援更多的國家和地區 2) 使用者角色（司機，騎手，餐館老闆，食客等）逐漸增加，為這些使用者提供使用者檔案服務也面臨著巨大的挑戰。
通知推送服務
- 蘋果通知推送服務 (不可靠)
- 谷歌雲訊息服務GCM （它可以檢測到是否成功遞送) 或者
- 簡訊服務通常更可靠
本文首發於矽谷io