微服務(wù)(Microservices)

1、精品好資料學(xué)習(xí)推薦微服務(wù)(Microservices) 說在前面 好久沒寫博文了，心里癢癢（也許是換工作后，有點時間了吧）。最近好像談?wù)撐⒎?wù)的人比較多，也開始學(xué)習(xí)一下，但是都有E文，看起來半懂不懂的。 Martinfowler的微服務(wù)，也算是入門必讀了。有人翻譯過，但是只有一半。還是自己練練手吧。微服務(wù) “微服務(wù)架構(gòu)”一詞在過去幾年里廣泛的傳播，它用于描述一種獨立部署的軟件應(yīng)用設(shè)計方式。這種架構(gòu)方式并沒有非常準確的定義，但是在業(yè)務(wù)能力、自動部署、端對端的整合、對語言及數(shù)據(jù)的分散控制上，卻有著顯著特征。 “微服務(wù)”-只不過在滿大街充斥的軟件架構(gòu)中的一新名詞而已。盡管我們非常鄙視這樣的東西，但是

2、這玩意所描述的軟件風格，越來越引起我們的注意。在過去幾年里，我們發(fā)現(xiàn)越來越多的項目開始使用這種風格，以至于我們身邊的同事在構(gòu)建企業(yè)應(yīng)用時，把它理所當然的認為這是一種默認開發(fā)形式。然而，很不幸，微服務(wù)風格是什么，應(yīng)該怎么開發(fā)，關(guān)于這樣的理論描述卻很難找到。 簡而言之，微服務(wù)架構(gòu)風格，就像是把小的服務(wù)開發(fā)成單一應(yīng)用的形式，每個應(yīng)用運行在單一的進程中，并使用如HTTP這樣子的輕量級的API。這些服務(wù)滿足某需求，并使用自動化部署工具進行獨立發(fā)布。這些服務(wù)可以使用不同的開發(fā)語言以及不同數(shù)據(jù)存儲技術(shù)，并保持最低限制的集中式管理。 開始介微服務(wù)風格前，先介紹整體風格：即把一個完整的應(yīng)用當成一開發(fā)單元。企業(yè)應(yīng)

3、用通常包含三個部分：客戶端界面（由HTML、Javascript組成，使用瀏覽器進行訪問）、數(shù)據(jù)庫（由許多的表組件構(gòu)成一個通用的、相互關(guān)聯(lián)的數(shù)據(jù)管理系統(tǒng)）、服務(wù)端應(yīng)用。服務(wù)端應(yīng)用處理HTTP請求、執(zhí)行領(lǐng)域邏輯、檢索并更新數(shù)據(jù)庫中的數(shù)據(jù)、使用適當?shù)腍TML視圖發(fā)送給客戶端。服務(wù)端應(yīng)用是完整的 - 由單一的邏輯層次執(zhí)行。系統(tǒng)中任務(wù)變更都會導(dǎo)到服務(wù)端的應(yīng)用重新編輯并發(fā)布一個新的版本。 這樣的整體服務(wù)是這樣的構(gòu)建系統(tǒng)的很自然的方式。雖然利用開發(fā)語基礎(chǔ)特性會把應(yīng)用封裝成類、函數(shù)、命名空間，但是業(yè)務(wù)中所有邏輯都要在單一的進程中處理完成。在某些場景中，開發(fā)者可能在的筆計本中開發(fā)、測試應(yīng)用，然后利用部署通道來

4、保證經(jīng)過正常測試、發(fā)布的修改內(nèi)容正確的發(fā)布的產(chǎn)品中。也可以使用橫向擴展，通過負載均橫系統(tǒng)將事個應(yīng)用部署到多臺服務(wù)器上。 整體風格的應(yīng)用也是相當成功的，但是越來越多的人感覺到有點不妥，特別是在云中進行應(yīng)用的發(fā)布時。變更發(fā)布周期被綁定了 - 原來可以劃分成小的應(yīng)用、小的需要的變更，需要統(tǒng)一的進行編譯和發(fā)布。隨著時間的推移，人們通常難于維護一種優(yōu)美的模塊化的結(jié)構(gòu)，使得一個模塊的變更很難不會影響到其它的模塊。進行擴展，也需要進行整體的擴展，而不能根據(jù)進行部分的擴展。圖1：整理架構(gòu)與微服務(wù)架構(gòu) 這些原因?qū)е铝宋⒎?wù)架構(gòu)風格的出現(xiàn)：以服務(wù)構(gòu)建應(yīng)用。因為服務(wù)可以獨立部署、獨立擴展，服務(wù)也可以提供模塊化的邊界

