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

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

谷歌

隨著多元化微服務的流行，越來越多的服務開始采用微服務來構建。近日，曾在Google和eBay擔任高級職務的Randy Shoup在博客中分享了其從這兩個公司所學習到的構建大規模服務架構的經驗。本文對Randy談論的內容進行了總結，為那些沒有創建、使用和保護大規模架構的工程師提供參考。

擁有多元化微服務的大規模生態系統運行情況如何呢？

eBay和Google采用了數百到數千個多帶帶的服務來協同工作。
現在的大規模系統都是以圖的形式，而不是層次式或多個連接的形式來構成服務。
服務之間相互依賴。
只有舊的大規模系統采用高度集成的方式進行組織。

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

詳細文檔請關注我們微信號，回復“京東”，獲取下載地址

2.亞馬遜

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

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

全面的培訓。
由具有20年以上開發經驗的員工全面定義各種模式與實踐。
在業務與技術兩方面定期進行衡量指標審查。
由內部的專家分享關于新工具、服務與技術的知識。

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

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

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

詳細文檔請關注我們微信號，回復“亞馬遜”，獲取下載地址

3.Twitter

在圍繞微服務展開的探討當中，我們發現幾乎很少有人能夠切實回答上述問題。以Docker、Mesos、Kubernetes以及gRPC為代表的各類新型技術成果的快速崛起使得我們能夠輕松建立小型新架構。然而，高流量生產性用例又該如何實現？根據我們的推算，目前能夠以規模化方式運行微服務，從而解決實際問題的企業數量仍然相當有限。

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

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

詳細文檔請關注我們微信號，回復“Twitter”，獲取下載地址

4.SoundCloud

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

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

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

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

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

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

詳細文檔請關注我們微信號，回復“SoundCloud”，獲取下載地址

5.Netflix

Cockcroft解釋他在Netflix的職位是云架構師，他的職責不是管理架構，而是發現和標準化公司工程師所形成的架構。Netflix開發團隊提出了幾條設計和實現微服務架構的最佳實踐

每個微服務的數據多帶帶存儲

不同微服務不要使用同一個后臺數據存儲。讓開發團隊選擇適合每個微服務的數據庫。或許，不同團隊使用同樣的數據結構來存儲會減少工作量，但當其中某個團隊想要更改數據結構的時候，其他服務不得不跟著改變。

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

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

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

詳細文檔請關注我們微信號，回復“Netflix”，獲取下載地址

6.Yelp

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

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

核實是否能夠給現有服務添加新的功能

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

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

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

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

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

詳細文檔請關注我們微信號，回復“Yelp”，獲取下載地址

7.ThoughtWorks

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

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

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

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

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

Stencil模板

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

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

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

詳細文檔請關注我們微信號，回復“ThoughtWorks”，獲取下載地址

京東

京東資深架構師李鑫主要負責京東的服務框架， 他所分享的內容是對微服務底層的技術框架支持。

為何要微服務化？

1.系統規模隨著業務的發展?而增長，原有系統架構模式中邏輯過于耦合，不再適應；
2.拆分后的?系統邏輯內聚，易于局部擴展；
3.?系統之間通過接?口來進?交互，接?契約不變的情況下可獨?變化。

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

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

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

詳細文檔請關注我們微信號，回復“京東”，獲取下載地址

七牛

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

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

詳細文檔請關注我們微信號，回復“七牛”，獲取下載地址

10 好雨云

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

好雨云的微服務包括：

控制臺服務 —— python 實現
實時消息服務 —— java 實現
計費服務 —— python實現
統計服務 —— java實現
日志服務 —— c 實現
redis服務 —— dockerfile 構建
mysql服務 —— dockerfile構建

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

好雨云微服務的開發過程全部在云平臺上進行，本地沒有設置開發和測試環境，我們為每一個微服務建立兩個應用，一套是開發測試應用，另一套是生產應用，開發測試應用關聯開發代碼分支，依賴測試數據服務，生產應用關聯代碼主干，依賴生產數據服務，開發人員日常開發調試在開發測試應用進行，代碼提交開發分支，點擊部署，馬上就能看見應用的效果，測試通過的應用，將代碼合并到主干，點擊生產應用的部署，完成上線過程，如果代碼有重大bug，點擊日志中的“代碼回滾”就能迅速回滾到上一個代碼版本。

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

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

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

詳細文檔請關注我們微信號，回復“好雨云”，獲取下載地址

更多精彩內容請掃描下方二維碼輕松獲取。