摘要：自去年以來，微服務(wù)受到了前所未有的關(guān)注，眾多的互聯(lián)網(wǎng)巨頭開始實施微服務(wù)架構(gòu)并取得了不錯的反響，話不多說，今天我們就為大家盤點一下谷歌亞馬遜等十大科技公司的微服務(wù)實踐案例。

自去年以來，微服務(wù)受到了前所未有的關(guān)注，眾多的互聯(lián)網(wǎng)巨頭開始實施微服務(wù)架構(gòu)并取得了不錯的反響，話不多說，今天我們就為大家盤點一下谷歌、亞馬遜等十大科技公司的微服務(wù)實踐案例。

谷歌

隨著多元化微服務(wù)的流行，越來越多的服務(wù)開始采用微服務(wù)來構(gòu)建。近日，曾在Google和eBay擔任高級職務(wù)的Randy Shoup在博客中分享了其從這兩個公司所學習到的構(gòu)建大規(guī)模服務(wù)架構(gòu)的經(jīng)驗。本文對Randy談?wù)摰膬?nèi)容進行了總結(jié)，為那些沒有創(chuàng)建、使用和保護大規(guī)模架構(gòu)的工程師提供參考。

擁有多元化微服務(wù)的大規(guī)模生態(tài)系統(tǒng)運行情況如何呢？

eBay和Google采用了數(shù)百到數(shù)千個多帶帶的服務(wù)來協(xié)同工作。
現(xiàn)在的大規(guī)模系統(tǒng)都是以圖的形式，而不是層次式或多個連接的形式來構(gòu)成服務(wù)。
服務(wù)之間相互依賴。
只有舊的大規(guī)模系統(tǒng)采用高度集成的方式進行組織。

目前運行良好的系統(tǒng)都是不斷變革的產(chǎn)物。例如，Google從來沒有對系統(tǒng)進行過集中的設(shè)計。當前的系統(tǒng)純粹是適應(yīng)時代和技術(shù)發(fā)展演變而成的。變異和自然選擇。當一個新的問題出現(xiàn)，工程師通常選擇利用已有的產(chǎn)品或服務(wù)來解決。因此，一個服務(wù)只有在不斷的提供價值、不斷被使用的情況下，才能避免被淘汰的命運。

詳細文檔請關(guān)注我們微信號，回復(fù)“京東”，獲取下載地址

2.亞馬遜

Munns是Amazon的DevOps部門的業(yè)務(wù)開發(fā)經(jīng)理，他在演講中引用了維基百科上微服務(wù)的定義，但同時也列舉了微服務(wù)的4條使用上的限制：
單一目的。
僅通過API進行連接。
通過HTTPS協(xié)議進行連接。
微服務(wù)之間大體以黑盒的方式展現(xiàn)。

描述團隊的規(guī)模有一個著名的術(shù)語，即剛好能吃完兩只披薩的團隊。在Amazon，這樣的團隊被稱為服務(wù)團隊，他們對于創(chuàng)建過程具有完全的自主權(quán)，包括產(chǎn)品的計劃、開發(fā)工作、運維以及客戶支持。他們具備完全的自主權(quán)及責任性，同時也負責每日的運維和維護工作。換句話說，誰創(chuàng)建的服務(wù)，就由誰負責運行。這意味著質(zhì)量保證（QA）人員以及運維人員都隸屬于服務(wù)團隊之中。但Munns也提到，承擔這一角色的部分員工也有可能由整個組織共享。
對于團隊來說，這樣的文化意味著很高的自由度，但這些團隊將通過以下途徑得到授權(quán)并保證實施的高標準：

全面的培訓。
由具有20年以上開發(fā)經(jīng)驗的員工全面定義各種模式與實踐。
在業(yè)務(wù)與技術(shù)兩方面定期進行衡量指標審查。
由內(nèi)部的專家分享關(guān)于新工具、服務(wù)與技術(shù)的知識。

Munn對于小型團隊與微服務(wù)在Amazon的發(fā)展進行了深入的觀察，以了解其重點所在。對于其他打算按照相同方式發(fā)展的組織，Munn提出了一些建議：