5、，并且不同的使用也可以使用不同的開發(fā)語言。服還可以以不同的周期進行管理。 微服務(wù)風格關(guān)不是我們發(fā)明的，也不是一個新的東西，它至少起源于Unix時代的設(shè)計原則。之所以這樣，我們認為只是當時很少人考慮過這種風格，并認識到把軟件使用這種的風格可以帶來更多的好處。微服務(wù)風格的特性 我們沒有辦法對微服務(wù)風格進行準確的定義，但是我們可以償試著描述一下微服務(wù)風格所應(yīng)該具有的覺特性，這樣就可以對它打上相應(yīng)的標簽了。正如其它定義中對特性的描述一新，并不是所有的微服務(wù)風格都要所有的特性，但是我們認為常見的微服務(wù)都應(yīng)該有這些特性。盡管我們是相當松散的社區(qū)核心成員，但是我們也計劃償試描述我們工作中或者在其它我們了解的

6、組件中所理解的微服務(wù)。當然，我們并不依賴于那些已經(jīng)明確過的定義。組件與服務(wù) 自從我們從事軟件行業(yè)以來，一直希望能夠構(gòu)建由組件組成的系統(tǒng)，就像我們所看到的實現(xiàn)世界由物件構(gòu)成的一樣。在過去的幾十年里，我們已經(jīng)看到了大部分語言平臺的公共庫的進行了精簡，并取得可觀的進展。 當我們談?wù)摻M件的時候，有可能會因為組件的不同定義引起混亂。因此我們申明，這里談到的組件是指軟件中獨立的單元，它能獨立替代和獨立更新。 微服務(wù)架構(gòu)也使用組件庫，但是它把軟件拆分成服務(wù)，并認為這是主要的組織形式。我們把組件庫定義為程序中相互關(guān)系、并使用內(nèi)存中調(diào)用的組件，把服務(wù)定義為進程間使用如Web請求服務(wù)或者遠程調(diào)用來相互通信的組件。

7、（這種定義的方式與其它面向?qū)ο蟪绦蛑蟹?wù)對象的概念是不一樣的。） 把服務(wù)當成組件（而不是組件庫）一個主要的原因是服務(wù)可以獨立的部署。如果你的應(yīng)用由多個組件庫組成并跑在一個進程中，那么任何組件的變更都將導(dǎo)致整體應(yīng)用的重新發(fā)布。但是如果由許多服務(wù)構(gòu)成的應(yīng)用，你可以想像的到每個服務(wù)的變更僅需要發(fā)布相應(yīng)的服務(wù)。當然，這也不是絕對的，比如導(dǎo)致服務(wù)接口的變更的更新就需要相應(yīng)服務(wù)的變化，但優(yōu)秀微服務(wù)構(gòu)架，會盡量避免這種服務(wù)間的耦合并完善服務(wù)的交互接口。 把服務(wù)當成組件的另一個考慮是這將擁有更新清晰的接口。許多開發(fā)語言并沒有良好的定義公共接口的機制。通常只有文檔和規(guī)范說明，讓用戶避免組件間會導(dǎo)致組件耦合的過度

8、的依賴。不過服務(wù)由是是通過明確的遠程接口調(diào)用，這個問題就很容易解決了。 使用服務(wù)也有它的不足之處。遠程調(diào)用比進制內(nèi)部調(diào)用更消耗性能，而且遠程的API比較粗糙，難以使用。如果由于對組件的職責進行變更，影響到跨進程間的交互，那么這操作起來也比較困難。 第一個可能的特性，我們看到每個服務(wù)是運行在獨立的進程上的。注意，這只是第一個可能的特性。服務(wù)也可以由多個進程組成，它們是同時開發(fā)和部署的，例如服務(wù)可能用到一個應(yīng)用進制和一種數(shù)據(jù)稟。圍繞業(yè)務(wù)功能進行組織 當尋找把一個大的應(yīng)用拆分成小的部分時，主管通常注意在技術(shù)層面，拆分成UI組、服務(wù)邏輯組和數(shù)據(jù)庫組。當使用這種標準對團隊進行劃分時，甚至小小的更變都將導(dǎo)

