自去年以來，微服務受到了前所未有的關注，衆多的網際網路巨頭開始實施微服務架構并取得了不錯的反響，話不多說，今天我們就為大家盤點一下谷歌、亞馬遜等十大科技公司的微服務實踐案例。
1. 谷歌
擁有多元化微服務的大規模生态系統運作情況如何呢？
eBay和Google采用了數百到數千個單獨的服務來協同工作；
現在的大規模系統都是以圖的形式，而不是層次式或多個連接配接的形式來構成服務；
服務之間互相依賴；
隻有舊的大規模系統采用高度內建的方式進行組織……
關注好雨微信服務号，回複“谷歌”，擷取下載下傳位址
2. 亞馬遜
Amazon DevOps部門業務開發經理Munns列舉了微服務4條使用限制：
1）單一目的
2）僅通過API進行連接配接
3）通過HTTPS協定進行連接配接
4）微服務之間大體以黑盒的方式展現……
關注好雨微信服務号，回複“亞馬遜”，擷取下載下傳位址
3. Twitter
目前能夠以規模化方式運作微服務，進而解決實際問題的企業數量仍然相當有限。Twitter就是其中的典型代表，盡管其也經曆過公共服務中斷，但Twitter中包含上百種服務、數以萬計的節點以及每項服務中的數百萬RPS，是世界上規模最大的微服務應用之一……
關注好雨微信服務号，回複“Twitter”，擷取下載下傳位址
4. SoundCloud
很多的技術文章着重介紹的都是項目後總結出的最佳實踐，SoundCloud從另外的角度，介紹項目中解決問題的整個探索過程，詳細講述了在最終使用微服務架構之前所做的種種分析和嘗試，這對于正在嘗試解決問題的技術人員來說有很大的啟示作用……
關注好雨微信服務号，回複“SoundCloud”，擷取下載下傳位址
5. Netflix
想要重寫或給一個運作良好的已部署好的微服務添加一些代碼的話，最好的方式常常是對于新的或要改動的代碼，建立一個微服務。然而，就Netflix的經驗來講，情況常常是發現服務太大而要進行拆分……
關注好雨微信服務号，回複“Netflix”，擷取下載下傳位址
6. Yelp
在你開始考慮設計服務之初和團隊成員、其他服務領域的專家聊一聊；
除了如何與現有的特性、産品以及服務如何适配之外，考慮一下你想要額外添加的功能；
考慮一種最合理的組織整體功能的方式；
有時候添加新功能意味着要對現有元件進行重組……
關注好雨微信服務号，回複“Yelp”，擷取下載下傳位址
7. ThoughtWorks
随着公司國際化戰略的推行以及本土業務的高速發展，背景支撐系統已經不堪重負。在吞吐量、穩定性以及可擴充性上都無法滿足日益增長的業務需求。對于每10萬元額度的合同，從銷售團隊準備材料、與客戶簽單、遞交給合同部門，再到合同生效大概需要3.5人天。随着業務量的快速增長，簽訂合同的成本急劇增加……
關注好雨微信服務号，回複“ThoughtWorks”，擷取下載下傳位址
8. 京東
為何要微服務化？
1.系統規模随着業務的發展⽽而增長，原有系統架構模式中邏輯過于耦合，不再适應；
2.拆分後的⼦系統邏輯内聚，易于局部擴充；
3.⼦系統之間通過接⼝口來進⾏互動，接⼝契約不變的情況下可獨⽴變化……
關注好雨微信服務号，回複“京東”，擷取下載下傳位址
9. 七牛
七牛将圖像處理服務拆成兩個部分，分别負責處理檔案的傳輸和圖像本身的處理。從負載均衡過來的請求不再是完整的檔案，而是檔案的位址。這樣一來，負載均衡和流量優化跟整個圖像處理沒有關系，可以做單獨的部署。而對于稍微複雜一些的請求（如圖檔格式和尺寸的變更，添加水印），就用管道的方式把不同的服務串聯起來最終實作……
關注好雨微信服務号，回複“七牛”，擷取下載下傳位址
10. 好雨
微服務架構是好雨基礎元件，好雨雲幫的很多功能都跑在它上，好雨微服務架構的第一個使用者就是好雨雲幫自身，在這個過程中我們也體會到微服務架構給我們帶來的便捷。
好雨雲幫的微服務包括：
控制台服務 —— python 實作
實時消息服務 —— java 實作
計費服務 —— python實作
統計服務 —— java實作
日志服務 —— c 實作
redis服務 —— dockerfile 建構
mysql服務 —— dockerfile建構
我們技術團隊每個人擅長的開發語言不同，在微服務中也有展現，喜歡python的開發者用python開發微服務，喜歡java的開發者用java開發，适合用c的微服務用c開發，開源的服務直接用dockerfile建構。新來的開發人員不需要學習就可以開始開發。
好雨雲幫微服務的開發過程全部在雲平台上進行，本地沒有設定開發和測試環境，我們為每一個微服務建立兩個應用，一套是開發測試應用，另一套是生産應用，開發測試應用關聯開發代碼分支，依賴測試資料服務，生産應用關聯代碼主幹，依賴生産資料服務，開發人員日常開發調試在開發測試應用進行，代碼送出開發分支，點選部署，馬上就能看見應用的效果，測試通過的應用，将代碼合并到主幹，點選生産應用的部署，完成上線過程，如果代碼有重大bug，點選日志中的“代碼復原”就能迅速復原到上一個代碼版本。
除此之外服務高可用、服務伸縮、服務容錯這些需求都交給好雨微服務架構元件去解決，通過這樣的方法我們一天最多上線50多個版本，而過程中使用者的服務沒有異常中斷。
控制台服務是使用者使用量比較大的服務，為了優化性能，我們重度依賴應用實時性能分析，它可以分析出對性能影響最大的SQL和URL，優化完SQL和對應的程式，上線後立馬就能看見效果。并根據效果繼續優化。對服務的伸縮，我們依賴于實時業務監控，通過監測總體響應時間和吞吐率決定服務是擴容還是縮容。
通過好雨微服務架構來開發好雨雲幫的特性，我們踐行了“吃自己的狗糧”，并持續優化着好雨微服務架構，做為第一個微服務架構的使用者我們也從中受益，我們在環境問題、系統管理、性能優化、服務伸縮和代碼釋出上線上幾乎沒有浪費時間，讓我們更加專注産品本身，快速疊代……