文化 —— 這里要強調(diào)一點，自主權(quán)與責任是不可分離的，規(guī)模越大的團隊，其運作速度相對于小型團隊將有所下降。團隊要堅持卓越產(chǎn)品的標準，但并非堅守做事的方式一成不變。
實踐 —— Munn提到了持續(xù)集成（CI）與持續(xù)交付（CD），以及簡化運維任務(wù)的重要性。
工具 —— 這些工具將用于之前所提到的實踐、基礎(chǔ)設(shè)施的管理、指標的設(shè)立和監(jiān)控，以及交流和協(xié)作。

Munns最后強調(diào)了為服務(wù)和客戶建立起一種模式的重要性，這將使組織避免重復(fù)發(fā)明一些相同的基礎(chǔ)部件，將精力浪費在通信、授權(quán)、防止濫用和服務(wù)發(fā)現(xiàn)等任務(wù)上。他還闡述了構(gòu)建、托管、服務(wù)的指標對于觀察基礎(chǔ)設(shè)施是否按預(yù)期運行、SLA是否得到滿足等問題的重要性。

詳細文檔請關(guān)注我們微信號，回復(fù)“亞馬遜”，獲取下載地址

3.Twitter

在圍繞微服務(wù)展開的探討當中，我們發(fā)現(xiàn)幾乎很少有人能夠切實回答上述問題。以Docker、Mesos、Kubernetes以及gRPC為代表的各類新型技術(shù)成果的快速崛起使得我們能夠輕松建立小型新架構(gòu)。然而，高流量生產(chǎn)性用例又該如何實現(xiàn)？根據(jù)我們的推算，目前能夠以規(guī)?；绞竭\行微服務(wù)，從而解決實際問題的企業(yè)數(shù)量仍然相當有限。

Twitter就是其中的典型代表。而且盡管其也經(jīng)歷過公共服務(wù)中斷，但Twitter負責運維的是世界上規(guī)模最大的微服務(wù)應(yīng)用之一，其中包含上百種服務(wù)、數(shù)以萬計的節(jié)點以及每項服務(wù)中的數(shù)百萬RPS。令人震驚的是，事實證明這樣的工作絕非易事。雖然不是不可能，但需要企業(yè)投入多年并充分運用自身聰明才智，從而令一切在實踐層面運作良好。

當Oliver和我前幾年離開Twitter公司時，我們的目標是運用自己多年積累下的專業(yè)知識，將其轉(zhuǎn)化成可供全世界各組織機構(gòu)使用的可行性資源。令人振奮的是，這些知識中已經(jīng)有相當一部分以開源項目的面貌了，也就是Finagle項目——這是一套用于支撐Twitter微服務(wù)架構(gòu)的高通量RPC庫。

詳細文檔請關(guān)注我們微信號，回復(fù)“Twitter”，獲取下載地址

4.SoundCloud

很多的技術(shù)文章著重介紹的都是項目后總結(jié)出的最佳實踐，本文從另外的角度，介紹項目中解決問題的整個探索過程，詳細講述了在最終使用微服務(wù)架構(gòu)之前所做的種種分析和嘗試，這對于正在嘗試解決問題的技術(shù)人員來說有很大的啟示作用。

當我最初加入公司的時候，手頭最重要的項目內(nèi)部稱之為v2。該項目對我們的網(wǎng)站做徹底的改版，發(fā)布時的商標名稱為The Next SoundCloud。

一開始我加入了后端團隊，App團隊。我們負責巨大的Ruby on Rails應(yīng)用程序。那時候還不稱其為遺留系統(tǒng)，而稱之為mothership。App團隊負責Rails應(yīng)用相關(guān)的所有事情，包括舊的用戶接口。Next是一個單頁面的JavaScript web應(yīng)用程序，我們遵照當時的標準實踐，將其構(gòu)建為公開API的常規(guī)客戶端，用Rails monolith實現(xiàn)的。