9、致跨團隊間項目協(xié)作，從而消耗時間和預(yù)算審批。一個高效的團隊會針對這種情況進行改善，關(guān)注它們所涉及的應(yīng)用邏輯，并從中做出較好的選擇。換句話說，邏輯無處不在。Conways Law的實踐就是一個例子。 plain view plain copy 任何組織設(shè)計一個系統(tǒng)（廣義上的系統(tǒng)）都會產(chǎn)生一種設(shè)計，其結(jié)構(gòu)為其組織通信結(jié)構(gòu)的復(fù)本。 - Melvyn Conway, 1967 圖2：Conways Law的實踐 微服務(wù)更傾向于圍繞業(yè)務(wù)功能對服務(wù)結(jié)構(gòu)進行劃分、拆解。這樣的服務(wù)，是針對業(yè)務(wù)領(lǐng)域有著關(guān)完整實現(xiàn)的軟件，它包含使用接口、持久存儲、以及對旬的交互。因此團隊應(yīng)該是跨職能的，包含完整的開發(fā)技術(shù)：用戶體

10、驗、數(shù)據(jù)庫、以及項目管理。圖3：通過團隊邊界強調(diào)服務(wù)邊界 就采用這種組織形式。不同職能的團隊同時為各自的產(chǎn)品構(gòu)建和運營負責，同時每個產(chǎn)品又拆分成多個通過消息引擎通信的單獨服務(wù)。 大型的整體型應(yīng)用也可以按照業(yè)務(wù)功能進行模塊化的，盡管這種例子不常見。當然，我們敦促一個大型的團隊將一個構(gòu)建成整體型的應(yīng)用依照業(yè)務(wù)功能進行拆分。我們能看到主要問題在于，這種組件形式會導(dǎo)致很多的上下文依賴。如果在大量的模塊邊界上都存在這種大量的調(diào)用，對于團隊的每個成員來說，短期內(nèi)是很難記住的。此外，我們發(fā)現(xiàn)模塊化方式需要大量的規(guī)范去強制執(zhí)行，當然，大量明確的拆分也讓服務(wù)組件在

11、團隊的邊界中更加清晰。產(chǎn)品不是項目 大部分的軟件開發(fā)者都使用這樣的開發(fā)模式：至力于提供一些被認為是完整的軟件。一旦開發(fā)完成，軟件將移交給維護部門，然后，開發(fā)組就可以解散掉了。 微服務(wù)的支持者認為，這種做法是不可取的，并提議開發(fā)組應(yīng)該負責產(chǎn)品的整個生命周期。一個常見的證明是：Amazon的“你編譯，你運維（you build, you run it）”的理念，它要求開發(fā)團隊對軟件產(chǎn)品的整個生命周期負責。這要求開發(fā)者每天都關(guān)注軟件產(chǎn)品的運行情況，并與用戶聯(lián)系的更緊密，同時承擔一些售后支持。 成熟的產(chǎn)品會與業(yè)務(wù)功能進行綁定。除了把軟件看成既定功能的集合外，會進一步關(guān)心“軟件如何幫助用戶實現(xiàn)業(yè)務(wù)功能”

12、這樣的問題。 采用整體型的架構(gòu)并不是沒有原因的，但是越小的服務(wù)粒度越容易促進用戶與服務(wù)提供商之前的關(guān)系。強化終端及弱化通道 當構(gòu)建不同的進程間通信機制的時候，我們發(fā)現(xiàn)有許多的產(chǎn)品和方法能夠把更加有效方法強加入的通信機制中。比如企業(yè)服務(wù)總線（ESB），這樣的產(chǎn)品提供更有效的方式改進通信過程中的路由、編碼、傳輸、以及業(yè)務(wù)處理規(guī)則。 微服務(wù)傾向于做如下的選擇：強化終端及弱化通道。微服務(wù)的應(yīng)用致力松耦合和高內(nèi)聚：采用單獨的業(yè)務(wù)邏輯，表現(xiàn)的更像經(jīng)典Unix意義上的過濾器一樣，接受請求、處理業(yè)務(wù)邏輯、返回響應(yīng)。它們更喜歡簡單的REST風格，而不是復(fù)雜的協(xié)議，如WS或者BPEL或者集中式框架。 有兩種協(xié)議最

