# Google 和 eBay 關于構建微服務生態系統的深刻教訓 > 原文： [http://highscalability.com/blog/2015/12/1/deep-lessons-from-google-and-ebay-on-building-ecosystems-of.html](http://highscalability.com/blog/2015/12/1/deep-lessons-from-google-and-ebay-on-building-ecosystems-of.html)  當您查看 Google，Twitter，eBay 和 Amazon 的大型系統時，它們的體系結構已演變為類似的東西：**一組多語言微服務**。 當您處于多語言微服務最終狀態時，會是什么樣？ [Randy Shoup](https://www.linkedin.com/in/randyshoup) 曾在 Google 和 eBay 的高層職位上進行過非常有趣的演講，探討了這個想法：[大規模服務體系結構：Google 和 eBay 的經驗](http://www.infoq.com/presentations/service-arch-scale-google-ebay)。 我真正喜歡 Randy 的演講的是，他如何自我意識地使您沉浸于您可能沒有經驗的事物的體驗中：創建，使用，持久化和保護大型體系結構。 在演講的*服務生態系統*部分中，Randy 問：擁有一個多語言微服務的大規模生態系統看起來像什么？ 在*大規模運營服務*部分中，他問：作為服務提供商，運營這樣的服務感覺如何？ 在*建立服務*部分中，他問：當您是服務所有者時，它是什么樣的？ 在 *Service Anti-Patterns* 部分中，他問：哪里會出問題？ 一個非常強大的方法。 對我來說，這次演講的重點是**，**，**激勵動機，**，一致主題的想法，這些主題貫穿了整個工作。 盡管從來沒有明確地提出將其作為單獨的策略，但這是為什么您希望小型團隊開發小型清潔服務，內部服務的收費模型如此強大，架構如何在沒有架構師的情況下可以發展，清潔設計可以如何發展的背后動機。 從下至上的過程，以及沒有中央委員會如何發展標準。 我的收獲是**動機的故意調整是您如何擴展大型動態組織和大型動態代碼庫**。 引入適當的激勵措施[會使](https://en.wikipedia.org/wiki/Nudge_(book))事情在沒有顯式控制的情況下發生，幾乎就像在刪除鎖，不共享狀態，與消息進行通信并并行化所有內容時，分布式系統中的更多工作一樣 。 讓我們看看現代系統是如何構建大規模系統的。 ## 多語言微服務是終局游戲 * 大型系統最終演變成看起來非常相似的東西： **一組多語言微服務** 。 多種語言意味著微服務可以用多種語言編寫。 * **eBay** 成立于 1995 年。根據您的計算方式，它們屬于其體系結構的第 5 代。 * 最初是創始人在 1995 年勞動節周末寫的一個整體式 Perl 應用程序。 * 然后，它移至一個整體的 C ++應用程序，最終在單個 DLL 中包含了 340 萬行代碼。 * 以前的經驗促使人們轉向 Java 中分布更分散的分區系統。 * 當今的 eBay 具有相當多的 Java，但是一組多語言的微服務。 * **Twitter** 的演變非常相似。 根據您的計算方式，它們取決于其體系結構的第三代。 * 開始于單片 Ruby on Rails 應用程序。 * 在前端轉移到 Javascript 和 Rails 的組合，在后端轉移了很多 Scala。 * 最終，他們已經遷移到我們今天所說的一套多語言微服務。 * **Amazon** 遵循類似的路徑。 * 從單片 C ++應用程序開始。 * 然后用 Java 和 Scala 編寫的服務。 * 最后得到了一組多語言微服務。 ## 服務生態系統 * 擁有多語種微服務的大規模生態系統看起來如何？ * 在 eBay 和 Google 上，成百上千的獨立服務一起工作。 * 現代大型系統以關系圖而不是層次結構或層級集合來構成服務。 * 服務依賴于許多其他服務，同時又依賴于許多服務。 * 較舊的大型系統通常按嚴格的等級進行組織。 ### 如何創建服務生態系統？ * 這些性能最佳的系統比智能設計更是進化的**產品。 例如，在 Google，從來沒有一個集中的自上而下的系統設計。 隨著時間的流逝，它以一種非常有機的方式進化和成長。** * 變異和自然選擇。 當需要解決問題時，會創建新服務，或更經常地從現有服務或產品中提取新服務。 **服務只要被使用**就可以生存，只要它們能夠提供價值，否則它們將被棄用。 * 這些大型系統**從下至上**發展。 **干凈的設計可以是一種緊急特性，而不是自上而下的設計**的產物。 * 作為示例，請考慮 Google App Engine 的一些服務分層。 * Cloud Datastore（NoSQL 服務）基于 Megastore（地理規模結構化數據庫），Megastore 基于 Bigtable（集群級結構化服務）構建，Bigtable 基于 Colossus（下一代集群文件系統）構建 ）（基于 Borg（集群管理基礎架構）構建）。 * 分層很干凈。 每個圖層都會添加不屬于下方圖層的內容。 它不是自上而下設計的產品。 * 它是自下而上構建的。 Colossus，首先建立了 Google 文件系統。 幾年后，Bigtable 建成了。 幾年后，Megastore 建成了。 幾年后，云數據庫遷移到 Megastore。 * 如果沒有自上而下的體系結構，則可以將關注點分離得如此美妙。 * **這是沒有架構師**的體系結構。 Google 的所有人都沒有 Architect 的頭銜。 技術決策沒有中央批準。 大多數技術決策是由各個團隊根據自己的目的在本地做出的，而不是全球范圍內做出的。 * 與 2004 年的 eBay 形成對比。有一個體系結構審查委員會，該委員會必須批準所有大型項目。 * 通常，只有在更改項目為時已晚時，他們才參與項目。 * 集中批準機構成為瓶頸。 通常，它唯一的影響是在最后一分鐘說不。 * eBay 處理此問題的更好方法是**在審查委員會中編碼聰明有經驗的人的知識**，然后將**放入各個團隊可以重用的**。 將這些經驗編碼到一個庫或服務中，或者甚至是一組指南，人們可以自己使用它們，而不必在最后一刻才進入流程。 ### 沒有架構師，標準將如何發展？ * 沒有中央控制的**可能最終以**標準化。 * 服務和公共基礎架構之間的通信趨向于發生**標準化。** * 標準之所以成為標準，是因為它們比替代的更適合**。** * 通常標準化的通信部分： * **網絡協議**。 Google 使用稱為 [Stubby](https://www.quora.com/What-functionality-does-Google-have-around-Protocol-Buffers-that-isnt-included-in-the-current-public-release) 的專有協議。 eBay 使用 REST。 * **數據格式**。 Google 使用協議緩沖區。 eBay 傾向于使用 JSON。 * **接口模式標準**。 Google 使用協議緩沖區。 對于 JSON，有 JSON 模式。 * 通常標準化的常見基礎設施： * 源代碼控制。 * 配置管理。 * 集群管理器。 * 監視系統。 * 警報系統。 * 診斷工具。 * 所有這些組件都可能脫離約定。 * 在進化環境中，**通過**來實施標準：代碼，鼓勵，代碼審查和代碼搜索。 * 鼓勵最佳實踐的最簡單方法是通過實際代碼。 這與自上而下的審查或前期的設計無關，而是與某人產生的代碼可以輕松完成工作有關。 * 鼓勵是通過**團隊提供一個庫**來進行的。 * 鼓勵也是通過您要依賴于支持 X 協議或 Y 協議的服務獲得的。 * Google 以**聞名，每一行代碼**都已簽到至少要由另一位程序員檢查過的源代碼控件**。 這是交流常規做法的好方法。** * 除少數例外，Google 的每個工程師都可以**搜索整個代碼庫**。 當程序員試圖弄清楚如何做某事時，這是一個巨大的附加值。 在擁有 1 萬名工程師的情況下，您很可能會嘗試做某人以前已經做過的事情。 這允許從一個區域開始的**最佳實踐通過代碼庫**傳播。 它還允許錯誤傳播。 * 為了鼓勵通用做法和標準化約定**，做正確的事情**真的很容易，而做錯事情的難度會更大。 * 各個**服務彼此獨立。** * Google 沒有**來標準化服務內部**。 服務是外面的黑匣子。 * 存在約定和通用庫，但是沒有編程語言要求。 通常使用四種語言：C ++，Go，Java，Python。 許多不同的服務都以各種語言編寫。 * 框架或持久性機制尚無標準化。 * **在成熟的服務生態系統中，我們標準化了圖的弧線，而不是節點本身。** 定義一個通用形狀，而不是通用實現。 ### 創建新服務 * 新服務的使用已得到證實，便會創建它們。 * 通常針對一個特定用例構建了一項功能。 然后發現功能是通用且有用的。 * 組成了一個團隊，并將服務分解為自己的獨立單元。 * 僅當一項功能成功并且適合許多不同的用例時，才會發生這種情況。 * 這些**體系結構通過實用主義**得以發展。 沒有人坐在高處，說應該增加一項服務。 * Google 文件系統支持搜索引擎。 分布式文件系統更普遍可用也就不足為奇了。 * Bigtable 最初支持搜索引擎，但用途更為廣泛。 * Megastore 是作為 Google 應用程序的存儲機制而建立的，但用途更為廣泛。 * Google App Engine 本身由一小組工程師啟動，他們認識到需要幫助來構建網站。 * Gmail 來自內部項目，該項目在內部非常有用，然后被其他人外部化。 ### 淘汰舊服務 * 如果不再使用服務會怎樣？ * 可以重新利用的技術被重用。 * 人們可以被解雇或重新部署到其他團隊。 * Google Wave 在市場上并不成功，但是其中一些技術最終出現在 Google Apps 中。 例如，多人編輯文檔的能力來自 Wave。 * 更常見的情況是核心服務要經過多代，而舊代則已棄用。 Google 經常發生這種情況。 變化是如此之大，以至于 Google 內部的每項服務似乎都已被棄用或尚未準備就緒。 ## 建立服務 * 當您是服務所有者時，在多語言微服務的大規模系統中構建服務時會是什么樣？ * 大型體系結構中性能良好的服務是： * **通用**。 它將具有一個簡單的定義明確的界面。 * **模塊化且獨立的**。 我們可以稱之為微服務。 * **不共享持久層**。 稍后再詳細介紹。 ### 服務所有者的目標是什么？ * **滿足客戶的需求** 。 以適當的質量級別提供必要的功能，同時滿足協商的性能級別，同時保持穩定性和可靠性，同時不斷改進服務。 * **以最小的成本和精力滿足需求** 。 * 該**目標以鼓勵**使用通用基礎結構**的方式調整激勵**。 * 每個團隊的資源有限，因此要利用經過戰斗測試的通用工具，流程，組件和服務符合他們的利益。 * 它還可以激發良好的操作行為。 自動構建和部署服務。 * 它還鼓勵優化資源的有效利用。 ### 服務所有者的職責是什么？ * **生成并運行**。 * 團隊通常是一個小團隊，擁有從設計到開發和部署，一直到退休的服務。 * 沒有單獨的維護或維護工程團隊。 * 團隊可以自由選擇自己的技術，方法和工作環境。 * 團隊應對自己做出的選擇負責。 * **服務作為有界上下文**。 * 團隊的**認知負擔是有限的**。 * 無需了解生態系統中的所有其他服務。 * 團隊需要深入了解其服務及其所依賴的服務。 * 這意味著**團隊可以非常小巧和敏捷**。 一個典型的團隊是 3-5 人。 （此外，美國海軍陸戰隊 [消防隊](https://en.wikipedia.org/wiki/Fireteam) 有四個人。） * 較小的團隊規模意味著團隊內部的通信具有很高的帶寬和質量。 * 康韋定律對您有利。 通過組織小型團隊，您最終將只有幾個單獨的組件。 ### 服務之間是什么關系？ * 即使您在同一家公司，也可以將服務之間的**關系視為供應商-客戶關系**。 * 要非常友好和合作，但在關系中要有條理。 * 要非常清楚所有權。 * 要非常清楚誰對什么負責。 在很大程度上，這與定義一個清晰的界面并進行維護有關。 * **激勵措施是一致的，因為客戶可以選擇是否使用服務**。 這鼓勵服務由其客戶來做。 這是最終構建新服務的方式之一。 * 定義 SLA。 由于服務提供商向其客戶承諾一定水平的服務，因此客戶可以依賴該服務。 * **客戶團隊為服務**付費。 * **為服務收費符合經濟激勵**。 它激勵雙方在資源使用方面非常高效。 * 當事物為**時，我們傾向于不對其進行估價，也不傾向于對其進行優化**。 * 例如，一個內部客戶免費使用 Google App Engine，他們使用了大量資源。 要求他們提高其資源使用效率不是一個好策略。 退款開始后一周，他們就可以通過一兩個簡單的更改將其 GAE 資源消耗減少 90％。 * 使用 GAE 的團隊并不是邪惡的，他們還有其他優先事項，因此沒有動力去優化 GAE 的使用。 事實證明，使用更高效的體系結構，它們實際上獲得了更好的響應時間。 * **收費還激勵服務提供商保持較高的質量**，否則內部客戶可能會去其他地方。 這直接激勵了良好的開發和管理實踐。 代碼審查就是一個例子。 Google 的大規模構建和測試系統是另一個。 Google 每天都會運行數百萬次自動測試。 每次在存儲庫中接受代碼時，都會對所有相關代碼進行驗收測試，這有助于所有小型團隊保持其服務質量。 * 退款模型**鼓勵進行小幅增量更改**。 較小的更改更容易理解。 同樣，代碼更改的影響是非線性的。 千行變更的風險比 100 行變更的風險高 10 倍，而風險高出 100 倍。 * **保持接口**的完全向后/向前兼容性。 * 請勿破壞客戶端代碼。 * 這意味著維護多個接口版本。 在某些討厭的情況下，這意味著維護多個部署，一個部署用于新版本，其他部署用于舊版本。 * 通常由于增量更改較小，因此不會更改接口。 * 具有明確的棄用策略。 然后，強烈希望服務提供商將所有客戶端從版本 N 移到版本 N + 1。 ## 大規模運營服務 * 作為服務提供商，在多語言微服務的大規模系統中操作服務的感覺如何？ * **可預測的性能是一項要求。** * 大規模服務**非常容易受到性能變化**的影響。 * **性能的可預測性**比平均性能重要得多。 * 性能不一致的低延遲實際上根本不是低延遲。 * 當客戶提供一致的性能時，對它進行編程很容易。 * 由于服務使用許多其他服務來執行其工作，因此尾巴延遲主導著性能。 * 想象一下，一個服務在中值處有 1 毫秒的延遲，而在 99.999％的位置（萬分之一），延遲是一秒。 * 撥打一個電話意味著您的時間慢了 0.01％。 * 如果您使用的是 5,000 臺計算機（就像 Google 的許多大型服務一樣），那么您的速度就會降低 50％。 * 例如，memcached 的百萬分之一問題被追溯到低級數據結構重新分配事件。 隨著等待時間的增加，這個罕見的問題浮出水面。 事實證明，像這樣的低級細節在大型系統中非常重要。 * 深度彈性。 * 服務中斷更有可能是由于人為錯誤而不是硬件或軟件故障引起的。 * 對機器，群集和數據中心的故障具有彈性。 * 調用其他服務時進行負載平衡并提供流量控制。 * 能夠快速回滾更改。 * 增量部署。 * **使用金絲雀系統**。 不要一次部署到所有計算機。 選擇一個系統，將該軟件的新版本放在該系統上，然后查看其在新世界中的行為。 * 如果**有效，則開始分階段推出**。 首先是 10％的機器，然后是 20％的機器，以此類推。 * 如果在部署中的 50％點發生問題，那么您應該能夠回滾。 * eBay 使用**功能標志將代碼部署與功能部署**分離。 通常，代碼是在功能關閉的情況下部署的，然后可以將其打開或關閉。 這樣可以確保在啟用新功能之前可以正確部署代碼。 這也意味著，如果新功能存在錯誤，性能問題或業務故障，則可以在不部署新代碼的情況下關閉該功能。 * 您可能會發出太多警報，而您永遠不會受到太多監視。 ## 服務反模式 * **大型服務** * 一項服務過多。 您想要的是一個非常小的清潔服務生態系統。 * 做得太多的服務就是**只是另一個整體**。 難以推理，難以擴展，難以更改，并且還會創建比您想要的更多的上游和下游依賴項。 * **共享持久性** * 在分層模型中，服務放在應用程序層中，而持久層則作為通用服務提供給應用程序。 * 他們在 eBay 上進行了此操作，但**無效**。 它**破壞了服務的封裝**。 應用程序可以通過更新數據庫將**后門連接到您的服務**中。 最終導致重新引入服務耦合。 共享數據庫不允許松散耦合的服務。 * 微服務通過小巧，隔離和獨立來防止此問題，這是使生態系統保持健康和成長的方式。 ## 相關文章 * 關于 [HackerNews](https://news.ycombinator.com/item?id=10657251) * 蘭迪·舒普[在 Twitter](https://twitter.com/randyshoup) 上 * [微服務-不是免費的午餐！](http://highscalability.com/blog/2014/4/8/microservices-not-a-free-lunch.html) * [Google On Latency Tolerant Systems：由不可預測的部分組成可預測的整體](http://highscalability.com/blog/2012/6/18/google-on-latency-tolerant-systems-making-a-predictable-whol.html) * [10 個易趣的星球擴展尺度](http://highscalability.com/blog/2009/11/17/10-ebay-secrets-for-planet-wide-scaling.html)（2009） 像所有其他文章一樣。 這篇文章令人著迷。 我想知道微服務具體做什么？ Gmail 和 Google Wave 聽起來不夠小，不能被視為可以由小型團隊完成的微服務。 很棒的帖子！ 我希望您能詳細說明不同的工程團隊如何“使用服務付費”。 我完全同意，圍繞激勵機制組織大型團隊要比自上而下的設計優越得多，而讓團隊付費使用其他團隊服務是其中的一部分。 但是實際上，您如何實際跟蹤服務的“付款”？ 你真的是說錢嗎？ 還是您在指其他？ -克里斯 >定義一個通用形狀，而不是通用實現。 找出*為什么*被認為是好的，這將更為有用。 我發現本文中的許多建議都缺乏推理。 這使得它們非常無用。 信息發布！ 為了回答克里斯的問題，每個擁有很少微服務的產品團隊都應該有一個成本中心，可以向其他產品團隊收取使用費用。 大多數企業都擁有像 SAP 這樣的良好財務系統來跟蹤付款。 當為更多新服務提供資金時，這種“按需付費”的模式非常有效。 我希望這回答了你的問題。 -拉杰什 所有已知的問題/建議，但仍然是一個很好的談話，永遠不會老。 令人驚訝的是，許多公司沒有遵循這些基本原則。 技術演講的作者很容易理解，值得從事面向服務的體系結構工作的人們閱讀一次。 在 11 月 5 日舉行的紐約 Kubernetes 會議上，來自 Google 的一位人士說：“ Gmail 是數百種微服務。” http://www.meetup.com/New-York-Kubernetes-Meetup/events/226173240/