摘要：自去年以來(lái)，微服務(wù)受到了前所未有的關(guān)注，眾多的互聯(lián)網(wǎng)巨頭開(kāi)始實(shí)施微服務(wù)架構(gòu)并取得了不錯(cuò)的反響，話不多說(shuō)，今天我們就為大家盤(pán)點(diǎn)一下谷歌亞馬遜等十大科技公司的微服務(wù)實(shí)踐案例。

自去年以來(lái)，微服務(wù)受到了前所未有的關(guān)注，眾多的互聯(lián)網(wǎng)巨頭開(kāi)始實(shí)施微服務(wù)架構(gòu)并取得了不錯(cuò)的反響，話不多說(shuō)，今天我們就為大家盤(pán)點(diǎn)一下谷歌、亞馬遜等十大科技公司的微服務(wù)實(shí)踐案例。

谷歌

隨著多元化微服務(wù)的流行，越來(lái)越多的服務(wù)開(kāi)始采用微服務(wù)來(lái)構(gòu)建。近日，曾在Google和eBay擔(dān)任高級(jí)職務(wù)的Randy Shoup在博客中分享了其從這兩個(gè)公司所學(xué)習(xí)到的構(gòu)建大規(guī)模服務(wù)架構(gòu)的經(jīng)驗(yàn)。本文對(duì)Randy談?wù)摰膬?nèi)容進(jìn)行了總結(jié)，為那些沒(méi)有創(chuàng)建、使用和保護(hù)大規(guī)模架構(gòu)的工程師提供參考。

擁有多元化微服務(wù)的大規(guī)模生態(tài)系統(tǒng)運(yùn)行情況如何呢？

eBay和Google采用了數(shù)百到數(shù)千個(gè)多帶帶的服務(wù)來(lái)協(xié)同工作。
現(xiàn)在的大規(guī)模系統(tǒng)都是以圖的形式，而不是層次式或多個(gè)連接的形式來(lái)構(gòu)成服務(wù)。
服務(wù)之間相互依賴。
只有舊的大規(guī)模系統(tǒng)采用高度集成的方式進(jìn)行組織。

目前運(yùn)行良好的系統(tǒng)都是不斷變革的產(chǎn)物。例如，Google從來(lái)沒(méi)有對(duì)系統(tǒng)進(jìn)行過(guò)集中的設(shè)計(jì)。當(dāng)前的系統(tǒng)純粹是適應(yīng)時(shí)代和技術(shù)發(fā)展演變而成的。變異和自然選擇。當(dāng)一個(gè)新的問(wèn)題出現(xiàn)，工程師通常選擇利用已有的產(chǎn)品或服務(wù)來(lái)解決。因此，一個(gè)服務(wù)只有在不斷的提供價(jià)值、不斷被使用的情況下，才能避免被淘汰的命運(yùn)。

詳細(xì)文檔請(qǐng)關(guān)注我們微信號(hào)，回復(fù)“京東”，獲取下載地址

2.亞馬遜

Munns是Amazon的DevOps部門(mén)的業(yè)務(wù)開(kāi)發(fā)經(jīng)理，他在演講中引用了維基百科上微服務(wù)的定義，但同時(shí)也列舉了微服務(wù)的4條使用上的限制：
單一目的。
僅通過(guò)API進(jìn)行連接。
通過(guò)HTTPS協(xié)議進(jìn)行連接。
微服務(wù)之間大體以黑盒的方式展現(xiàn)。

描述團(tuán)隊(duì)的規(guī)模有一個(gè)著名的術(shù)語(yǔ)，即剛好能吃完兩只披薩的團(tuán)隊(duì)。在Amazon，這樣的團(tuán)隊(duì)被稱為服務(wù)團(tuán)隊(duì)，他們對(duì)于創(chuàng)建過(guò)程具有完全的自主權(quán)，包括產(chǎn)品的計(jì)劃、開(kāi)發(fā)工作、運(yùn)維以及客戶支持。他們具備完全的自主權(quán)及責(zé)任性，同時(shí)也負(fù)責(zé)每日的運(yùn)維和維護(hù)工作。換句話說(shuō)，誰(shuí)創(chuàng)建的服務(wù)，就由誰(shuí)負(fù)責(zé)運(yùn)行。這意味著質(zhì)量保證（QA）人員以及運(yùn)維人員都隸屬于服務(wù)團(tuán)隊(duì)之中。但Munns也提到，承擔(dān)這一角色的部分員工也有可能由整個(gè)組織共享。
對(duì)于團(tuán)隊(duì)來(lái)說(shuō)，這樣的文化意味著很高的自由度，但這些團(tuán)隊(duì)將通過(guò)以下途徑得到授權(quán)并保證實(shí)施的高標(biāo)準(zhǔn)：