13、經(jīng)常被使用到：包含資源API的HTTP的請求-響應(yīng)和輕量級消息通信協(xié)議。最為重要的建議為：plain view plain copy Be of the web, not behind the web(善于利用網(wǎng)絡(luò)，而不是限制使用網(wǎng)絡(luò)。) - Ian Robinson 微服務(wù)團隊采用這樣的原則和規(guī)范：基于互聯(lián)網(wǎng)（廣義上，包含Unix系統(tǒng)）構(gòu)建系統(tǒng)。這樣經(jīng)常使用的資源幾乎不用什么的代價就可以被開發(fā)者或者運行商緩存。 第二種做法是通過輕量級消息總線來發(fā)布消息。這種的通信協(xié)議非常的單一（單一到只負責消息路由），像RabbitMQ或者ZeroMQ這樣的簡單的實現(xiàn)甚至像可靠的異步機制都沒提供，以至于需要

14、依賴產(chǎn)生或者消費消息的終端或者服務(wù)來處理這類問題。 在整體工風格中，組件在進程內(nèi)執(zhí)行，進程間的消息通信通常通過調(diào)用方法或者回調(diào)函數(shù)。從整體式風格到微服務(wù)框架最大的問題在于通信方式的變更。從內(nèi)存內(nèi)部原始的調(diào)用變成遠程調(diào)用，產(chǎn)生的大量的不可靠通信。因此，你需要把粗粒度的方法成更加細粒度的通信。分散治理 集中治理的一種好處是在單一平臺上進行標準化。經(jīng)驗表明這種趨勢的好處在縮小，因為并不是所有的問題都相同，而且解決方案并不是萬能的。我們更加傾向于采用適當?shù)墓ぞ呓鉀Q適當?shù)膯栴}，整體式的應(yīng)用在一定程度上比多語言環(huán)境更有優(yōu)勢，但也適合所有的情況。 把整體式框架中的組件，拆分成不同的服務(wù)，我們在構(gòu)建它們時有更

15、多的選擇。你想用Node.js去開發(fā)報表頁面嗎？做吧。用C+來構(gòu)建時時性要求高的組件？很好。你想以在不同類型的數(shù)據(jù)庫中切換，來提高組件的讀取性能？我們現(xiàn)在有技術(shù)手段來實現(xiàn)它了。 當然，你是可以做更多的選擇，但也不意味的你就可以這樣做，因為你的系統(tǒng)使用這種方式進行侵害意味著你已經(jīng)有的決定。 采用微服務(wù)的團隊更喜歡不同的標準。他們不會把這些標準寫在紙上，而是喜歡這樣的思想：開發(fā)有用的工具來解決開發(fā)者遇到的相似的問題。這些工具通常從實現(xiàn)中成長起來，并進行的廣泛范圍內(nèi)分享，當然，它們有時，并不一定，會采用開源模式?，F(xiàn)在開源的做法也變得越來越普遍，git或者github成為了它們事實上的版本控制系統(tǒng)。

16、Netfix就是這樣的一個組織，它是非常好的一個例子。分享有用的、尤其是經(jīng)過實踐的代碼庫激勵著其它的開發(fā)著也使用相似的方式來解決相似的問題，當然，也保留著根據(jù)需要使用不同的方法的權(quán)力。共享庫更關(guān)注于數(shù)據(jù)存儲、進程內(nèi)通信以及我們接下來做討論到的自動化等這些問題上。 微服務(wù)社區(qū)中，開銷問題特別引人注意。這并不是說，社區(qū)不認為服務(wù)交互的價值。相反，正是因為發(fā)現(xiàn)到它的價值。這使得他們在尋找各種方法來解決它們。如Tolearant Reader和Consumer-DrivenContracts這樣的設(shè)計模式就經(jīng)常被微服務(wù)使用。這些模式解決了獨立服務(wù)在交互過程中的消耗問題。使用Consumer-Drive

17、n Contracts增加了你的信心，并實現(xiàn)了快速的反饋機制。事實上，我們知道澳大利亞的一個團隊致力使用Consumer-Drvien Contracts開發(fā)新的服務(wù)。他們使用簡單的工程，幫助他們定義服務(wù)的接口。使得在新服務(wù)的代碼開始編寫之前，這些接口就成為自動化構(gòu)建的一個部分。構(gòu)建出來的服務(wù)，只需要指出這些接口適用的范圍，一個優(yōu)雅的方法避免了新軟件中的YAGNI 困境。這些技術(shù)和工具在使用過程中完善，通過減少服務(wù)間的耦合，限制了集中式管理的需求。 也許分散治理普及于亞馬遜“編譯它，運維它”的理念。團隊為他們開發(fā)的軟件負全部責任，也包含7*24小時的運行。全責任的方式并不常見，但是我們確實發(fā)現(xiàn)

