谷歌失敗案例賞析：那些年在微服務上踩的坑

你們好，今天和在座的各位分享一些失敗的經驗教訓。聊一聊這一類的話題要比那些成功案例更有意思。行業在進步，咱們能夠從過去的錯誤中吸收經驗，並主動在將來的計劃中避免，這一點很使人鼓舞。

背景信息

在開始以前，先介紹一下我在谷歌的經歷。2003 年大學畢業後我直接加入了谷歌，在這以前我是一個音樂營地的營地顧問，營地顧問以前我在一家冰激凌店工做。我還記得在谷歌的第一天，第一個項目的技術負責人是 Andrew Fights，他如今是相似谷歌傑出的工程師的角色，我記得當時告訴他，我得去找人聊一聊由於實在不知道我在作什麼，今天想起來仍是頗有趣的事情。在谷歌裏我像海綿同樣快速的吸取技術和其餘的信息。今天我在這裏談論的一些事情其實要早於我在谷歌的時間，大約 2000 年和 2001 年左右。讓咱們從微服務，即谷歌的微服務版本開始講起。

當時，谷歌的業務仍然押注在 GSA（谷歌搜索服務器）產品，其實最終 GSA 也並無像想象中的那麼順利。固然了，其它事情也是這樣，畢竟不能將一個虛擬的壟斷產品與像廣告這樣數十億美圓的鉅額業務相對比。不過，谷歌最開始是以搜索起家的，並專一在解決這一類的技術問題。

     

接下來要討論的不少內容的原始驅動力來自於這張幻燈片。在經濟危機以前，不少企業都將他們的基礎設施構建在 Sun Microsystems 的硬件之上，並將 Solaris 做爲操做系統。若是不考慮成本的話，這一套解決方案比現有的其它東西都要好，不少人買了不少這種 Sun box 也是基於這樣的緣由。但 Sun box 真的很貴，尤爲是一個擁有龐大數據中心的企業，整個數據中心須要填滿這種機箱以支撐業務的發展，成本就會影響到其業務渠道和活下去的底線。

谷歌當時就處在這樣一個情況。當時的人會很天然的說：「Linux 雖然不夠完美，不過功能也夠用，它的硬件又很便宜，因此平衡下來咱們能夠選擇 Linux 做爲替代」。必定程度上，我也認同這些過往的事情是真實的，當時的人們成本意識很強，因此他們會竭盡全力的去解決一系列 RAM、芯片等 Linux 出現的一切故障，以下降成本。而這就帶來了一個結果 - 即 Linux 真的不可靠，特別是使用垃圾站硬件的時候，且問題很嚴重。我認爲，谷歌從 Compaq DEC 併購中受益不淺，這也是致使 90 年代一些真正使人難以置信的研究實驗室死亡的緣由。許多人好比 Jeff Dean 和 Sanjay Kumar 都來自那個世界，他們如今幾乎都是質量工程師。當時的他們對如何在那些難以使人置信的不可靠硬件之上構建軟件這個問題產生了強大的興趣，後面發生的事情也是不少接下來要分享的內容。

     

你們都知道，這個問題在 2001 年是沒有人解決過的問題，也是他們當下所處的狀況。「讓咱們寫一些很酷的軟件，看看 Github 上有什麼」。

     

然而在 2001 年並無什麼能夠替代的方案，因此必須本身作。另外一個問題是很是古怪的擴展要求。他們試圖作一些當時很是大膽的事情，即索引每一個網頁的每一個字。一些人將每一個網頁的每一個單詞收錄並編入索引，其餘人只是給它創建索引，而後丟棄那些限制競爭對手能力的原始數據。這是一項艱鉅的任務，須要用到當時根本不存在的計算機軟件。

所以，因爲不可靠的 Linux 盒子，該軟件必須橫向擴展，而且必須在堆棧的任何組件中容納頻繁的例行故障。以前有一篇很棒的文章提出了「機器是牛而不是寵物」。我認爲在這件事情上谷歌作對了。這些機器沒有來自「星際迷航」的酷炫名字，它們只是 AB 1,2,5,7 相似的東西，那也是機器名。系統對它沒有太多的依賴，它死了或者繼續運行都不會影響其它部分。這個問題讓人們開始思考如何創建更具彈性的系統。

