設計優步打車服務

要求

• 爲全球的交通運輸市場提供服務
• 大規模的實時調度
• 後端設計

架構

爲什麼要微服務？

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