18、越來越多的公司在他們的團隊中所推廣。Netfix是另外一個接受這種理念的組件。每天凌晨3點被鬧鐘吵醒，因為你非常的關(guān)注寫的代碼質(zhì)量。這在傳統(tǒng)的集中式治理中這是一樣多么不思議的事情呀。分散數(shù)據(jù)管理 對數(shù)據(jù)的分散管理有多種不同的表現(xiàn)形式。最為抽象層次，它意味著不同系統(tǒng)中的通用概念是不同的。這帶來的覺問題是大型的跨系統(tǒng)整合時，用戶使用不同的售后支持將得到不同的促銷信息。這種情況叫做并沒有給用戶顯示所有的促銷手段。不同的語法確實存在相同的詞義或者（更差）相同的詞義。 應(yīng)用之間這個問題很普遍，但應(yīng)用內(nèi)部這個問題也存在，特別是當應(yīng)用拆分成不同的組件時。對待這個問題非常有用的方式為Bounded Conte

19、xt的領(lǐng)域驅(qū)動設(shè)計。DDD把復(fù)雜的領(lǐng)域拆分成不同上下文邊界以及它們之間的關(guān)系。這樣的過程對于整體架構(gòu)和微服務(wù)框架都很有用，但是服務(wù)間存在著明顯的關(guān)系，幫助我們對上下文邊界進行區(qū)分，同時也像我們在業(yè)務(wù)功能中談到的，強行拆分。 當對概念模式下決心進行分散管理時，微服務(wù)也決定著分散數(shù)據(jù)管理。當整體式的應(yīng)用使用單一邏輯數(shù)據(jù)庫對數(shù)據(jù)持久化時，企業(yè)通常選擇在應(yīng)用的范圍內(nèi)使用一個數(shù)據(jù)庫，這些決定也受廠商的商業(yè)權(quán)限模式驅(qū)動。微服務(wù)讓每個服務(wù)管理自己的數(shù)據(jù)庫：無論是相同數(shù)據(jù)庫的不同實例，或者是不同的數(shù)據(jù)庫系統(tǒng)。這種方法叫PolyglotPersistence。你可以把這種方法用在整體架構(gòu)中，但是它更常見于微服務(wù)

20、架構(gòu)中。圖4：Polyglot Persistence 微服務(wù)音分散數(shù)據(jù)現(xiàn)任意味著管理數(shù)據(jù)更新。處理數(shù)據(jù)更新的常用方法是使用事務(wù)來保證不同的資源修改數(shù)據(jù)庫的一致性。這種方法通常在整體架構(gòu)中使用。 使用事務(wù)是因為它能夠幫助處理一至性問題，但對時間的消耗是嚴重的，這給跨服務(wù)操作帶來難題。分布式事務(wù)非常難以實施，因此微服務(wù)架構(gòu)強調(diào)服務(wù)間事務(wù)的協(xié)調(diào)，并清楚的認識一致性只能是最終一致性以及通過補償運算處理問題。 選擇處理不一致問題對于開發(fā)團隊來說是新的挑戰(zhàn)，但是也是一個常見的業(yè)務(wù)實踐模式。通常業(yè)務(wù)上允許一定的不一致以滿足快速響應(yīng)的需求，但同時也采用一些恢復(fù)的進程來處理這種錯誤。當業(yè)務(wù)上處理強一致性消耗比

21、處理錯誤的消耗少時，這種付出是值的的?；A(chǔ)設(shè)施自動化 基礎(chǔ)設(shè)施自動化技術(shù)在過去幾年中得到了長足的發(fā)展：云計算，特別是AWS的發(fā)展，減少了構(gòu)建、發(fā)布、運維微服務(wù)的復(fù)雜性。 許多使用微服務(wù)架構(gòu)的產(chǎn)品或者系統(tǒng)，它們的團隊擁有豐富的持集部署以及它的前任持續(xù)集成的經(jīng)驗。團隊使用這種方式構(gòu)建軟件致使更廣泛的依賴基礎(chǔ)設(shè)施自動化技術(shù)。下圖說明這種構(gòu)建的流程：圖5：基本的構(gòu)建流程 盡管這不是介紹自動部署的文章，但我們也打算介紹一下它的主要特征。我們希望我們的軟件應(yīng)該這樣方便的工作，因此我們需要更多的自動化測試。流程中工作的軟件改進意味著我們能自動的部署到各種新的環(huán)境中。 整體風格的應(yīng)用相當開心的在各種環(huán)境中構(gòu)建