以上是我如何描述事物的方式。在谷歌不少人都有博士學位。記得面試時，我尚未博士學位。並且，我只跟一個沒有博士學位的人談過，面試結束時，他說，「別擔憂，如今開始僱用沒有博士學位的人了」，在那裏有不少人比我更聰明，而且真的想將他們的知識應用到 CS 系統研究中，將這種類型的經驗和知識應用於現實問題是一件頗有趣的事情。

     

在谷歌有不少自下而上的決策，個人第一位經理在我加入時有 120 位直接彙報人的這一事實也說明了這一點，決策的制定是分散且惟一，那裏是一個有抱負的文化氛圍，也是一個很是以任務爲導向的組織，既有基礎設施，還有公司層面，特別是在那個時候，它是一個很是純粹的理想主義組織。具備諷刺意味的是，如今看到新聞時感受事情發生了很大的變化，至少就公衆形象而言，固然重要的是要記住時間，並且我認可也許有點過度自信。人們可能以爲他們有能力作任何事情，願意嘗試新的大的挑戰，並假設確實能夠實現，這很酷有很高的風險，但也頗有趣。

那些發生的事情

那麼，這樣的工程要求和文化氛圍實際致使的結果是什麼呢？

這是一張寒武紀大爆發的圖，寒武紀大爆發是進化史上的一個時期，生物多樣性迅速，是多種因素共同做用的結果。我今天早上讀了維基百科，以確保我引用的事實是正確的。它與氧氣的增長有關，鈣的增長使得這些生物可以製造它們的殼。那時的許多事情都發生在大體相同的時間，在 2000 萬年間，生物多樣性的增加很是迅速。

     

在谷歌也有相似的東西，業務須要構建一個很是大的架構，這個架構須要圍繞軟件和認爲他們能夠嘗試一些新事物的文化背景而構造。這就致使了在谷歌相似寒武紀大爆發同樣的不少基礎設施項目的爆發，許多項目如今已經衆所周知，如 GFS-Google 被普遍使用的文件系統， BigTable 是 Cassandra 以前的產品，著名的 MapReduce、Borg 是相似於 Kubernetes-ish 的項目。有人可能會由於我這樣的觀點生氣，但它應該很接近真實的狀況，也還有一些沒有公開但令我印象深入的項目。

其實不只這些重要的項目衆所周知，他們撰寫的論文也使得這些案例在 Google 以外傳播開來。這些項目與 Hadoop 項目之間存在一對一的對應關係，並從開源社區推廣。但這帶來了一個問題，他們引領谷歌的文化走向崇拜這些項目，人們會認爲在一些與大型基礎設施結構類似的項目上工做真的很酷。這份清單上的全部內容固然都是必要的，Google 也從中受益不淺。然而谷歌內部的這些貨物崇拜致使人們試圖模仿這些系統的設計而不去理解爲何選擇這些設計。

     

這些設計在不少方面看起來很像今天的微服務。這就是爲何咱們不把它稱爲微服務，在結構上它們看起來很像微服務。起初想要創造一種能夠水平擴展的東西，想要分解像 RPC 服務發現這樣的用戶級基礎設施，但如今「服務網格」中的內容已被考慮到這些巨大的客戶端庫中，這些庫在今天的谷歌被普遍使用，被稱爲谷歌 3。在谷歌 3 構建一個 Hello World 的二進制文件，它須要消耗 140 兆字節的二進制文件，且只是爲了連接這個用戶級別的內核。谷歌 3 爲了完成全部這些工做而將其考慮在內，後來也轉向了一些看起來有點像 CI、CD 的東西。它開始感受很像微服務了，可是這樣作的決定是出於計算機科學的需求，我認爲這是今天大多數組織構建微服務的一個有趣的理由。

經驗教訓 第一條 開始以前須要明確構建微服務的緣由

