自去年以來,微服務受到了史無前例的關注,衆多的互聯網巨頭開始實施微服務架構並取得了不錯的反響,話很少說,今天咱們就爲你們盤點一下谷歌、亞馬遜等十大科技公司的微服務實踐案例。
1. 谷歌
擁有多元化微服務的大規模生態系統運行狀況如何呢?
eBay和Google採用了數百到數千個單獨的服務來協同工做;
如今的大規模系統都是以圖的形式,而不是層次式或多個鏈接的形式來構成服務;
服務之間相互依賴;
只有舊的大規模系統採用高度集成的方式進行組織……java
關注好雨微信服務號,回覆「谷歌」,獲取下載地址
2. 亞馬遜python
Amazon DevOps部門業務開發經理Munns列舉了微服務4條使用限制:mysql
1)單一目的redis
2)僅經過API進行鏈接sql
3)經過HTTPS協議進行鏈接docker
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和對應的程序,上線後立馬就能看見效果。並根據效果繼續優化。對服務的伸縮,咱們依賴於實時業務監控,經過監測整體響應時間和吞吐率決定服務是擴容仍是縮容。
經過好雨微服務架構來開發好雨雲幫的特性,咱們踐行了「吃本身的狗糧」,並持續優化着好雨微服務架構,作爲第一個微服務架構的用戶咱們也從中受益,咱們在環境問題、系統管理、性能優化、服務伸縮和代碼發佈上線上幾乎沒有浪費時間,讓咱們更加專一產品自己,快速迭代……
關注好雨微信服務號,回覆「好雨雲幫」,獲取下載地址