22、、測試、發(fā)布。事實證明，一旦你打算投資一條整體架構(gòu)應(yīng)用自動化的的生產(chǎn)線，那么你會發(fā)現(xiàn)發(fā)布更多的應(yīng)用似乎非不那么的可怕。記住，CD（持續(xù)部署）的一個目標在于讓發(fā)布變得無趣，因此無論是一個還是三個應(yīng)用，它都一樣的無趣。 另一個方面，我們發(fā)現(xiàn)使用微服務(wù)的團隊更加依賴于基礎(chǔ)設(shè)施的自動化。相比之下，在整體架構(gòu)也微服務(wù)架構(gòu)中，盡管發(fā)布的場景不同，但發(fā)布工作的無趣并沒有多大的區(qū)別。圖6：模塊化部署的區(qū)別容錯性設(shè)計 使用服務(wù)作為組件的一個結(jié)果在于應(yīng)用需要有能容忍服務(wù)的故障的設(shè)計。任務(wù)服務(wù)可能因為供應(yīng)商的不可靠而故障，客戶端需要盡可能的優(yōu)化這種場景的響應(yīng)。跟整體構(gòu)架相比，這是一個缺點，因為它帶來的額外的復(fù)雜性。

23、這將讓微服務(wù)團隊時刻的想到服務(wù)故障的情況下用戶的體驗。Netflix的Simian Army可以為每個應(yīng)用的服務(wù)及數(shù)據(jù)中心提供日常故障檢測和恢復(fù)。 這種產(chǎn)品中的自動化測試可以讓大部分的運維團隊正常的上下班。這并不意味著整體構(gòu)架的應(yīng)用沒有這么精巧的監(jiān)控配置，只是在我們的經(jīng)驗中它并不常見。 由于服務(wù)可以隨時故障，快速故障檢測，乃至，自動恢復(fù)變更非常重要。微服務(wù)應(yīng)用把實時的監(jiān)控放在應(yīng)用的各個階段中，檢測構(gòu)架元素（每秒數(shù)據(jù)庫的接收的請求數(shù)）和業(yè)務(wù)相關(guān)的指標（把分鐘接收的定單數(shù)）。監(jiān)控系統(tǒng)可以提供一種早期故障告警系統(tǒng)，讓開發(fā)團隊跟進并調(diào)查。 對于微服務(wù)框架來說，這相當重要，因為微服務(wù)相互的通信可能導(dǎo)致緊

24、急意外行為。許多專家車稱贊這種緊急事件的價值，但事實是這種緊急行為有時是災(zāi)難。監(jiān)控是至關(guān)重要的，它能快速發(fā)現(xiàn)這種緊急不良行為，讓我們迅速修復(fù)它。 整體架構(gòu)，跟微服務(wù)一樣，在構(gòu)建時是通明的，實情上，它們就是這樣子的。它們不同之處在于，你需要清楚的認識到不同進程間運行的服務(wù)是不相關(guān)的。庫對于同一進程是透明的，也因此不那么重要了。 微服務(wù)團隊期望清楚的監(jiān)控和記錄每個服務(wù)的配置，比如使用儀表盤顯示上/下線狀態(tài)、各種運維和業(yè)務(wù)相關(guān)的指標。對斷路器（circuit breaker）狀態(tài)、目前的吞吐量和時延細節(jié)，我們也會經(jīng)常遇到。設(shè)計改進 微服務(wù)實踐者，通常有不斷改進設(shè)計的背景，他們把服務(wù)分解成進一步的工具