全面的培訓(xùn)。
由具有20年以上開(kāi)發(fā)經(jīng)驗(yàn)的員工全面定義各種模式與實(shí)踐。
在業(yè)務(wù)與技術(shù)兩方面定期進(jìn)行衡量指標(biāo)審查。
由內(nèi)部的專家分享關(guān)于新工具、服務(wù)與技術(shù)的知識(shí)。

Munn對(duì)于小型團(tuán)隊(duì)與微服務(wù)在Amazon的發(fā)展進(jìn)行了深入的觀察，以了解其重點(diǎn)所在。對(duì)于其他打算按照相同方式發(fā)展的組織，Munn提出了一些建議：

文化 —— 這里要強(qiáng)調(diào)一點(diǎn)，自主權(quán)與責(zé)任是不可分離的，規(guī)模越大的團(tuán)隊(duì)，其運(yùn)作速度相對(duì)于小型團(tuán)隊(duì)將有所下降。團(tuán)隊(duì)要堅(jiān)持卓越產(chǎn)品的標(biāo)準(zhǔn)，但并非堅(jiān)守做事的方式一成不變。
實(shí)踐 —— Munn提到了持續(xù)集成（CI）與持續(xù)交付（CD），以及簡(jiǎn)化運(yùn)維任務(wù)的重要性。
工具 —— 這些工具將用于之前所提到的實(shí)踐、基礎(chǔ)設(shè)施的管理、指標(biāo)的設(shè)立和監(jiān)控，以及交流和協(xié)作。

Munns最后強(qiáng)調(diào)了為服務(wù)和客戶建立起一種模式的重要性，這將使組織避免重復(fù)發(fā)明一些相同的基礎(chǔ)部件，將精力浪費(fèi)在通信、授權(quán)、防止濫用和服務(wù)發(fā)現(xiàn)等任務(wù)上。他還闡述了構(gòu)建、托管、服務(wù)的指標(biāo)對(duì)于觀察基礎(chǔ)設(shè)施是否按預(yù)期運(yùn)行、SLA是否得到滿足等問(wèn)題的重要性。

詳細(xì)文檔請(qǐng)關(guān)注我們微信號(hào)，回復(fù)“亞馬遜”，獲取下載地址

3.Twitter

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

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

當(dāng)Oliver和我前幾年離開(kāi)Twitter公司時(shí)，我們的目標(biāo)是運(yùn)用自己多年積累下的專業(yè)知識(shí)，將其轉(zhuǎn)化成可供全世界各組織機(jī)構(gòu)使用的可行性資源。令人振奮的是，這些知識(shí)中已經(jīng)有相當(dāng)一部分以開(kāi)源項(xiàng)目的面貌了，也就是Finagle項(xiàng)目——這是一套用于支撐Twitter微服務(wù)架構(gòu)的高通量RPC庫(kù)。

詳細(xì)文檔請(qǐng)關(guān)注我們微信號(hào)，回復(fù)“Twitter”，獲取下載地址

4.SoundCloud

很多的技術(shù)文章著重介紹的都是項(xiàng)目后總結(jié)出的最佳實(shí)踐，本文從另外的角度，介紹項(xiàng)目中解決問(wèn)題的整個(gè)探索過(guò)程，詳細(xì)講述了在最終使用微服務(wù)架構(gòu)之前所做的種種分析和嘗試，這對(duì)于正在嘗試解決問(wèn)題的技術(shù)人員來(lái)說(shuō)有很大的啟示作用。

當(dāng)我最初加入公司的時(shí)候，手頭最重要的項(xiàng)目?jī)?nèi)部稱之為v2。該項(xiàng)目對(duì)我們的網(wǎng)站做徹底的改版，發(fā)布時(shí)的商標(biāo)名稱為T(mén)he Next SoundCloud。