我認爲構建微服務的惟一充分理由是組織結構，而且這也應該是大多數組織構建微服務的惟一緣由。然而，這並非谷歌構建微服務的緣由。谷歌構建微服務是爲了計算機科學，在這裏，我不會去爭辯從這個角度構建微服務其實也沒有什麼好處，固然確定是有不少痛點驅動。

開始構建微服務以後，若是簡單的認爲它必定會很順利，也沒有事先調研全部可能的失敗狀況，那麼必定不會順利，並且實際上也可能會帶來不少使人遺憾的結果。我和不少企業討論過這個問題，這些企業也由於遷移的過程實在太痛苦了而放棄了向微服務的遷移。因此，必定要事先了解構建微服務的動因。就像谷歌裏有不少人效仿大型的基礎設施項目同樣，有時我認爲他們在構建一些並沒必要須的架構。理智的投資方式應該是遵循如下原則：「若是你不須要就不要去作，不然只會會讓事情變得更困難」。

這樣作的主要緣由是最大限度地減小團隊之間的人員溝通成本，一個超過 10 個或 12 我的的團隊沒法在一個工程項目上成功協做，它與人員溝通結構和工做受權有很大關係。所以，將項目團隊映射到微服務能夠減小人與人之間的溝通開銷，從而提升開發速度。這是一個選擇微服務的合理緣由，但這也並非咱們在谷歌構建微服務的緣由。

     

其實谷歌的微服務不是預先設計的結果，只是一件意外產物。我聽到過不少人分享他們採用微服務的緣由，對我而言他們從根本上仍是技術驅動。我並非說這些是錯的。但我認爲，若是這是你選擇微服務的緣由，那麼至少你應該慎重的考慮並確認微服務是當下惟一的技術選擇，沒有其它的替代辦法。

     

我常常從管理層那裏聽到不少實施微服務後帶來的痛苦。我也構建過不少使全部 Google 受益的監控系統，也會不可避免地討論咱們的客戶 -Google 內部的項目，其中一些是搜索和廣告等內容，一些是在 Google 雲端硬盤管理控制檯中不多據說過的功能，它多是爲谷歌雲端硬盤服務的一個很是重要的項目，但吞吐量並不高，有着一套與搜索和廣告都不一樣的要求。並且，來自搜索和廣告的經驗教訓只對大規模的服務有意義。就像 Jeff Dean 所說的一句話，一個支撐超過三四個數量級以上規模的系統是沒法設計出來的。基於此，我認爲在系統的能力集和功能集，以及系統規模之間存在一個天然的取捨。

能夠用一個例子來理解它：若是咱們構建了一個具有大規模擴展能力的系統，那麼因爲這樣一種天然的規律，在某些角度就必須認可它的功能特性可能不好。咱們在谷歌構建的系統具有超級超級的可擴展能力，如今谷歌的公開數據是每秒 20 億次 RPC 調用，這比我想象的實際須要的要多得多。若是要經過擴展來實現這種請求量，那麼必將犧牲不少功能，而這也是在谷歌發生的事情。

Dapper 經過積極的採樣分析解決了這個問題，但坦白說，也給低吞吐量的系統帶來了糟糕的體驗。Kubernetes 項目大概不會真正適用於 Google 的現狀。當觸及實質問題的時候，咱們會發現 Borg（谷歌內部的大型集羣管理項目）從不少角度均可以說是一個很是不一樣的系統。這些取捨在不少地方都會發生，但對於應用程序員們的結果是，他們有大量的需求用來標準化微服務的開發工做，而所參考的微服務本質上卻來自搜索與廣告領域，小型服務的程序員開發體驗所以會變得很是糟糕。

在谷歌，要想將一個服務投放到生產環境是一件很麻煩的事情，由於全部的需求都必須支持搜索和廣告的水平擴展，即便一個很小的項目也要強制執行。我還記得，我以 20% Project 的方式完成了谷歌天氣項目，當你搜索舊金山的天氣，谷歌天氣就會出現。我一週內完成了原型開發，接下來的幾個星期內完成了核心代碼的生產版本，但總共花了六個月的時間 。實際上也並非六個月就把它發佈了，由於我還要完成不少上線必需要作的任務清單任務。