25、。這些工具可以讓應(yīng)用開發(fā)者在不改變速度情況下，控制都他們的應(yīng)用的需求變更。變更控制不意味首減少變更，而是使用適當?shù)姆绞胶凸ぞ?，讓它更加頻繁，至少，很好讓它變得可控。 不論如何，當你試圖軟件系統(tǒng)拆分成組件時，你將面臨著如何拆分的問題。那么我們的決定拆分我們應(yīng)用的原則是什么呢？首要的因素，組件可以被獨立替換和更新的，這意味著我們尋找的關(guān)鍵在于，我們要想象著重寫一個組件而不影響它們之前的協(xié)作關(guān)系。事實上，許多的微服務(wù)小組給它進一步的預(yù)期：服務(wù)應(yīng)該能夠報廢的，而不是要長久的發(fā)展的。 Guardian網(wǎng)站就是這方面的一個優(yōu)秀的例子，它初期被設(shè)計和構(gòu)建成一個整體架構(gòu)，但它已經(jīng)向微服務(wù)的發(fā)展了。整體構(gòu)架仍然

26、是它網(wǎng)站的核心，但是他們使用微服務(wù)來增加那些使用整體架構(gòu)API的新特性。這種方法增加這些臨時的特性非常方便，比如運動新聞的特稿。這樣站點的一個部分可以使用快速的開發(fā)語言迅速整合起來，當它過時后可以一次性移除。我們發(fā)現(xiàn)一家金融機構(gòu)用相似的方法增加新的市場營銷活動，數(shù)周或者幾個月后把它撤銷。 可代替是模塊化開發(fā)中的一個特例，它是用模塊來應(yīng)對需要變更的。你希望讓變更是相同模塊，相同周期中進行變化而已。系統(tǒng)的某些很小做變更部分，也應(yīng)該放在不同的服務(wù)中，這樣它們更容易讓它們消亡。如果你發(fā)現(xiàn)兩個服務(wù)一直重復(fù)的變更時，這就是一個要合并它們的信號了。 把組件改成服務(wù)，增加了細化發(fā)布計劃的一個機會。整體構(gòu)架的任

27、務(wù)變更需要整個應(yīng)用的完整的構(gòu)建和發(fā)布。然而，使用微服務(wù)，你只需要發(fā)布你要修改的服務(wù)就可以了。這將簡化和加速你的發(fā)布周期。缺點是你需要為一個變更服務(wù)發(fā)布可能中斷用戶的體驗而擔心。傳統(tǒng)的集成方法是使用版本來處理這些問題，但是微服務(wù)版本僅是最后的通告手段。我們需要在設(shè)計服務(wù)時盡可能的容忍供應(yīng)商的變更，以避免提供多個版本。其它微服務(wù)系統(tǒng)多大？ 盡管“微服務(wù)”一詞在架構(gòu)風格中越來越流行，它的名字很不辛讓人關(guān)注它的服務(wù)大小，以及對“微”這個組成的爭議。在我們與微服務(wù)實踐者的談話中，我們發(fā)現(xiàn)了服務(wù)的大小范圍。被報道的最大團隊遵循亞馬遜Tow Pizaa團隊理念（比如，一個團隊吃兩個比薩就可以了。），這意味著

28、不超過20號（一打）人。我們發(fā)現(xiàn)最小配置是半打的團隊支撐起一打的服務(wù)。 這也引發(fā)這樣的考慮：規(guī)模為一個服務(wù)一打人到一個服務(wù)一個人的團隊打上微服務(wù)的標簽。此刻我們認為，它們是一樣的，但是隨著對這種風格的深入研究，也存在我們改變我們的想法的可能。微服務(wù)與SOA 當前我們談到微服務(wù)時，通常會問，這是不是我們20年前討論的面向服務(wù)架構(gòu)（SOA）。這是一個很好的觀點，因為微服務(wù)風格也SOA所提倡的一些優(yōu)勢非常相似。盡管如此，問題在于SOA意味的太多不同的東西了，因此通常時候我們談的所謂“SOA”時，它與我們談?wù)摰娘L格不一至，因為它通常是指在整體風格應(yīng)用中的ESB。 此外，我們發(fā)現(xiàn)面向服務(wù)的風格是這么的拙