一開(kāi)始我加入了后端團(tuán)隊(duì)，App團(tuán)隊(duì)。我們負(fù)責(zé)巨大的Ruby on Rails應(yīng)用程序。那時(shí)候還不稱其為遺留系統(tǒng)，而稱之為mothership。App團(tuán)隊(duì)負(fù)責(zé)Rails應(yīng)用相關(guān)的所有事情，包括舊的用戶接口。Next是一個(gè)單頁(yè)面的JavaScript web應(yīng)用程序，我們遵照當(dāng)時(shí)的標(biāo)準(zhǔn)實(shí)踐，將其構(gòu)建為公開(kāi)API的常規(guī)客戶端，用Rails monolith實(shí)現(xiàn)的。

App和Web這兩個(gè)團(tuán)隊(duì)是完全隔離的 -- 甚至在Berlin距離挺遠(yuǎn)的不同的大廈辦公。我們幾乎只在所有人都參加的大會(huì)上才能看到彼此，主要的溝通工具是問(wèn)題跟蹤系統(tǒng)和IRC。如果你問(wèn)任何一個(gè)團(tuán)隊(duì)的任何人我們的開(kāi)發(fā)流程時(shí)如何工作的，他們可能會(huì)這么回答：

有人想到了某個(gè)功能，隨后寫(xiě)了很多描述，并且畫(huà)了些模擬圖。
設(shè)計(jì)師優(yōu)化了用戶體驗(yàn)。
編寫(xiě)代碼。
一些測(cè)試之后，將應(yīng)用部署。

但有時(shí)候這個(gè)過(guò)程會(huì)遇到一些障礙。工程師和設(shè)計(jì)師都抱怨他們加班過(guò)多，但同時(shí)產(chǎn)品經(jīng)理和合作伙伴則抱怨他們永遠(yuǎn)無(wú)法按時(shí)得到想要的東西。

詳細(xì)文檔請(qǐng)關(guān)注我們微信號(hào)，回復(fù)“SoundCloud”，獲取下載地址

5.Netflix

Cockcroft解釋他在Netflix的職位是云架構(gòu)師，他的職責(zé)不是管理架構(gòu)，而是發(fā)現(xiàn)和標(biāo)準(zhǔn)化公司工程師所形成的架構(gòu)。Netflix開(kāi)發(fā)團(tuán)隊(duì)提出了幾條設(shè)計(jì)和實(shí)現(xiàn)微服務(wù)架構(gòu)的最佳實(shí)踐

每個(gè)微服務(wù)的數(shù)據(jù)多帶帶存儲(chǔ)

不同微服務(wù)不要使用同一個(gè)后臺(tái)數(shù)據(jù)存儲(chǔ)。讓開(kāi)發(fā)團(tuán)隊(duì)選擇適合每個(gè)微服務(wù)的數(shù)據(jù)庫(kù)?；蛟S，不同團(tuán)隊(duì)使用同樣的數(shù)據(jù)結(jié)構(gòu)來(lái)存儲(chǔ)會(huì)減少工作量，但當(dāng)其中某個(gè)團(tuán)隊(duì)想要更改數(shù)據(jù)結(jié)構(gòu)的時(shí)候，其他服務(wù)不得不跟著改變。

數(shù)據(jù)的拆分會(huì)使得數(shù)據(jù)管理異常復(fù)雜，是因?yàn)槎鄮У拇鎯?chǔ)系統(tǒng)不容易同步，易于出現(xiàn)不一致的情況，外鍵也會(huì)發(fā)生意外的改變。你需要一個(gè)后臺(tái)運(yùn)行的主數(shù)據(jù)管理的工具來(lái)發(fā)現(xiàn)和修復(fù)不一致的情況。比如，你需要檢查每個(gè)存儲(chǔ)訂閱者ID的數(shù)據(jù)庫(kù)來(lái)確保所有的ID都是同一個(gè)。這個(gè)工具可以自己寫(xiě)或者直接買。很多商用的關(guān)系型數(shù)據(jù)庫(kù)都提供此類核對(duì)，它常常過(guò)于耦合，不能支持很好的伸縮性。

使用類似程度的成熟度來(lái)維護(hù)代碼

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

詳細(xì)文檔請(qǐng)關(guān)注我們微信號(hào)，回復(fù)“Netflix”，獲取下載地址

6.Yelp