App和Web這兩個團隊是完全隔離的 -- 甚至在Berlin距離挺遠的不同的大廈辦公。我們幾乎只在所有人都參加的大會上才能看到彼此，主要的溝通工具是問題跟蹤系統(tǒng)和IRC。如果你問任何一個團隊的任何人我們的開發(fā)流程時如何工作的，他們可能會這么回答：

有人想到了某個功能，隨后寫了很多描述，并且畫了些模擬圖。
設(shè)計師優(yōu)化了用戶體驗。
編寫代碼。
一些測試之后，將應(yīng)用部署。

但有時候這個過程會遇到一些障礙。工程師和設(shè)計師都抱怨他們加班過多，但同時產(chǎn)品經(jīng)理和合作伙伴則抱怨他們永遠無法按時得到想要的東西。

詳細文檔請關(guān)注我們微信號，回復(fù)“SoundCloud”，獲取下載地址

5.Netflix

Cockcroft解釋他在Netflix的職位是云架構(gòu)師，他的職責不是管理架構(gòu)，而是發(fā)現(xiàn)和標準化公司工程師所形成的架構(gòu)。Netflix開發(fā)團隊提出了幾條設(shè)計和實現(xiàn)微服務(wù)架構(gòu)的最佳實踐

每個微服務(wù)的數(shù)據(jù)多帶帶存儲

不同微服務(wù)不要使用同一個后臺數(shù)據(jù)存儲。讓開發(fā)團隊選擇適合每個微服務(wù)的數(shù)據(jù)庫?；蛟S，不同團隊使用同樣的數(shù)據(jù)結(jié)構(gòu)來存儲會減少工作量，但當其中某個團隊想要更改數(shù)據(jù)結(jié)構(gòu)的時候，其他服務(wù)不得不跟著改變。

數(shù)據(jù)的拆分會使得數(shù)據(jù)管理異常復(fù)雜，是因為多帶帶的存儲系統(tǒng)不容易同步，易于出現(xiàn)不一致的情況，外鍵也會發(fā)生意外的改變。你需要一個后臺運行的主數(shù)據(jù)管理的工具來發(fā)現(xiàn)和修復(fù)不一致的情況。比如，你需要檢查每個存儲訂閱者ID的數(shù)據(jù)庫來確保所有的ID都是同一個。這個工具可以自己寫或者直接買。很多商用的關(guān)系型數(shù)據(jù)庫都提供此類核對，它常常過于耦合，不能支持很好的伸縮性。

使用類似程度的成熟度來維護代碼

微服務(wù)中所有代碼都保持同樣的類似程度的成熟度和穩(wěn)定度。也就是說，你想要重寫或給一個運行良好的已部署好的微服務(wù)添加一些代碼的話，最好的方式常常 是對于新的或要改動的代碼，新建一個微服務(wù)，現(xiàn)有的微服務(wù)丟著不管就行。 [編輯注：這種架構(gòu)常常稱之為immutable infrastructure principle.] 這樣的話，你可以迭代式的部署和測試新代碼，直至沒有bug，性能足夠好,現(xiàn)有的微服務(wù)不會出現(xiàn)故障或性能下降.一旦新的微服務(wù)和原始的服務(wù)一樣穩(wěn)定，如果確實需要進行功能合并的話，你可以將其合并在一起，或者處于性能的考慮合并它們。然而，就Cockcroft’s的經(jīng)驗來講，常常是你發(fā)現(xiàn)你的服務(wù)太大而要進行拆分。

詳細文檔請關(guān)注我們微信號，回復(fù)“Netflix”，獲取下載地址

6.Yelp

在你開始考慮設(shè)計服務(wù)之初，也就是動手寫代碼和設(shè)計之前，和團隊成員、其他服務(wù)領(lǐng)域的專家聊一聊。除了如何與現(xiàn)有的特性、產(chǎn)品以及服務(wù)如何適配之外，考慮一下你想要額外添加的功能?？紤]一種最合理的組織整體功能的方式。有時候添加新功能意味著要對現(xiàn)有組件進行重組。

我們希望避免那些簡單的 “append-only”服務(wù)架構(gòu)，也就是說development只存在于新的服務(wù)中

核實是否能夠給現(xiàn)有服務(wù)添加新的功能

