說在前面
很久沒寫博文了，內心癢癢（或許是換工做後，有點時間了吧）。
近期好像談論微服務的人比較多，也開始學習一下。但是都有E文。看起來半懂不懂的。html
Martinfowler的《
微服務》，也算是入門必讀了。有人
翻譯過，但是僅僅有一半。仍是本身練練手吧。
微服務
「微服務架構」一詞在過去幾年裏普遍的傳播，它用於描寫敘述一種獨立部署的軟件應用設計方式。這樣的架構方式並無很準確的定義。但是在業務能力、本身主動部署、端對端的整合、對語言及數據的分散控制上，卻有着顯著特徵。
「微服務」----僅僅只是在滿大街充斥的軟件架構中的一新名詞而已。雖然咱們很是歧視這種東西。但是這玩意所描寫敘述的軟件風格，愈來愈引發咱們的注意。在過去幾年裏，咱們發現愈來愈多的項目開始使用這種風格，以致於咱們身邊的同事在構建企業應用時，把它理所固然的以爲這是一種默認開發形式。
然而，很是不幸，微服務風格是什麼。應該怎麼開發，關於這種理論描寫敘述卻很是難找到。git
簡而言之。微服務架構風格，就像是把小的服務開發成單一應用的形式，每個應用執行在單一的進程中。並使用如HTTP這樣子的輕量級的API。這些服務知足某需求，並使用本身主動化部署工具進行獨立公佈。
這些服務可以使用不一樣的開發語言以及不一樣數據存儲技術，並保持最低限制的集中式管理。github
開始介微服務風格前，先介紹整體風格：即把一個完整的應用當成一開發單元。企業應用一般包括三個部分：client界面（由HTML、Javascript組成，使用瀏覽器進行訪問）、數據庫（由不少的表組件構成一個通用的、相互關聯的數據管理系統）、服務端應用。
服務端應用處理HTTP請求、運行領域邏輯、檢索並更新數據庫中的數據、使用適當的HTML視圖發送給client。服務端應用是完整的 ---- 由單一的邏輯層次運行。系統中任務變動都會導到服務端的應用又一次編輯並公佈一個新的版本號。web
這種整體服務是這種構建系統的很是天然的方式。
儘管利用開發語基礎特性會把應用封裝成類、函數、命名空間，但是業務中所有邏輯都要在單一的進程中處理完畢。數據庫
在某些場景中。開發人員可能在的筆計本中開發、測試應用。而後利用部署通道來保證通過正常測試、公佈的改動內容正確的公佈的產品中。也可以使用橫向擴展，經過負載均橫系統將事個應用部署到多臺server上。設計模式
整體風格的應用也是至關成功的。但是愈來愈多的人感受到有點不妥，特別是在雲中進行應用的公佈時。變動公佈週期被綁定了 ---- 原來可以劃分紅小的應用、小的需要的變動，需要統一的進行編譯和公佈。隨着時間的推移，人們一般難於維護一種優美的模塊化的結構，使得一個模塊的變動很是難不會影響到其餘的模塊。進行擴展，也需要進行整體的擴展。而不能依據進行部分的擴展。
圖1：整理架構與微服務架構
這些緣由致使了微服務架構風格的出現：以服務構建應用。
因爲服務可以獨立部署、獨立擴展。服務也可以提供模塊化的邊界，並且不一樣的使用也可以使用不一樣的開發語言。瀏覽器
服還可以以不一樣的週期進行管理。緩存
微服務風格關不是咱們發明的。也不是一個新的東西，它至少起源於Unix時代的設計原則。之因此這樣，咱們以爲僅僅是當時很是少人考慮過這樣的風格，並認識到把軟件使用這樣的的風格可以帶來不少其它的優勢。
微服務風格的特性
咱們沒有辦法對微服務風格進行準確的定義，但是咱們可以償試着描寫敘述一下微服務風格所應該具備的覺特性。這樣就可以對它打上對應的標籤了。
正如其餘定義中對特性的描寫敘述一新。並不是所有的微服務風格都要所有的特性。但是咱們以爲常見的微服務都應該有這些特性。雖然咱們是至關鬆散的社區核心成員。但是咱們也計劃償試描寫敘述咱們工做中或者在其餘咱們瞭解的組件中所理解的微服務。性能優化
固然，咱們並不依賴於那些已經明白過的定義。網絡
組件與服務
自從咱們從事軟件行業以來。一直但願能夠構建由組件組成的系統，就像咱們所示實現世界由物件構成的同樣。在過去的幾十年裏。咱們已經看到了大部分語言平臺的公共庫的進行了精簡，並取得可觀的進展。
當咱們談論組件的時候。有可能會因爲組件的不一樣定義引發混亂。所以咱們申明，這裏談到的
組件是指軟件中獨立的單元，它能獨立替代和獨立更新。
微服務架構也使用組件庫，但是它把軟件拆分紅服務，並以爲這是基本的組織形式。咱們把
組件庫定義爲程序中相互關係、並使用內存中調用的組件，把
服務定義爲進程間使用如Web請求服務或者遠程調用來相互通訊的組件。（這樣的定義的方式與其餘面向對象程序中服務對象的概念是不同的。）
把服務當成組件（而不是組件庫）一個基本的緣由是服務可以獨立的部署。假設你的應用由多個組件庫組成並跑在一個進程中。那麼不論什麼組件的變動都將致使整體應用的又一次公佈。但是假設由不少服務構成的應用，你可以想像的到每個服務的變動僅需要公佈對應的服務。固然。這也不是絕對的，比方致使服務接口的變動的更新就需要對應服務的變化。但優秀微服務構架，會盡可能避免這樣的服務間的耦合並無缺服務的交互接口。
把服務當成組件的還有一個考慮是這將擁有更新清晰的接口。不少開發語言並無良好的定義公共接口的機制。
一般僅僅有文檔和規範說明，讓用戶避免組件間會致使組件耦合的過分的依賴。只是服務由是是經過明白的遠程接口調用。這個問題就很是easy攻克了。
使用服務也有它的不足之處。
遠程調用比進制內部調用更消耗性能，而且遠程的API比較粗糙。難以使用。假設由於對組件的職責進行變動，影響到跨進程間的交互，那麼這操做起來也比較困難。
第一個可能的特性。咱們看到每個服務是執行在獨立的進程上的。注意，這僅僅是第一個可能的特性。服務也可以由多個進程組成。它們是同一時候開發和部署的，好比服務可能用到一個應用進制和一種數據稟。
環繞業務功能進行組織
當尋找把一個大的應用拆分紅小的部分時，主管一般注意在技術層面。拆分紅UI組、服務邏輯組和數據庫組。當使用這樣的標準對團隊進行劃分時，甚至小小的更變都將致使跨團隊間項目協做。從而消耗時間和預算審批。
一個高效的團隊會針對這樣的狀況進行改善。關注它們所涉及的應用邏輯，並從中作出較好的選擇。
換句話說。邏輯無處不在。Conway's Law的實踐就是一個樣例。
不論什麼組織設計一個系統（廣義上的系統）都會產生一種設計，其結構爲其組織通訊結構的複本。
-- Melvyn Conway, 1967
圖2：Conway's Law的實踐
微服務更傾向於環繞
業務功能對服務結構進行劃分、拆解。這種服務，是針對業務領域有着關完整實現的軟件，它包括使用接口、持久存儲、以及對旬的交互。所以團隊應該是跨職能的，包括完整的開發技術：用戶體驗、數據庫、以及項目管理。
圖3：經過團隊邊界強調服務邊界
www.comparethemarket.com就採用這樣的組織形式。
不一樣職能的團隊同一時候爲各自的產品構建和運營負責，同一時候每個產品又拆分紅多個經過消息引擎通訊的單獨服務。
大型的整體型應用也可以按照業務功能進行模塊化的。雖然這樣的樣例不常見。
固然，咱們敦促一個大型的團隊將一個構建成整體型的應用按照業務功能進行拆分。
咱們能看到主要問題在於。這樣的組件形式會致使很是多的上下文依賴。假設在大量的模塊邊界上都存在這樣的大量的調用。對於團隊的每個成員來講，短時間內是很是難記住的。
此外。咱們發現模塊化方式需要大量的規範去強制運行，固然。大量明白的拆分也讓服務組件在團隊的邊界中更加清晰。
產品不是項目
大部分的軟件開發人員都使用這種開發模式：至力於提供一些被以爲是完整的軟件。一旦開發完畢，軟件將移交給維護部門。而後，開發組就可以解散掉了。
微服務的支持者以爲。這樣的作法是不可取的。並提議開發組應該負責產品的整個生命週期。一個常見的證實是：Amazon的「你編譯，你運維（you build, you run it）」的理念。它要求開發團隊對軟件產品的整個生命週期負責。
這要求開發人員天天都關注軟件產品的執行狀況，並與用戶聯繫的更緊密。同一時候承擔一些售後支持。
成熟的產品會與業務功能進行綁定。除了把軟件當作既定功能的集合外，會進一步關心「軟件怎樣幫助用戶實現業務功能」這種問題。
採用整體型的架構並不是沒有緣由的，但是越小的服務粒度越easy促進用戶與服務提供商以前的關係。
強化終端及弱化通道
當構建不一樣的進程間通訊機制的時候，咱們發現有不少的產品和方法能夠把更加有效方法強增長的通訊機制中。比方企業服務總線（ESB），這種產品提供更有效的方式改進通訊過程當中的路由、編碼、傳輸、以及業務處理規則。
微服務傾向於作例如如下的選擇：強化終端及弱化通道。
微服務的應用致力鬆耦合和高內聚：採用單獨的業務邏輯，表現的更像經典Unix意義上的過濾器同樣。接受請求、處理業務邏輯、返回響應。它們更喜歡簡單的REST風格，而不是複雜的協議。如WS或者BPEL或者集中式框架。
有兩種協議最經常被使用到：包括資源API的HTTP的請求-響應和輕量級消息通訊協議。
最爲重要的建議爲：
Be of the web, not behind the web(善於利用網絡，而不是限制使用網絡。)
---- Ian Robinson
微服務團隊採用這種原則和規範：基於互聯網（廣義上，包括Unix系統）構建系統。
這樣經常使用的資源差點兒不用什麼的代價就可以被開發人員或者執行商緩存。
另一種作法是經過輕量級消息總線來公佈消息。
這種的通訊協議很的單一（單一到僅僅負責消息路由）。像RabbitMQ或者ZeroMQ這種簡單的實現甚至像可靠的異步機制都沒提供，以致於需要依賴產生或者消費消息的終端或者服務來處理這類問題。
在整體工風格中。組件在進程內運行，進程間的消息通訊一般經過調用方法或者回調函數。從整體式風格到微服務框架最大的問題在於通訊方式的變動。從內存內部原始的調用變成遠程調用。產生的大量的不可靠通訊。所以，你需要把粗粒度的方法成更加細粒度的通訊。
分散治理
集中治理的一種優勢是在單一平臺上進行標準化。
經驗代表這樣的趨勢的優勢在縮小。因爲並不是所有的問題都一樣，而且解決方式並不是萬能的。咱們更加傾向於採用適當的工具解決適當的問題，整體式的應用在必定程度上比多語言環境更有優點，但也適合所有的狀況。
把整體式框架中的組件。拆分紅不一樣的服務，咱們在構建它們時有不少其它的選擇。
你想用Node.js去開發報表頁面嗎？作吧。用C++來構建時時性要求高的組件？很是好。
你想以在不一樣類型的數據庫中切換，來提升組件的讀取性能？咱們現在有技術手段來實現它了。
固然，你是可以作不少其它的選擇，但也不意味的你就可以這樣作，因爲你的系統使用這樣的方式進行侵害意味着你已經有的決定。
採用微服務的團隊更喜歡不一樣的標準。他們不會把這些標準寫在紙上，而是喜歡這種思想：開發實用的工具來解決開發人員遇到的類似的問題。這些工具一般從實現中成長起來，並進行的普遍範圍內分享，固然。它們有時，並不必定。會採用開源模式。現在開源的作法也變得愈來愈廣泛，git或者github成爲了它們其實的版本號控制系統。
Netfix就是這種一個組織。它是很好的一個樣例。
分享實用的、尤爲是通過實踐的代碼庫激勵着其餘的開發着也使用類似的方式來解決類似的問題，固然，也保留着依據需要使用不一樣的方法的權力。共享庫更關注於數據存儲、進程內通訊以及咱們接下來作討論到的本身主動化等這些問題上。
微服務社區中，開銷問題特別引人注意。這並不是說。社區不以爲服務交互的價值。
相反，正是因爲發現到它的價值。這使得他們在尋找各類方法來解決它們。
如Tolearant Reader和Consumer-Driven Contracts這種設計模式就經常被微服務使用。這些模式攻克了獨立服務在交互過程當中的消耗問題。
使用Consumer-Driven Contracts添加了你的信心，並實現了高速的反饋機制。其實。咱們知道澳大利亞的一個團隊致力使用Consumer-Drvien Contracts開發新的服務。
他們使用簡單的project，幫助他們定義服務的接口。
使得在新服務的代碼開始編寫以前，這些接口就成爲本身主動化構建的一個部分。構建出來的服務，僅僅需要指出這些接口適用的範圍。一個優雅的方法避免了新軟件中的'YAGNI '困境。這些技術和工具在使用過程當中無缺，經過下降服務間的耦合，限制了集中式管理的需求。
或許分散治理普及於亞馬遜「編譯它，運維它」的理念。
團隊爲他們開發的軟件負全部責任。也包括7*24小時的執行。全責任的方式並不常見。但是咱們確實發現愈來愈多的公司在他們的團隊中所推廣。Netfix是另一個接受這樣的理念的組件。天天凌晨3點被鬧鐘吵醒，因爲你很的關注寫的代碼質量。這在傳統的集中式治理中這是同樣多麼不思議的事情呀。
分散數據管理
對數據的分散管理有多種不一樣的表現形式。最爲抽象層次。它意味着不一樣系統中的通用概念是不一樣的。這帶來的覺問題是大型的跨系統整合時，用戶使用不一樣的售後支持將獲得不一樣的促銷信息。這樣的狀況叫作並無給用戶顯示所有的促銷手段。不一樣的語法確實存在一樣的詞義或者（更差）一樣的詞義。
應用之間這個問題很是廣泛。但應用內部這個問題也存在，特別是當應用拆分紅不一樣的組件時。對待這個問題很是實用的方式爲
Bounded Context的領域驅動設計。DDD把複雜的領域拆分紅不一樣上下文邊界以及它們之間的關係。
這種過程對於整體架構和微服務框架都很是實用，但是服務間存在着明顯的關係。幫助咱們對上下文邊界進行區分，同一時候也像咱們在業務功能中談到的，強行拆分。
當對概念模式下決心進行分散管理時，微服務也決定着分散數據管理。
當整體式的應用使用單一邏輯數據庫對數據持久化時，企業一般選擇在應用的範圍內使用一個數據庫，這些決定也受廠商的商業權限模式驅動。微服務讓每個服務管理本身的數據庫：無論是一樣數據庫的不一樣實例，或者是不一樣的數據庫系統。這樣的方法叫Polyglot Persistence。
你可以把這樣的方法用在整體架構中，但是它更常見於微服務架構中。
圖4：Polyglot Persistence
微服務音分散數據現隨意味着管理數據更新。
處理數據更新的常常用法是使用事務來保證不一樣的資源改動數據庫的一致性。這樣的方法一般在整體架構中使用。
使用事務是因爲它能夠幫助處理一至性問題，但對時間的消耗是嚴重的，這給跨服務操做帶來難題。
分佈式事務很難以實施，所以微服務架構強調服務間事務的協調，並清楚的認識一致性僅僅能是終於一致性以及經過補償運算處理問題。
選擇處理不一致問題對於開發團隊來講是新的挑戰。但是也是一個常見的業務實踐模式。一般業務上贊成必定的不一致以知足高速響應的需求。但同一時候也採用一些恢復的進程來處理這樣的錯誤。當業務上處理強一致性消耗比處理錯誤的消耗少時。這樣的付出是值的的。
基礎設施本身主動化
基礎設施本身主動化技術在過去幾年中獲得了長足的發展：雲計算，特別是AWS的發展，下降了構建、公佈、運維微服務的複雜性。
不少使用微服務架構的產品或者系統。它們的團隊擁有豐富的
持集部署以及它的前任
持續集成的經驗。團隊使用這樣的方式構建軟件導致更普遍的依賴基礎設施本身主動化技術。
下圖說明這樣的構建的流程：
圖5：主要的構建流程
雖然這不是介紹本身主動部署的文章。但咱們也打算介紹一下它的主要特徵。咱們但願咱們的軟件應該這樣方便的工做，所以咱們需要不少其它的本身主動化測試。
流程中工做的軟件改進意味着咱們能本身主動的部署到各類新的環境中。
整體風格的應用至關開心的在各類環境中構建、測試、公佈。
事實證實，一旦你打算投資一條整體架構應用本身主動化的的生產線，那麼你會發現公佈不少其它的應用彷佛非不那麼的可怕。
記住。CD（持續部署）的一個目標在於讓公佈變得無趣，所以無論是一個仍是三個應用，它都同樣的無趣。
還有一個方面，咱們發現使用微服務的團隊更加依賴於基礎設施的本身主動化。相比之下。在整體架構也微服務架構中。雖然公佈的場景不一樣，但公佈工做的無趣並無多大的差異。
圖6：模塊化部署的差異
容錯性設計
使用服務做爲組件的一個結果在於應用需要有能容忍服務的故障的設計。任務服務可能因爲供應商的不可靠而故障，client需要儘量的優化這樣的場景的響應。跟整體構架相比，這是一個缺點，因爲它帶來的額外的複雜性。這將讓微服務團隊時刻的想到服務故障的狀況下用戶的體驗。Netflix的
Simian Army可以爲每個應用的服務及數據中心提供平常故障檢測和恢復。
這樣的產品中的本身主動化測試可以讓大部分的運維團隊正常的上下班。這並不意味着整體構架的應用沒有這麼靜止的監控配置，僅僅是在咱們的經驗中它並不常見。
由於服務可以隨時故障，高速故障檢測，乃至，本身主動恢復變動很重要。微服務應用把實時的監控放在應用的各個階段中，檢測構架元素（每秒數據庫的接收的請求數）和業務相關的指標（把分鐘接收的定單數）。監控系統可以提供一種早期故障告警系統，讓開發團隊跟進並調查。
對於微服務框架來講。這至關重要，因爲微服務相互的通訊可能致使緊急意外行爲。
不少專家車稱讚這樣的緊急事件的價值，但事實是這樣的緊急行爲有時是災難。監控是相當重要的。它能高速發現這樣的緊急不良行爲，讓咱們迅速修復它。
整體架構。跟微服務同樣，在構建時是通明的，實情上，它們就是這樣子的。它們不一樣之處在於。你需要清楚的認識到不一樣進程間執行的服務是不相關的。庫對於同一進程是透明的，也所以不那麼重要了。
微服務團隊指望清楚的監控和記錄每個服務的配置。比方使用儀表盤顯示上/下線狀態、各類運維和業務相關的指標。對斷路器（circuit breaker）狀態、眼下的吞吐量和時延細節，咱們也會經常遇到。
設計改進
微服務實踐者。一般有不斷改進設計的背景。他們把服務分解成進一步的工具。
這些工具可以讓應用開發人員在不改變速度狀況下。控制都他們的應用的需求變動。變動控制不意味首下降變動，而是使用適當的方式和工具，讓它更加頻繁。至少。很是好讓它變得可控。
不論怎樣，當你試圖軟件系統拆分紅組件時，你將面臨着怎樣拆分的問題。那麼咱們的決定拆分咱們應用的原則是什麼呢？首要的因素，組件能夠被獨立替換和更新的。這意味着咱們尋找的關鍵在於，咱們要想象着重寫一個組件而不影響它們以前的協做關係。其實。不少的微服務小組給它進一步的預期：服務應該能夠報廢的，而不是要長久的發展的。
Guardian站點就是這方面的一個優秀的樣例，它初期被設計和構建成一個整體架構。但它已經向微服務的發展了。整體構架仍然是它站點的核心，但是他們使用微服務來添加那些使用整體架構API的新特性。這樣的方法添加這些暫時的特性很方便，比方運動新聞的特稿。
這樣站點的一個部分可以使用高速的開發語言迅速整合起來。當它過期後可以一次性移除。咱們發現一家金融機構用類似的方法添加新的市場營銷活動，數週或者幾個月後把它撤銷。
可取代是模塊化開發中的一個特例，它是用模塊來應對需要變動的。
你但願讓變動是一樣模塊，一樣週期中進行變化而已。系統的某些很是小作變動部分，也應該放在不一樣的服務中。這樣它們更easy讓它們消亡。
假設你發現兩個服務一直反覆的變動時。這就是一個要合併它們的信號了。
把組件改爲服務，添加了細化公佈計劃的一個機會。
整體構架的任務變動需要整個應用的完整的構建和公佈。
然而，使用微服務，你僅僅需要公佈你要改動的服務就可以了。這將簡化和加速你的公佈週期。
缺點是你需要爲一個變動服務公佈可能中斷用戶的體驗而操心。
傳統的集成方法是使用版本號來處理這些問題。但是微服務版本號僅是最後的通告手段。咱們需要在設計服務時儘量的容忍供應商的變動，以免提供多個版本號。
其餘
微服務系統多大？
雖然「微服務」一詞在架構風格中愈來愈流行，它的名字很是不辛讓人關注它的服務大小，以及對「微」這個組成的爭議。在咱們與微服務實踐者的談話中。咱們發現了服務的大小範圍。被報道的最大團隊遵循亞馬遜Tow Pizaa團隊理念（比方，一個團隊吃兩個比薩就可以了。
），這意味着不超過20號（一打）人。
咱們發現最小配置是半打的團隊支撐起一打的服務。
這也引起這種考慮：規模爲一個服務一打人到一個服務一我的的團隊打上微服務的標籤。此刻咱們以爲，它們是同樣的，但是隨着對這種風格的深刻研究，也存在咱們改變咱們的想法的可能。
微服務與SOA
當前咱們談到微服務時，通常會問，這是否是咱們20年前討論的面向服務架構（SOA）。這是一個很是好的觀點，因爲微服務風格也SOA所提倡的一些優點很是類似。雖然如此，問題在於SOA意味的
太多不一樣的東西了，所以一般時候咱們談的所謂「SOA」時，它與咱們談論的風格不一至，因爲它通常是指在整體風格應用中的ESB。
此外，咱們發現面向服務的風格是這麼的拙劣：從試圖使用ESB隱藏複雜性。 到使用多年才認識到發費數百美圓卻沒產生任務價值這種失敗。到集中治理模式抑制變動。而且這些問題每每很是難發現。
可以確定的時，微服務社區中使用的不少的技術都開發人員是從大型機構的整合服務經驗中發展來的。
Tolerant Reader模式就是這種一個樣例。由於互聯網的發展。利用簡單的協議這個方案，讓它從這些經驗傳達的出來。這是從已經很是複雜的集中式標準中的一種反模式，坦白的說，真讓人驚歎。（無論什麼時候，當你需要用一個服務來管理你的所有的服務，你就知道這很是麻煩。）
SOA的這樣的常見行爲讓微服務的提倡者拒絕打上SOA的標籤，雖然有人以爲微服務是從SOA中發展而來的，也許面向服務是對的。
無論怎樣，其實SOA表達這麼多的含義，它給一個團隊清醒的認識到這樣的構架風格就已經值的了。
多語言。多選擇
JVM作爲一個平臺。它的增加就是一個平臺中執行多語言的最大的樣例。
過去二十年中，它一般作爲更高層次語言的殼。以達到更高層次的抽象。比方，研究它的內部結構，、使用低級的語言寫更高效的代碼。雖然如此。不少整體風格並不需要這樣的層次的性能優化或者在語法及高層次上的抽象，這非常常見（讓咱們很是失望）。此外整體構架一般意味着使用單一的語言。這也限制着使用技術的數量。
實踐標準和強制標準
它有點尷尬。微服務團隊傾向於避免這樣的一般由企業架構隊伍定製的僵硬的強制標準，但是它們卻很樂於甚至推廣這些開放的標準，如HTTP、ATOM、其餘微規範。
關鍵的不一樣在這些標準是怎麼開發出來的，以及它們是怎麼被推廣的。
標準被一些組件管理，如IETF認證標準，僅當它們在互聯網上有幾個在用的實現。一般源自於開源project的成功應用。
這些標準單獨分離出來，與那種在企業中一般有沒有什麼編碼經驗的或者沒有什麼影響力的廠商標準進行差異。
讓作對事更easy
一方面，咱們發現在持續公佈、部署愈來愈多的使用本身主動化。是很是多實用的工具開發出來幫助開發人員和運營商的努力結果。爲打包、代碼管理、支撐服務的工具。或者添加標準監控的記錄的工具。現在都非常常見了。網絡中最好的。可能就是
Netflix's的開源工具，但是包括
Dropwizard在內的其餘工具也被普遍的使用着。
斷路器(circuit breaker)和產品中現有的代碼
同步是有害的
任務時候，你在服務間的調用使用同步的方法，都會遇到宕機時間的乘積效應。簡單的說，你的系統宕機時間是你係統的單獨組件的宕機時間的乘積。你面臨的選擇使用異步或者管理宕機時間。
在www.guardian.co.uk中，它們在新平臺中使用一種簡單的規則來實現它：在Netflix中每次用戶請求的同步調用。他們又一次設計的平臺API都會把它構建成異步的API來運行。
微服務是將來嗎？
咱們寫這篇文章的主要目的在於解釋微服務的主要思想和原則。
但是發時間作這事的時候。咱們清醒的認識到微服務構架風格是一個很重要的想法：一個值得企業應用中認真考慮的東西。咱們近期使用這樣的風格構建了幾個系統，認識那些也使用和喜歡這樣的方法的愛好者。
咱們認識的使用這樣的方式的先行者，包括亞馬遜、Netflix、The Guardian、The UK Government Digital Service、realestate.com.au、Forward和comparethemarket.com。2013看的巡迴會議充滿了向正在想成爲微服務一分子的公司，包括Travis CI。此外，大量的組件正在從事咱們以爲是微服務的事，僅僅是沒有使用微服務的名字而已。
（一般，它們被打上SOA的標籤。雖然。咱們以爲SOA有不少不一樣的地方。）
雖然有這些積極的經驗，而後，咱們也不急於確認微服務是將來軟件架構方向。
至今爲止。咱們的經驗與整體風格的應該中相比出來的是有優點的，但是咱們意識知這種事實，咱們並無足夠的時間來證實咱們的論證。
你所使用的架構通常是你開發出來後。使用的幾年的實際成果。
咱們看到這些project是在一個優秀的團隊，帶着對模塊化的強烈追求，使用在過去幾年中已經衰退的整體架構構建出來的。不少人相信，這樣的衰退不太可能與微服務有關，因爲服務邊界是清晰的並且很是難再無缺的。
然而，當咱們還沒看到足夠多的系統執行足夠長時間時，咱們不能確定微服務構架是成熟的。
固然，還有緣由就是，有人指望微服務構架不夠成熟。
在組件化方面的不論什麼努力，其成功都依賴於軟件怎樣拆分紅適合的組件。指出組件化的準確邊界應該在那，這是很困難的。
改良設計要認可邊界的權益困境和所以帶來的易於重構的重要性。
但是當你的組件是被遠程通訊的服務時。重構比進程內的庫又要困難的多。服務邊界上的代碼遷移是困難的，任務接口的變動需要參與者的共同協做，向後兼容的層次需要被添加。測試也變動更加複雜。
還有一個問題在於，假設組件並無清晰的劃分，你的工做的複雜性將從組件內部轉向組件間的關係。作這事不只要環繞着複雜。它也要面對着不清晰和更難控制的地方。很是easy想到。當你在一個小的、簡單的組件內找東西。總比在沒有關係的混亂的服務間要easy。
最後。團隊技能也是重要的因素。新的技術傾向於被掌握不少其它的技能的團隊使用。但是掌握多技能的團隊中使用的技巧在較少技能的團隊中並不是必需的。咱們發現大量的少技能的團隊構建混亂的整合構架。但是它要發時間去證實使用微服務在這樣的狀況下會發生什麼。一個糟糕的團隊一般開發糟糕的系統：很是難說，微服務在這樣的狀況下可否幫助它們。仍是破壞它們。
一個理性的爭議在於，咱們據說，你不該該從微服務構架開始作。最好從整體構架開發，作模塊化開發，而後當整體構架出現故障是再把模塊化拆分紅服務。
（雖然這樣的建議不是好主意，因爲一個好的進程內接口並不是一個好的服務接口。
）
所以咱們持這樣的慎重的樂觀。
到眼下爲止，咱們尚未足夠認識，關於微構架是否能被大範圍的推廣。咱們不能確定的說。咱們要終結什麼。但是軟件開發的挑戰在於你僅僅能在不完整的信息中決定你眼下要處理的問題。