在你開(kāi)始考慮設(shè)計(jì)服務(wù)之初，也就是動(dòng)手寫(xiě)代碼和設(shè)計(jì)之前，和團(tuán)隊(duì)成員、其他服務(wù)領(lǐng)域的專家聊一聊。除了如何與現(xiàn)有的特性、產(chǎn)品以及服務(wù)如何適配之外，考慮一下你想要額外添加的功能?？紤]一種最合理的組織整體功能的方式。有時(shí)候添加新功能意味著要對(duì)現(xiàn)有組件進(jìn)行重組。

我們希望避免那些簡(jiǎn)單的 “append-only”服務(wù)架構(gòu)，也就是說(shuō)development只存在于新的服務(wù)中

核實(shí)是否能夠給現(xiàn)有服務(wù)添加新的功能

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

考慮你的功能是否更適合作為一個(gè)庫(kù)

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

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

性能和可靠性 庫(kù)與調(diào)用請(qǐng)求的尋址空間一樣，而服務(wù)則處于不同的網(wǎng)絡(luò)地址。假使其他東西都是一樣的，訪問(wèn)一個(gè)庫(kù) 要比服務(wù)更快更可靠。但是，如果功能對(duì)資源需求較高，比如CPU,內(nèi)存和硬盤(pán)，那么作為一個(gè)服務(wù)能夠讓客戶端的運(yùn)行效率更高，能夠使得服務(wù)所依賴的硬件獨(dú)立于客戶端的硬件而水平擴(kuò)展。

詳細(xì)文檔請(qǐng)關(guān)注我們微信號(hào)，回復(fù)“Yelp”，獲取下載地址

7.ThoughtWorks

隨著公司國(guó)際化戰(zhàn)略的推行以及本土業(yè)務(wù)的高速發(fā)展，后臺(tái)支撐系統(tǒng)已經(jīng)不堪重負(fù)。在吞吐量、穩(wěn)定性以及可擴(kuò)展性上都無(wú)法滿足日益增長(zhǎng)的業(yè)務(wù)需求。對(duì)于每10萬(wàn)元額度的合同，從銷售團(tuán)隊(duì)準(zhǔn)備材料、與客戶簽單、遞交給合同部門(mén)，再到合同生效大概需要3.5人天。隨著業(yè)務(wù)量的快速增長(zhǎng)，簽訂合同的成本急劇增加。

合同管理系統(tǒng)是后臺(tái)支撐系統(tǒng)中重要的一部分。當(dāng)前的合同系統(tǒng)是5年前使用.NET基于SAGE CRM二次開(kāi)發(fā)的產(chǎn)品。 一方面，系統(tǒng)架構(gòu)過(guò)于陳舊，性能、可靠性無(wú)法滿足現(xiàn)有的需求。另一方面，功能繁雜，結(jié)構(gòu)混亂，定制的代碼與SAGE CRM系統(tǒng)耦合度極高。由于是遺留系統(tǒng)，熟悉該代碼的人早已離職多時(shí)，新團(tuán)隊(duì)對(duì)其望而卻步，只能做些周邊的修補(bǔ)工作。同時(shí)，還要承擔(dān)著邊補(bǔ)測(cè)試，邊整理邏輯的工作。

在無(wú)法中斷業(yè)務(wù)處理的情況下，為了解決當(dāng)前面臨的問(wèn)題，團(tuán)隊(duì)制定了如下的策略：

1). 在現(xiàn)有合同管理系統(tǒng)的外圍，構(gòu)建功能服務(wù)接口，將系統(tǒng)核心的功能分離出來(lái)。
2). 利用這些功能服務(wù)接口作為代理，解耦原合同系統(tǒng)與其調(diào)用者之間的依賴；
3). 通過(guò)不斷構(gòu)建功能服務(wù)接口，逐漸將原有系統(tǒng)分解成多個(gè)獨(dú)立的服務(wù)。
4). 摒棄原有的合同管理系統(tǒng)，使用全新構(gòu)建的(微)服務(wù)接口替代。

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

Stencil模板

Stencil模板是一個(gè)獨(dú)立的Ruby代碼工程庫(kù)，主要包括代碼模板以及一組配置文件模板。

代碼模板使用Webmachine作為Web框架，RESTful和JSON構(gòu)建服務(wù)之間的通信方式，RSpec作為測(cè)試框架。同時(shí)，代碼模板還定義了一組Rake任務(wù)，譬如運(yùn)行測(cè)試，查看測(cè)試報(bào)告，將當(dāng)前的微服務(wù)生成RPM包，使用Koji給RPM包打標(biāo)簽等。

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