在編寫新的服務(wù)之前，應(yīng)該核實是否現(xiàn)有服務(wù)不包括你的功能。它可能會與現(xiàn)有的功能存在沖突，處理相同的信息，或者只是在現(xiàn)有服務(wù)功能范圍內(nèi)的演化。另一方面，如果給現(xiàn)有服務(wù)添加新的功能會讓服務(wù)的使用者感到困惑的話，最好就不要添加新的功能了。

考慮你的功能是否更適合作為一個庫

盡管這篇文檔是講服務(wù)的，但值得注意的是一些功能更適合做成庫。為了幫助大家更好的決策，我們介紹了庫與服務(wù)之間進行取舍的一些經(jīng)驗：

升級速度 對于庫來講更適合哪些用戶期望很長時間才進行升級的場合(通常數(shù)周或數(shù)月，甚至于數(shù)年)。一般來說，這要求功能本身相對小且自包含，所以本身變更的可能就小。相反，如果你還正在進行開發(fā)，或者你希望能夠快速推送一些bug修訂給用戶，這樣的功能更適合作為一個服務(wù)。這樣功能就回更復(fù)雜一些，常常需要依賴外部的一些庫。

性能和可靠性 庫與調(diào)用請求的尋址空間一樣，而服務(wù)則處于不同的網(wǎng)絡(luò)地址。假使其他東西都是一樣的，訪問一個庫 要比服務(wù)更快更可靠。但是，如果功能對資源需求較高，比如CPU,內(nèi)存和硬盤，那么作為一個服務(wù)能夠讓客戶端的運行效率更高，能夠使得服務(wù)所依賴的硬件獨立于客戶端的硬件而水平擴展。

詳細文檔請關(guān)注我們微信號，回復(fù)“Yelp”，獲取下載地址

7.ThoughtWorks

隨著公司國際化戰(zhàn)略的推行以及本土業(yè)務(wù)的高速發(fā)展，后臺支撐系統(tǒng)已經(jīng)不堪重負。在吞吐量、穩(wěn)定性以及可擴展性上都無法滿足日益增長的業(yè)務(wù)需求。對于每10萬元額度的合同，從銷售團隊準備材料、與客戶簽單、遞交給合同部門，再到合同生效大概需要3.5人天。隨著業(yè)務(wù)量的快速增長，簽訂合同的成本急劇增加。

合同管理系統(tǒng)是后臺支撐系統(tǒng)中重要的一部分。當前的合同系統(tǒng)是5年前使用.NET基于SAGE CRM二次開發(fā)的產(chǎn)品。 一方面，系統(tǒng)架構(gòu)過于陳舊，性能、可靠性無法滿足現(xiàn)有的需求。另一方面，功能繁雜，結(jié)構(gòu)混亂，定制的代碼與SAGE CRM系統(tǒng)耦合度極高。由于是遺留系統(tǒng)，熟悉該代碼的人早已離職多時，新團隊對其望而卻步，只能做些周邊的修補工作。同時，還要承擔著邊補測試，邊整理邏輯的工作。

在無法中斷業(yè)務(wù)處理的情況下，為了解決當前面臨的問題，團隊制定了如下的策略：

1). 在現(xiàn)有合同管理系統(tǒng)的外圍，構(gòu)建功能服務(wù)接口，將系統(tǒng)核心的功能分離出來。
2). 利用這些功能服務(wù)接口作為代理，解耦原合同系統(tǒng)與其調(diào)用者之間的依賴；
3). 通過不斷構(gòu)建功能服務(wù)接口，逐漸將原有系統(tǒng)分解成多個獨立的服務(wù)。
4). 摒棄原有的合同管理系統(tǒng)，使用全新構(gòu)建的(微)服務(wù)接口替代。

