【乾貨下載】谷歌、亞馬遜等十大公司精選微服務案例

自去年以來，微服務受到了史無前例的關注，衆多的互聯網巨頭開始實施微服務架構並取得了不錯的反響，話很少說，今天咱們就爲你們盤點一下谷歌、亞馬遜等十大科技公司的微服務實踐案例。

1. 谷歌

隨着多元化微服務的流行，愈來愈多的服務開始採用微服務來構建。近日，曾在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. 京東

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

爲什麼要微服務化？

1.系統規模隨着業務的發展⽽而增加，原有系統架構模式中邏輯過於耦合，再也不適應；
2.拆分後的⼦系統邏輯內聚，易於局部擴展；
3.⼦系統之間經過接⼝口來進⾏交互，接⼝契約不變的狀況下可獨⽴變化。

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

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

能夠看出，服務註冊和尋址沒有太大變化，主要變化在於註冊中心。採用團隊本身寫的服務，並提供了index服務數據庫。相對來說，詢問註冊中心地址，會進行一個服務的調用。由於這一塊有本身內部的邏輯，沒有辦法實現，因此按期會發送性能統計數據。把RPC轉化，生成負載均衡管理重試策略，而後通過序列化之後發送到server並解碼，再進行實際的業務調用，而後進行一些過濾的邏輯。

詳細文檔請關注咱們微信號，回覆「京東」，獲取下載地址

1. 七牛

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

七牛將圖像處理服務拆成兩個部分，分別負責處理文件的傳輸和圖像自己的處理。從負載均衡過來的請求再也不是完整的文件，而是文件的地址。這樣，負載均衡和流量優化跟整個圖像處理沒有關係，能夠作單獨的部署。而對於稍微複雜一些的請求（如圖片格式和尺寸的變動，添加水印），就用管道的方式把不一樣的服務串聯起來最終實現。

詳細文檔請關注咱們微信號，回覆「七牛」，獲取下載地址

10 好雨雲

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

好雨雲的微服務包括：

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

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

好雨雲微服務的開發過程所有在雲平臺上進行，本地沒有設置開發和測試環境，咱們爲每個微服務創建兩個應用，一套是開發測試應用，另外一套是生產應用，開發測試應用關聯開發代碼分支，依賴測試數據服務，生產應用關聯代碼主幹，依賴生產數據服務，開發人員平常開發調試在開發測試應用進行，代碼提交開發分支，點擊部署，立刻就能看見應用的效果，測試經過的應用，將代碼合併到主幹，點擊生產應用的部署，完成上線過程，若是代碼有重大bug，點擊日誌中的「代碼回滾」就能迅速回滾到上一個代碼版本。

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

控制檯服務是用戶使用量比較大的服務，爲了優化性能，咱們重度依賴應用實時性能分析，它能夠分析出對性能影響最大的SQL和URL，優化完SQL和對應的程序，上線後立馬就能看見效果。並根據效果繼續優化。對服務的伸縮，咱們依賴於實時業務監控，經過監測整體響應時間和吞吐率決定服務是擴容仍是縮容。

經過好雨微服務架構來開發好雨雲的特性， 咱們踐行了「吃本身的狗糧」，並持續優化着好雨微服務架構，作爲第一個微服務架構的用戶咱們也從中受益，咱們在環境問題、系統管理、性能優化、服務伸縮和代碼發佈上線上幾乎沒有浪費時間，讓咱們更加專一產品自己，快速迭代。

詳細文檔請關注咱們微信號，回覆「好雨雲」，獲取下載地址

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