29、劣：從試圖使用ESB隱藏復(fù)雜性， 到使用多年才認識到發(fā)費數(shù)百美元卻沒產(chǎn)生任務(wù)價值這樣的失敗，到集中治理模式抑制變更。而且這些問題往往很難發(fā)現(xiàn)。 可以肯定的時，微服務(wù)社區(qū)中使用的許多的技術(shù)都開發(fā)者是從大型機構(gòu)的整合服務(wù)經(jīng)驗中發(fā)展來的。Tolerant Reader模式就是這樣的一個例子。由于互聯(lián)網(wǎng)的發(fā)展，利用簡單的協(xié)議這種方法，讓它從這些經(jīng)驗傳達的出來。這是從已經(jīng)很復(fù)雜的集中式標準中的一種反模式，坦白的說，真讓人驚嘆。（無論何時，當你需要用一個服務(wù)來管理你的所有的服務(wù)，你就知道這很麻煩。） SOA的這種常見行為讓微服務(wù)的提倡者拒絕打上SOA的標簽，盡管有人認為微服務(wù)是從SOA中發(fā)展而來的，或許面

30、向服務(wù)是對的。無論如何，事實上SOA表達這么多的含義，它給一個團隊清醒的認識到這種構(gòu)架風格就已經(jīng)值的了。多語言，多選擇 JVM做為一個平臺，它的增長就是一個平臺中運行多語言的最大的例子。過去二十年中，它通常做為更高層次語言的殼，以達到更高層次的抽象。比如，研究它的內(nèi)部結(jié)構(gòu)，、使用低級的語言寫更高效的代碼。盡管如此，許多整體風格并不需要這種層次的性能優(yōu)化或者在語法及高層次上的抽象，這很常見（讓我們很失望）。此外整體構(gòu)架通常意味著使用單一的語言，這也限制著使用技術(shù)的數(shù)量。實踐標準和強制標準 它有點尷尬，微服務(wù)團隊傾向于避免這種通常由企業(yè)架構(gòu)隊伍定制的僵硬的強制標準，但是它們卻非常樂于甚至推廣這些開

31、放的標準，如HTTP、ATOM、其它微規(guī)范。 關(guān)鍵的不同在這些標準是怎么開發(fā)出來的，以及它們是怎么被推廣的。標準被一些組件管理，如IETF認證標準，僅當它們在互聯(lián)網(wǎng)上有幾個在用的實現(xiàn)，通常源自于開源工程的成功應(yīng)用。 這些標準單獨分離出來，與那種在企業(yè)中通常有沒有什么編碼經(jīng)驗的或者沒有什么影響力的廠商標準進行區(qū)別。讓做對事更容易 一方面，我們發(fā)現(xiàn)在持續(xù)發(fā)布、部署越來越多的使用自動化，是很多有用的工具開發(fā)出來幫助開發(fā)者和運營商的努力結(jié)果。為打包、代碼管理、支撐服務(wù)的工具，或者增加標準監(jiān)控的記錄的工具，現(xiàn)在都非常常見了。網(wǎng)絡(luò)中最好的，可能就是Netflixs的開源工具，但是包含Dropwizard在

32、內(nèi)的其它工具也被廣泛的使用著。斷路器(circuit breaker)和產(chǎn)品中現(xiàn)有的代碼斷路器(circuit breaker)出現(xiàn)在Realease It!一書中，與Bulkhead和Timeout這樣的模式放在一起。實施起來，這些模式用于構(gòu)建通信應(yīng)用時相當?shù)闹匾?。Netflix的博客在解釋它們的應(yīng)用時，做了大量的工作。同步是有害的 任務(wù)時候，你在服務(wù)間的調(diào)用使用同步的方法，都會遇到宕機時間的乘積效應(yīng)。簡單的說，你的系統(tǒng)宕機時間是你系統(tǒng)的單獨組件的宕機時間的乘積。你面臨的選擇使用異步或者管理宕機時間。在www.guardian.co.uk中，它們在新平臺中使用一種簡單的規(guī)則來實現(xiàn)它：在Netflix中每次用戶請求的同步調(diào)用，他們重新設(shè)計的平臺API都會把它構(gòu)建成異步的API來執(zhí)行。微服務(wù)是未來嗎？ 我們寫這篇文章的主要目的在于解釋微服務(wù)的主要思想和原則。但是發(fā)時間做這事的時候，我們清醒的認識到微服務(wù)構(gòu)架風格是一個非常重要的想法：一個值得企業(yè)應(yīng)用中認真考慮的東西。我們最近使用這種風格構(gòu)建了幾個系統(tǒng)，認識那些也使用和喜歡這種方法的愛好者。 我們認識的使用這種方式的先行者，包含亞馬遜、Netflix、The Guardian、The UK Government Digital Service、.a