詳細(xì)文檔請(qǐng)關(guān)注我們微信號(hào)，回復(fù)“ThoughtWorks”，獲取下載地址

京東

京東資深架構(gòu)師李鑫主要負(fù)責(zé)京東的服務(wù)框架， 他所分享的內(nèi)容是對(duì)微服務(wù)底層的技術(shù)框架支持。

為何要微服務(wù)化？

1.系統(tǒng)規(guī)模隨著業(yè)務(wù)的發(fā)展?而增長(zhǎng)，原有系統(tǒng)架構(gòu)模式中邏輯過(guò)于耦合，不再適應(yīng)；
2.拆分后的?系統(tǒng)邏輯內(nèi)聚，易于局部擴(kuò)展；
3.?系統(tǒng)之間通過(guò)接?口來(lái)進(jìn)?交互，接?契約不變的情況下可獨(dú)?變化。

上圖中，左邊是幾年前京東的架構(gòu)，很多服務(wù)都是訪問(wèn)同樣一個(gè)DB。這種架構(gòu)的問(wèn)題在于：流量來(lái)了以后全部壓力都在DB上。而且在之前京東的架構(gòu)里比較強(qiáng)調(diào)快速開(kāi)發(fā)，很多邏輯比如說(shuō)倉(cāng)儲(chǔ)配送服務(wù)都不存在，全都依靠BD來(lái)進(jìn)行。這樣可擴(kuò)展性相當(dāng)差，性能也不太可控。后來(lái)，我們根據(jù)業(yè)務(wù)模塊和特性進(jìn)行水平拆分，應(yīng)用和應(yīng)用之間都要通過(guò)接口進(jìn)行交互，有同步和異步接口。

團(tuán)隊(duì)在2014年推出了新服務(wù)平臺(tái)JSF，其框架示意圖如下。

可以看出，服務(wù)注冊(cè)和尋址沒(méi)有太大變化，主要變化在于注冊(cè)中心。采用團(tuán)隊(duì)自己寫(xiě)的服務(wù)，并提供了index服務(wù)數(shù)據(jù)庫(kù)。相對(duì)來(lái)講，詢問(wèn)注冊(cè)中心地址，會(huì)進(jìn)行一個(gè)服務(wù)的調(diào)用。因?yàn)檫@一塊有自己內(nèi)部的邏輯，沒(méi)有辦法實(shí)現(xiàn)，所以定期會(huì)發(fā)送性能統(tǒng)計(jì)數(shù)據(jù)。把RPC轉(zhuǎn)化，生成負(fù)載均衡管理重試策略，然后經(jīng)過(guò)序列化以后發(fā)送到server并解碼，再進(jìn)行實(shí)際的業(yè)務(wù)調(diào)用，然后進(jìn)行一些過(guò)濾的邏輯。

詳細(xì)文檔請(qǐng)關(guān)注我們微信號(hào)，回復(fù)“京東”，獲取下載地址

七牛

肖勤介紹重點(diǎn)介紹了七牛圖片處理（FOP）場(chǎng)景的微服務(wù)應(yīng)用。FOP服務(wù)早期的架構(gòu)以它的每一個(gè)應(yīng)用為后端。隨著用戶越來(lái)越多，流量越來(lái)越高，負(fù)載均衡逐漸出現(xiàn)了帶寬和流量的壓力。

七牛將圖像處理服務(wù)拆成兩個(gè)部分，分別負(fù)責(zé)處理文件的傳輸和圖像本身的處理。從負(fù)載均衡過(guò)來(lái)的請(qǐng)求不再是完整的文件，而是文件的地址。這樣，負(fù)載均衡和流量?jī)?yōu)化跟整個(gè)圖像處理沒(méi)有關(guān)系，可以做多帶帶的部署。而對(duì)于稍微復(fù)雜一些的請(qǐng)求（如圖片格式和尺寸的變更，添加水?。陀霉艿赖姆绞桨巡煌姆?wù)串聯(lián)起來(lái)最終實(shí)現(xiàn)。

詳細(xì)文檔請(qǐng)關(guān)注我們微信號(hào)，回復(fù)“七牛”，獲取下載地址

10 好雨云

微服務(wù)架構(gòu)是好雨云基礎(chǔ)組件，好雨云的很多功能都跑在它上，好雨微服務(wù)架構(gòu)的第一個(gè)用戶就是好雨云自身，在這個(gè)過(guò)程中我們也體會(huì)到微服務(wù)架構(gòu)給我們帶來(lái)的便捷。