若是一個微服務專一於解決計算機科學研究的問題而非速度，那麼就會發生這種狀況。我認爲，開始以前應該明白將要完成的事情，並確保能夠專一於速度，保持合理且適合當下實際構建的服務類型的任務清單。由於促進高吞吐量不一樣於高工程速度；也不須要考慮低延遲；而低延遲很是重要，可是在吞吐量和工程速度之間須要取捨，反映在技術決策則體如今是否應該使用 JSON 進行通訊，仍是某些很是嚴格的二進制協議，亦或考慮監控的可觀察性方面。這些事情會讓你的進度慢下來，而大多數的谷歌項目並無像搜索和廣告同樣的規模，因此就會很是的痛苦。

 第二條 無服務器服務仍然運行在服務器上

     

在谷歌咱們也沒有稱它爲無服務器。上面圖中是一個測試，」火腿三明治、費德勒、怪物卡車、富士山和亞馬遜的 Lambda「，這些其實都是無服務器的，它們只是一些沒有任何意義的術語，因此我很是討厭無服務器這個詞。就像 NoSQL 同樣，咱們不該該將這其中一些小事物的反面詞語做爲營銷術的術語。這些詞語沒有任何意義，可是這就是咱們生活的世界。我將繼續稱之爲 FaaS- 功能即服務，這個詞至少有意義。

     

這張圖顯示了每個工程師都須要知道的一些數字 - 系統運行中不一樣活動的延遲時間列表。從上向下的第五個是讀取主要內存數據的延遲時間，能夠理解爲若是有一個緩存未命中，到達主內存須要大約 100 納秒。若是要在一個數據中心內完成一個 RPC 調用，那時間就遠遠不止於此。

     

這是另外一張一樣活動的數字，主內存數據大約是 100 納秒 - 十分之一微秒，速度很快。即便在同一數據中心內往返，仍然不到一毫秒。因此，當把它與人的速度類比的時候，它的速度感受有點快，但若是你把它們放在一塊兒，就會發現真的很是不一樣。並且我認爲有一種趨勢，將事情分解成愈來愈小的部分會變得很是有趣，以致於咱們會忘記了其實兩個進程間經過網絡通訊的成本很是高。我也確實看到不少人在這個方向上走的太遠，再次強調一下，這仍是癡迷於單一目的服務的理念，也是盲目蠻幹的失敗模式。 我寧願看到圍繞工程組織中的功能單元構建服務，並考慮必定的分區，而不是將事情細分爲儘量小的部分。

我有些擔憂無服務器運動或 FaaS 運動。有時你能夠擺脫徹底使人尷尬的並行，但在其餘狀況下緩存真的頗有幫助。若是你正經過網絡進行緩存，Mem Cache 有時是合適的，可是，在使用以前要確保完成背後的那些工做，包括如何支撐串行調用的次數，它是否會影響最終用戶的延遲，當前的系統情況。

因此，我認爲這是微服務的另外一種失敗模式，而如今無服務器的市場很大，因此外部市場實際發生的事情遠多於我在 Google 內部所看到的。若是咱們想消除對系統運行的擔憂，那麼 Etsy 文件及相似的東西均可以解決問題。可是，若是咱們將功能做爲一項服務專門討論，請注意一旦賣出概不退換，因此請確保那些功能真的是適合你的系統需求。

 第三條 獨立並非絕對的

咱們以前談到過採用微服務的根本緣由是團隊溝通成本和獨立的思考等。它開始讓我以爲有點像嬉皮士。就像每一個人同樣...... 每一個團隊都是一個獨立的決策單位。他們會嬉鬧，須要作的只是決定 API，發送請求而後響應。在微服務架構下，每一個團隊能夠作他們想作的任何事，它是平等和美麗的。