隨著團隊對業(yè)務(wù)的理解加深和對微服務(wù)實踐的嘗試，數(shù)個微服務(wù)程序已經(jīng)成功構(gòu)建出來。不過，問題同時也出現(xiàn)了：對于這些不同的微服務(wù)程序而言，雖然具體實現(xiàn)的代碼細節(jié)不同，但其結(jié)構(gòu)、開發(fā)方式、持續(xù)集成環(huán)境、測試策略、部署機制以及監(jiān)控和告警等，都有著類似的實現(xiàn)方式。那么如何滿足DRY原則并消除浪費呢？帶著這個問題，經(jīng)過團隊的努力，Stencil誕生了。 Stencil是一個幫助快速構(gòu)建Ruby微服務(wù)應(yīng)用的開發(fā)框架，主要包括四部分：Stencil模板、代碼生成工具，持續(xù)集成模板以及一鍵部署工具。

Stencil模板

Stencil模板是一個獨立的Ruby代碼工程庫，主要包括代碼模板以及一組配置文件模板。

代碼模板使用Webmachine作為Web框架，RESTful和JSON構(gòu)建服務(wù)之間的通信方式，RSpec作為測試框架。同時，代碼模板還定義了一組Rake任務(wù)，譬如運行測試，查看測試報告，將當前的微服務(wù)生成RPM包，使用Koji給RPM包打標簽等。

除此之外，該模板也提供了一組通用的URL，幫助使用者查看微服務(wù)的當前版本、配置信息以及檢測該微服務(wù)程序是否健康運行等。

詳細文檔請關(guān)注我們微信號，回復(fù)“ThoughtWorks”，獲取下載地址

京東

京東資深架構(gòu)師李鑫主要負責京東的服務(wù)框架， 他所分享的內(nèi)容是對微服務(wù)底層的技術(shù)框架支持。

為何要微服務(wù)化？

1.系統(tǒng)規(guī)模隨著業(yè)務(wù)的發(fā)展?而增長，原有系統(tǒng)架構(gòu)模式中邏輯過于耦合，不再適應(yīng)；
2.拆分后的?系統(tǒng)邏輯內(nèi)聚，易于局部擴展；
3.?系統(tǒng)之間通過接?口來進?交互，接?契約不變的情況下可獨?變化。

上圖中，左邊是幾年前京東的架構(gòu)，很多服務(wù)都是訪問同樣一個DB。這種架構(gòu)的問題在于：流量來了以后全部壓力都在DB上。而且在之前京東的架構(gòu)里比較強調(diào)快速開發(fā)，很多邏輯比如說倉儲配送服務(wù)都不存在，全都依靠BD來進行。這樣可擴展性相當差，性能也不太可控。后來，我們根據(jù)業(yè)務(wù)模塊和特性進行水平拆分，應(yīng)用和應(yīng)用之間都要通過接口進行交互，有同步和異步接口。

團隊在2014年推出了新服務(wù)平臺JSF，其框架示意圖如下。

可以看出，服務(wù)注冊和尋址沒有太大變化，主要變化在于注冊中心。采用團隊自己寫的服務(wù)，并提供了index服務(wù)數(shù)據(jù)庫。相對來講，詢問注冊中心地址，會進行一個服務(wù)的調(diào)用。因為這一塊有自己內(nèi)部的邏輯，沒有辦法實現(xiàn)，所以定期會發(fā)送性能統(tǒng)計數(shù)據(jù)。把RPC轉(zhuǎn)化，生成負載均衡管理重試策略，然后經(jīng)過序列化以后發(fā)送到server并解碼，再進行實際的業(yè)務(wù)調(diào)用，然后進行一些過濾的邏輯。

詳細文檔請關(guān)注我們微信號，回復(fù)“京東”，獲取下載地址

七牛

肖勤介紹重點介紹了七牛圖片處理（FOP）場景的微服務(wù)應(yīng)用。FOP服務(wù)早期的架構(gòu)以它的每一個應(yīng)用為后端。隨著用戶越來越多，流量越來越高，負載均衡逐漸出現(xiàn)了帶寬和流量的壓力。

七牛將圖像處理服務(wù)拆成兩個部分，分別負責處理文件的傳輸和圖像本身的處理。從負載均衡過來的請求不再是完整的文件，而是文件的地址。這樣，負載均衡和流量優(yōu)化跟整個圖像處理沒有關(guān)系，可以做多帶帶的部署。而對于稍微復(fù)雜一些的請求（如圖片格式和尺寸的變更，添加水?。?，就用管道的方式把不同的服務(wù)串聯(lián)起來最終實現(xiàn)。