好雨云的微服務(wù)包括：

控制臺(tái)服務(wù) —— python 實(shí)現(xiàn)
實(shí)時(shí)消息服務(wù) —— java 實(shí)現(xiàn)
計(jì)費(fèi)服務(wù) —— python實(shí)現(xiàn)
統(tǒng)計(jì)服務(wù) —— java實(shí)現(xiàn)
日志服務(wù) —— c 實(shí)現(xiàn)
redis服務(wù) —— dockerfile 構(gòu)建
mysql服務(wù) —— dockerfile構(gòu)建

我們技術(shù)團(tuán)隊(duì)每個(gè)人擅長(zhǎng)的開(kāi)發(fā)語(yǔ)言不同，在微服務(wù)中也有體現(xiàn)，喜歡python的開(kāi)發(fā)者用python開(kāi)發(fā)微服務(wù)，喜歡java的開(kāi)發(fā)者用java開(kāi)發(fā)，適合用c的微服務(wù)用c開(kāi)發(fā)，開(kāi)源的服務(wù)直接用dockerfile構(gòu)建。新來(lái)的開(kāi)發(fā)人員不需要學(xué)習(xí)就可以開(kāi)始開(kāi)發(fā)。

好雨云微服務(wù)的開(kāi)發(fā)過(guò)程全部在云平臺(tái)上進(jìn)行，本地沒(méi)有設(shè)置開(kāi)發(fā)和測(cè)試環(huán)境，我們?yōu)槊恳粋€(gè)微服務(wù)建立兩個(gè)應(yīng)用，一套是開(kāi)發(fā)測(cè)試應(yīng)用，另一套是生產(chǎn)應(yīng)用，開(kāi)發(fā)測(cè)試應(yīng)用關(guān)聯(lián)開(kāi)發(fā)代碼分支，依賴測(cè)試數(shù)據(jù)服務(wù)，生產(chǎn)應(yīng)用關(guān)聯(lián)代碼主干，依賴生產(chǎn)數(shù)據(jù)服務(wù)，開(kāi)發(fā)人員日常開(kāi)發(fā)調(diào)試在開(kāi)發(fā)測(cè)試應(yīng)用進(jìn)行，代碼提交開(kāi)發(fā)分支，點(diǎn)擊部署，馬上就能看見(jiàn)應(yīng)用的效果，測(cè)試通過(guò)的應(yīng)用，將代碼合并到主干，點(diǎn)擊生產(chǎn)應(yīng)用的部署，完成上線過(guò)程，如果代碼有重大bug，點(diǎn)擊日志中的“代碼回滾”就能迅速回滾到上一個(gè)代碼版本。

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

控制臺(tái)服務(wù)是用戶使用量比較大的服務(wù)，為了優(yōu)化性能，我們重度依賴應(yīng)用實(shí)時(shí)性能分析，它可以分析出對(duì)性能影響最大的SQL和URL，優(yōu)化完SQL和對(duì)應(yīng)的程序，上線后立馬就能看見(jiàn)效果。并根據(jù)效果繼續(xù)優(yōu)化。對(duì)服務(wù)的伸縮，我們依賴于實(shí)時(shí)業(yè)務(wù)監(jiān)控，通過(guò)監(jiān)測(cè)總體響應(yīng)時(shí)間和吞吐率決定服務(wù)是擴(kuò)容還是縮容。

通過(guò)好雨微服務(wù)架構(gòu)來(lái)開(kāi)發(fā)好雨云的特性， 我們踐行了“吃自己的狗糧”，并持續(xù)優(yōu)化著好雨微服務(wù)架構(gòu)，做為第一個(gè)微服務(wù)架構(gòu)的用戶我們也從中受益，我們?cè)诃h(huán)境問(wèn)題、系統(tǒng)管理、性能優(yōu)化、服務(wù)伸縮和代碼發(fā)布上線上幾乎沒(méi)有浪費(fèi)時(shí)間，讓我們更加專注產(chǎn)品本身，快速迭代。

詳細(xì)文檔請(qǐng)關(guān)注我們微信號(hào)，回復(fù)“好雨云”，獲取下載地址

更多精彩內(nèi)容請(qǐng)掃描下方二維碼輕松獲取。