這些其實是來自我以前對話的一家公司，他們不得不將已經完成的微服務回滾。在爲單個服務寫代碼的時候開發工做仍是很順利的，但在部署的時候問題就來了，交叉出現了一系列的跨服務橫切關注點，尤爲在生產環境中。那些顯而易見的關注點包括安全性、監控、服務發現、身份驗證等。這些都是跨功能的關注點。這時候會面臨兩個問題，第一個問題，每個團隊都必須承擔運維壓力，而每個團隊的規模相對較小，因此必需要付出額外的成本。第二，其中一些事情是全局的問題，特別像可觀察性，須要從系統的全局進行設計，而這樣的事情若是每一個團隊本身作決定，將會失去統一有效的機制。

Jessica 也談到了這一點。聽起來 Airbnb 正在以正確的方式接近這個方向，但這是一個重大問題。我認爲，當人們追求微服務的獨立性時，他們應該考慮哪些維度其實是獨立的，哪些維度應該委託給某類平臺團隊。我今天早上和 O'Reilly 的一我的談論了可能對微服務領域有幫助的書籍，其中我認爲看一本關於在微服務項目和人員管理方面的書會頗有用，能夠有助找出應該獨立的和不該該獨立的那些因素。

     

在這個問題上，我認爲螞蟻作對了。螞蟻，不管性別身份如何，都是獨立的。它們獨立完成本身的工做，可是會堅決遵循蟻羣的行爲規則。有時螞蟻們可能很痛苦，可是蟻羣這樣作的目的爲了獲取更大的利益。儘管這對單隻螞蟻來講多是使人沮喪的，但這就是蟻羣能夠活下去的工做方式。就若有時候使用一個簡短前綴的語言菜單和技術使人很沮喪，可是若是你的組織有一個支持微服務的短平臺列表，這大概是最好的選擇。在這個方面我認爲谷歌作的對，谷歌對事物的分解有時候近似瘋狂，在某種程度上，我建議儘量將事情從你的服務中獨立出來。我喜歡螞蟻，圖中顯示了它們的服務發現，若是螞蟻們經過隨機散步找到了食物，它們會返回巢穴並沿路留下信息素，隨後其餘螞蟻聞到並跟隨它找到食物源。螞蟻們很是聰明。在大學，咱們有一個有趣的編程做業來模擬螞蟻的這種行爲 - 一種很是優雅且效果很好的集體行爲。當有威脅時，螞蟻們會進行一系列的智能安全措施並彙集幼蟲，它們會把全部的熔岩都帶走並隱藏起來，這是蟻羣爲了共同的利益而採起的集體行爲。螞蟻們還構建了一些使人驚奇的物體，尤爲考慮到它們是昆蟲類動物，螞蟻絕對稱得上是優秀的工程師。他們作的對。

我認爲，在微服務中須要更多地考慮螞蟻精神而不是嬉皮士精神。在這個時代，嬉皮士精神可能不該該進入工程管理領域，這是微服務的錯誤信念和價值觀。

 第四條 警戒巨大的儀表板

我曾在谷歌的 Dapper 和 Monarch 項目工做過，Monarch 這個項目在谷歌並無太多的記錄，John Banning 曾在 Monitorama 分享過。Monarch 的規模很是大，它以服務的方式運行，基本上就像是一個爲整個谷歌設計的高可用性時間序列監控系統。在這個項目中，我花了大量時間與 Google 的 SRE 團隊交流，其中有一些很是棒的實踐給了我不少啓發。Cody Smith 是負責網絡搜索的 SRE。網絡搜索做爲儀表板設計的很是緊湊，就像十幾棵草攢在一塊兒，但卻具備使人難以置信的時間保真度。就如每秒分辨率，存在一百萬個維度去解釋圖形中的任何變化以及某種維度的過濾聚合。還有其餘的項目也有這些巨大的儀表板，有不少不少頁的信息。它們背後的設計思路是能夠經過掃描全部的信息並找到其中的問題或相似的問題。但我認爲這是一個很是糟糕的模式。

     

這是內部儀表板中的一組圖表。經過這張圖，很明顯能夠看出這裏大約在 12 點出現了一些問題，而這裏的高峯期是 12:20 左右，另外一邊的圖顯示峯值在 12 點以前，這些圖標顯示的數據大都相關。

     

