【乾貨下載】谷歌、亞馬遜等十大公司精選微服務案例
阿新 • • 發佈：2019-01-26
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”，獲取下載地址
8. 京東
京東資深架構師李鑫主要負責京東的服務框架， 他所分享的內容是對微服務底層的技術框架支援。
為何要微服務化？
1.系統規模隨著業務的發展⽽而增長，原有系統架構模式中邏輯過於耦合，不再適應；
2.拆分後的⼦系統邏輯內聚，易於區域性擴充套件；
3.⼦系統之間通過接⼝口來進⾏互動，接⼝契約不變的情況下可獨⽴變化。
上圖中，左邊是幾年前京東的架構，很多服務都是訪問同樣一個DB。這種架構的問題在於：流量來了以後全部壓力都在DB上。而且在之前京東的架構裡比較強調快速開發，很多邏輯比如說倉儲配送服務都不存在，全都依靠BD來進行。這樣可擴充套件性相當差，效能也不太可控。後來，我們根據業務模組和特性進行水平拆分，應用和應用之間都要通過介面進行互動，有同步和非同步介面。
團隊在2014年推出了新服務平臺JSF，其框架示意圖如下。
可以看出，服務註冊和定址沒有太大變化，主要變化在於註冊中心。採用團隊自己寫的服務，並提供了index服務資料庫。相對來講，詢問註冊中心地址，會進行一個服務的呼叫。因為這一塊有自己內部的邏輯，沒有辦法實現，所以定期會發送效能統計資料。把RPC轉化，生成負載均衡管理重試策略，然後經過序列化以後傳送到server並解碼，再進行實際的業務呼叫，然後進行一些過濾的邏輯。
詳細文件請關注我們微訊號，回覆“京東”，獲取下載地址
9. 七牛
肖勤介紹重點介紹了七牛圖片處理（FOP）場景的微服務應用。FOP服務早期的架構以它的每一個應用為後端。隨著使用者越來越多，流量越來越高，負載均衡逐漸出現了頻寬和流量的壓力。
七牛將影象處理服務拆成兩個部分，分別負責處理檔案的傳輸和影象本身的處理。從負載均衡過來的請求不再是完整的檔案，而是檔案的地址。這樣，負載均衡和流量優化跟整個影象處理沒有關係，可以做單獨的部署。而對於稍微複雜一些的請求（如圖片格式和尺寸的變更，新增水印），就用管道的方式把不同的服務串聯起來最終實現。
詳細文件請關注我們微訊號，回覆“七牛”，獲取下載地址
10 好雨雲
微服務架構是好雨雲基礎元件，好雨雲的很多功能都跑在它上，好雨微服務架構的第一個使用者就是好雨雲自身，在這個過程中我們也體會到微服務架構給我們帶來的便捷。
好雨雲的微服務包括：
控制檯服務 —— python 實現
實時訊息服務 —— java 實現
計費服務 —— python實現
統計服務 —— java實現
日誌服務 —— c 實現
redis服務 —— dockerfile 構建
mysql服務 —— dockerfile構建
我們技術團隊每個人擅長的開發語言不同，在微服務中也有體現，喜歡python的開發者用python開發微服務，喜歡java的開發者用java開發，適合用c的微服務用c開發，開源的服務直接用dockerfile構建。新來的開發人員不需要學習就可以開始開發。
好雨雲微服務的開發過程全部在雲平臺上進行，本地沒有設定開發和測試環境，我們為每一個微服務建立兩個應用，一套是開發測試應用，另一套是生產應用，開發測試應用關聯開發程式碼分支，依賴測試資料服務，生產應用關聯程式碼主幹，依賴生產資料服務，開發人員日常開發除錯在開發測試應用進行，程式碼提交開發分支，點選部署，馬上就能看見應用的效果，測試通過的應用，將程式碼合併到主幹，點選生產應用的部署，完成上線過程，如果程式碼有重大bug，點選日誌中的“程式碼回滾”就能迅速回滾到上一個程式碼版本。
除此之外服務高可用、服務伸縮、服務容錯這些需求都交給好雨微服務架構元件去解決，通過這樣的方法我們一天最多上線50多個版本，而過程中使用者的服務沒有異常中斷。
控制檯服務是使用者使用量比較大的服務，為了優化效能，我們重度依賴應用實時效能分析，它可以分析出對效能影響最大的SQL和URL，優化完SQL和對應的程式，上線後立馬就能看見效果。並根據效果繼續優化。對服務的伸縮，我們依賴於實時業務監控，通過監測總體響應時間和吞吐率決定服務是擴容還是縮容。
通過好雨微服務架構來開發好雨雲的特性， 我們踐行了“吃自己的狗糧”，並持續優化著好雨微服務架構，做為第一個微服務架構的使用者我們也從中受益，我們在環境問題、系統管理、效能優化、服務伸縮和程式碼釋出上線上幾乎沒有浪費時間，讓我們更加專注產品本身，快速迭代。
詳細文件請關注我們微訊號，回覆“好雨雲”，獲取下載地址
更多精彩內容請掃描下方二維碼輕鬆獲取。