詳細文檔請關(guān)注我們微信號，回復(fù)“七?！?，獲取下載地址

10 好雨云

微服務(wù)架構(gòu)是好雨云基礎(chǔ)組件，好雨云的很多功能都跑在它上，好雨微服務(wù)架構(gòu)的第一個用戶就是好雨云自身，在這個過程中我們也體會到微服務(wù)架構(gòu)給我們帶來的便捷。

好雨云的微服務(wù)包括：

控制臺服務(wù) —— python 實現(xiàn)
實時消息服務(wù) —— java 實現(xiàn)
計費服務(wù) —— python實現(xiàn)
統(tǒng)計服務(wù) —— java實現(xiàn)
日志服務(wù) —— c 實現(xiàn)
redis服務(wù) —— dockerfile 構(gòu)建
mysql服務(wù) —— dockerfile構(gòu)建

我們技術(shù)團隊每個人擅長的開發(fā)語言不同，在微服務(wù)中也有體現(xiàn)，喜歡python的開發(fā)者用python開發(fā)微服務(wù)，喜歡java的開發(fā)者用java開發(fā)，適合用c的微服務(wù)用c開發(fā)，開源的服務(wù)直接用dockerfile構(gòu)建。新來的開發(fā)人員不需要學習就可以開始開發(fā)。

好雨云微服務(wù)的開發(fā)過程全部在云平臺上進行，本地沒有設(shè)置開發(fā)和測試環(huán)境，我們?yōu)槊恳粋€微服務(wù)建立兩個應(yīng)用，一套是開發(fā)測試應(yīng)用，另一套是生產(chǎn)應(yīng)用，開發(fā)測試應(yīng)用關(guān)聯(lián)開發(fā)代碼分支，依賴測試數(shù)據(jù)服務(wù)，生產(chǎn)應(yīng)用關(guān)聯(lián)代碼主干，依賴生產(chǎn)數(shù)據(jù)服務(wù)，開發(fā)人員日常開發(fā)調(diào)試在開發(fā)測試應(yīng)用進行，代碼提交開發(fā)分支，點擊部署，馬上就能看見應(yīng)用的效果，測試通過的應(yīng)用，將代碼合并到主干，點擊生產(chǎn)應(yīng)用的部署，完成上線過程，如果代碼有重大bug，點擊日志中的“代碼回滾”就能迅速回滾到上一個代碼版本。

除此之外服務(wù)高可用、服務(wù)伸縮、服務(wù)容錯這些需求都交給好雨微服務(wù)架構(gòu)組件去解決，通過這樣的方法我們一天最多上線50多個版本，而過程中用戶的服務(wù)沒有異常中斷。

控制臺服務(wù)是用戶使用量比較大的服務(wù)，為了優(yōu)化性能，我們重度依賴應(yīng)用實時性能分析，它可以分析出對性能影響最大的SQL和URL，優(yōu)化完SQL和對應(yīng)的程序，上線后立馬就能看見效果。并根據(jù)效果繼續(xù)優(yōu)化。對服務(wù)的伸縮，我們依賴于實時業(yè)務(wù)監(jiān)控，通過監(jiān)測總體響應(yīng)時間和吞吐率決定服務(wù)是擴容還是縮容。

通過好雨微服務(wù)架構(gòu)來開發(fā)好雨云的特性， 我們踐行了“吃自己的狗糧”，并持續(xù)優(yōu)化著好雨微服務(wù)架構(gòu)，做為第一個微服務(wù)架構(gòu)的用戶我們也從中受益，我們在環(huán)境問題、系統(tǒng)管理、性能優(yōu)化、服務(wù)伸縮和代碼發(fā)布上線上幾乎沒有浪費時間，讓我們更加專注產(chǎn)品本身，快速迭代。

詳細文檔請關(guān)注我們微信號，回復(fù)“好雨云”，獲取下載地址

更多精彩內(nèi)容請掃描下方二維碼輕松獲取。