然而，這麼多呈現的圖表，接下來咱們應該查看哪個進一步定位問題？我一點概念都沒有。真正瞭解這些系統的人可能經過一些細節能夠辨識這些圖標背後的含義，但若是是正在隨時待命處理生產環境問題的運維人員則必須快速找出問題，這個儀表板則是一個糟糕的狀況，有八個圖表，還有另外十幾個顯示相同的狀況。另外，還有的儀表板的頁面一次又一次地顯示同一個故障，這樣實際上對於分析問題也並不可行。然而對微服務架構來講這是一個重要問題，每一個服務都會生成大量的儀表板或 RPC 和服務網格等等，包括業務指標。

以後，儀表板會呈現分佈式系統中的級聯故障，這些故障在不少地方均可以看到。微服務的本質是服務間具備相互依賴關係，A 依賴 B，B 依賴於 C，C 依賴於 D，D 出現了一次故障且反映在 CBNA 中。在儀表板中，應該能夠經過查看波浪線找出根本緣由，然而現實卻不是這樣。儀表板應該服務於 SLI 即服務水平指標，它表明了消費者關心的內容，以後的根因分析則須要基於此進行引導分析和改進。

     

我認爲可觀察性包括兩件事，一個是檢測關鍵信號，即 SLI 的部分，它須要很是精確；另外一個則是改進搜索空間。每增長一個微服務，可能發生的故障模式的數量隨着服務數量的增加而幾何式增加。我並不認爲機器學習或 AI 能夠神奇地解決這個問題。咱們須要儘快發現能夠幫助減小人腦假設的方法，只有在使用巨型儀表板以外的技術時才能實現引導過程。巨型儀表板在單體環境中運行良好，但我看到人們採用這種理念並圍繞它構建微服務的可觀察性。我認爲有必要使用儀表板，但確定不夠。我採訪過的 SRE 小組當時正在構建巨大的儀表板，咱們的效率明顯低於讓它設計上更緊湊的團隊，以後再使用其餘工具來改進搜索空間。因此，不要混淆搜索空間的可視化和對它的精煉優化。整個搜索空間太大了且沒法可視化，並且人類迄今也沒法處理那麼多信息。

在 LightStep，咱們看到不少客戶一直在努力解決這類問題。我不知道在座的各位是否經歷過一樣的狀況，但我認爲這是一種失敗模式，谷歌確定也明白這一點。曾經有一個大型的 Google 服務，大概名字是家庭類型之類的服務，它不得不使用代碼生成器生成告警配置，最終致使了 35,000 行還要長的代碼。我不記得其中的全部緣由。但隨後他們不得不開始手動維護這 35,000 行代碼，然而這些配置是在 Google 內部徹底模糊的 DSL 中編寫的，手動維護所帶來的痛苦程度沒法比擬，這就是由於他們混淆了對 SLI 的告警信息和多是根本緣由的告警信息。監控不該該對根本緣由發出告警，它應該是細化過程的一部分；而應該對 SLI 發出告警，對於任何特定系統，SLI 的信息不會有那麼多而致使沒法處理。

 第五條 沒法跟蹤一切

這條教訓來自 Dapper 項目。在某種程度上和以前對谷歌系統的評價相似，」當一個系統變得如此龐大時，它所提供的解決方案功能集會相對的減小」。咱們當時正在與搜索和廣告對 Dapper 的要求進行抗爭，它們要求 Dapper 每秒支持數億次查詢，而咱們能作到的惟一方法就是積極地進行採樣分析。

     

微服務的結構看起來很像多邊形，在運行中會產生事務通過這些組件，有些事務也會調用多個其它服務，因此瞭解一個微服務系統最基礎層面發生的事情能夠更好的維護和提供服務，諸如服務請求的起點、它的旅程直到請求的結束，這就是分佈式跟蹤的最基本想法。若是沒有實現這樣的功能，另外一種可替代的方式則是讓其餘人經過電話幫助調試，但實現起來很是痛苦。分佈式跟蹤的功能對於分佈式系統來講很是有價值。

     

它的問題是跟蹤在這個圖的數據科學和數據工程中有一個黑暗的祕密跟蹤。

     

