作者 | Rafal Gancarz
譯者 | 明知山
策劃 | 丁曉昀
Uber 將其大部分容器化微服務從µDeploy 遷移到一個叫作 Up 的新多雲平台，準備將相當一部分計算遷移到雲端。Uber 花了兩年時間將其許多微服務變得可移植，以便可以在不同的計算基礎設施和容器管理平台之間進行遷移。
2014 年，Uber 還只是一個單體應用程式，隨著業務的增長，開始遷移到微服務架構。Uber 開發了µDeploy 來幫助標準化大規模的應用服務部署。這一措施抽象了主機管理方面的東西，但服務管理仍然是高度手動的，這意味著服務工程師仍然需要決定哪些服務應該在哪個特定區域的哪個區域 (物理數據中心) 內運行。
Uber 高級工程師 Mathias Schwarz 和工程經理 Andrew Neverov 解釋了 Uber 決定將工程團隊與基礎設施團隊完全解耦的原因：
在運營本地數據中心時，由於晶片短缺和供應鏈問題，我們的交付周期較長。2023 年 2 月 13 日，Uber 與甲骨文和谷歌合作，致力於多元化和降低公司在供應鏈問題上的風險。如果沒有一個可以將底層基礎設施與數千名負責為業務提供數百種不同的服務 Uber 工程師解耦的系統，那麼執行這一戰略是不可能的。
在運營本地數據中心時，由於晶片短缺和供應鏈問題，我們的交付周期較長。2023 年 2 月 13 日，Uber 與甲骨文和谷歌合作，致力於多元化和降低公司在供應鏈問題上的風險。如果沒有一個可以將底層基礎設施與數千名負責為業務提供數百種不同的服務 Uber 工程師解耦的系統，那麼執行這一戰略是不可能的。
2018 年，Uber 的平台團隊開始研究一個新的多雲、多租戶聯合控制平面，負責自動化服務部署和基礎設施級遷移。這個叫作 Up 的新平台旨在成為服務工程師與基礎設施系統交互的主要工具。它還將管理和執行最佳實踐，以推動安全的代碼部署。
Up 的高級架構 (來源：Uber 工程博客)
Up 平台採用了分層架構，其中體驗層負責用戶交互和系統管理，包括工作負載管理和伸縮。平台層為體驗層組件提供通用的抽象和概念模型，用來表達基於主機能力和計算能力的服務部署約束。聯邦層實現與計算集群的集成，並負責基於可用容量和定義的部署約束來執行服務部署。變更管理組件提供漸進式發布功能。最底層包含實際的集群實例，使用了基於 Apache Mesos 而構建的 Peleton （Uber 自己的開源容器編排平台）和 Kubernetes。
為了準備遷移到雲端，Uber 花了兩年時間使所有無狀態微服務都變得可移植，可以在無需服務工程師參與的情況下在區域之間進行集中式管理。他們使用現有工具在區域之間移動服務，確保它們是可移植的。首先，他們允許將服務移回原始區域以解決可移植性問題，一旦解決了可移植性問題，就定期移動服務以驗證其可移植性並防止出現回歸。
在變得可移植之後，微服務逐步自動遷移到 Up 上，得益於自動伸縮和效率，節省了大量的資金，並大大減少了服務團隊的維護負擔。Uber 的大部分微服務平台現在都通過 Up 來管理，可以自由地啟動其雲遷移工作，而不會對服務團隊產生太大影響。他們也關注自動化持續交付和部署安全方面的東西。
原文連結：
https://www.infoq.com/news/2023/10/uber-up-cloud-microservices/
語雀突發 P0 級事故！宕機 8 小時被網友怒噴，運維又背鍋？
智譜 AI「超 25 億融資」的背後
是時候徹底放棄「高分低能」的 Leetcode了：AI 時代的面試需要大變革！
B 站廣州研發工作室解散；外媒曝光蘋果中國區醜聞；OpenAI 被曝已叫停新大模型項目 | Q資訊