圖中呈現了數據卷的真實檢查數據，能夠看出堆棧頂部的實際事務數量，隨着業務增加，這個數據的總量大概須要再乘以服務數量。所以，當遷移至微服務後，數據量也會相應增加，這個增加與事務總數不成比例，但與服務的數量成正比，大概是乘以網絡成本和存儲此數據的成本，以後還須要將數據存儲一段有效時間。基本上，從第一原則的角度來看，微服務系統中的數據太多。在更快的網絡或更便宜的存儲被髮明以前，如今的數據真的太多了。這個問題會反映在太高的 Splunk 帳單或者 ELK 失效。但若是你使用日誌記錄做爲跟蹤數據，而後嘗試使在同一管道中聚合，這個問題就會發生。分佈式跟蹤一般被認爲是這些時序圖，但實際上它只是一種使用內置採樣機制進行事務性日誌記錄的方法。

     

對於 Dapper，咱們須要將其用於 Web 搜索和廣告，也所以而積極的採樣分析。咱們在交易以前作的第一件事就是翻轉一枚硬幣選擇它做爲樣本數據，這樣能夠將數據量減小 99.9％，這種方法頗有幫助。然而，事實證實這還不夠，即便將 1000 箇中的一個請求集中在一塊兒的成本也很昂貴。所以，在全局集中這些數據以前還須要進行進一步的抽取 1:10000，以後能夠 MapReduce 以及更復雜的分析。這就是在 Google 完成這項工做所必需的。然而，就我我的而言很是後悔並對此種作法深感遺憾。坦率講，相較於在 Dapper 的作法，我認爲應該能夠找到另外一種方法提供更多的按鈕而且更面向長遠的考慮，這也是我爲何會成立 LightStep 的緣由。

Dapper 由 Sharon Pearl 和 Mike Burrows 兩人創辦，他們都來自前面提到的 Compaq DEC 併購，但對此並非很開心。Mike 在微軟研究院工做過，那時他在研究 Bing 搜索產品，當他去谷歌時，有人稱他的背景並不容許他在谷歌工做。他喜歡搜索，以後他建立了 Chubby，有點像 Zookeeper，同時還參與了許多其餘項目。而 Sharon 促使了我加入 Dappe。 在早期的職業生涯裏，谷歌作過這樣一件事情：他們會在組織裏給你匹配一個與你儘量不一樣的人，他們會從九維空間的角度進行員工走查，包括工做的語言、離開學校的時間、辦公地點、彙報結構等。

在參與這項調查的人裏面，Sharon 是與我最不相同的那我的，當時我還在廣告項目，並非很喜歡當時的工做。Sharon 給我列出來她正在參與的一系列項目，並提到了 Dapper，而他們當時真的不想將它產品化。我聽了以後卻喜歡上了它，「這聽起來比我正在作的事情更加有趣」，以後我管理了大約 120 份報告，我開始研究它想作一些更野心勃勃的事情，個人導師 Luis 在這當中也建議我 「這足以讓人在谷歌的每臺機器上跑步了。你爲何不先解決它？」這真的是一個有些政治和塹壕戰的項目，但這就是他告訴我要作的事情。我也作到了，但我真的後悔了。由於其實還有不少其它的方法能夠解決這個問題。這無關個人 LightStep 項目，相比於方法，LightStep 給出了不少能夠了解系統的機會。

總   結

     

最後總結一下，我認爲選擇微服務有兩個驅動因素：獨立和計算機科學。開始微服務以前要確保在組織級別推動微服務的緣由。構建微服務的目的在於優化速度，它不是指工程速度，也不是指系統吞吐量。一件事情開始的緣由不一樣會致使不一樣的結果。第二，須要瞭解所選解決方案的適合規模。對於整個無服務器 FaaS 話題，不要由於它頗有趣而繼續縮小和縮小。「嘗試作個螞蟻，而不是嬉皮士」。第三，可觀察性不是關於三大支柱，它只是有關數據的檢測和改進。考慮一下這些工做流程，跟蹤全部內容則是可能的。從調試和性能優化角度來看，這是解決此問題的一種有趣方式。