微服務（Microservices）【翻譯】

時間 2019-11-13

標籤微服 microservices 翻譯简体版

原文原文鏈接

完整版文章請訪問個人我的博客查看：http://damienzhong.com/2018/03/12/%E5%BE%AE%E6%9C%8D%E5%8A%A1%EF%BC%88microservices%EF%BC%89%E3%80%90%E7%BF%BB%E8%AF%91%E3%80%91/

微服務

「微服務架構（Microservice Architecture）」一詞在過去幾年裏普遍的傳播，它用於描述一種設計應用程序的特別方式，做爲一套獨立可部署的服務。目前，這種架構方式尚未準確的定義，可是在圍繞業務能力的組織、自動部署（automated deployment）、端智能（intelligence in the endpoints）、語言和數據的分散控制，卻有着某種共同的特徵。html

「微服務（Microservices）」——只不過在滿大街充斥的軟件架構中的一新名詞而已。儘管咱們很是鄙視這樣的東西，可是這玩意所描述的軟件風格，愈來愈引發咱們的注意。在過去幾年裏，咱們發現愈來愈多的項目開始使用這種風格，以致於咱們身邊的同事在構建企業級應用時，把它理所固然的認爲這是一種默認開發形式。然而，很不幸，微服務風格是什麼，應該怎麼開發，關於這樣的理論描述卻很難找到。git

簡而言之，微服務架構風格，就像是把一個單獨的應用程序開發爲一套小服務，每一個小服務運行在本身的進程中，並使用輕量級機制通訊，一般是 HTTP API。這些服務圍繞業務能力來構建，並經過徹底自動化部署機制來獨立部署。這些服務使用不一樣的編程語言書寫，以及不一樣數據存儲技術，並保持最低限度的集中式管理。github

在開始介紹微服務風格（microservice style）前，比較一下總體風格（monolithic style）是頗有幫助的：一個完整應用程序（monolithic application）構建成一個單獨的單元。企業級應用一般被構建成三個主要部分：客戶端用戶界面（由運行在客戶機器上的瀏覽器的 HTML 頁面、Javascript 組成）、數據庫（由許多的表構成一個通用的、相互關聯的數據管理系統）、服務端應用。服務端應用處理 HTTP 請求，執行領域邏輯（domain logic），檢索並更新數據庫中的數據，使用適當的 HTML 視圖發送給瀏覽器。服務端應用是完整的，是一個單獨的的邏輯執行。任何對系統的改變都涉及到從新構建和部署一個新版本的服務端應用程序。web

這樣的總體服務（monolithic server）是一種構建系統很天然的方式。雖然你能夠利用開發語基礎特性把應用程序劃分紅類、函數、命名空間，但全部你處理請求的邏輯都運行在一個單獨的進程中。在某些場景中，開發者能夠在的筆計本上開發、測試應用，而後利用部署通道來保證通過正常測試的變動，發佈到產品中。你也可使用橫向擴展，經過負載均衡將多個應用部署到多臺服務器上。數據庫

總體應用程序（Monolithic applications）至關成功，可是愈來愈多的人感受到有點不妥，特別是在雲中部署時。變動發佈週期被綁定了——只是變動應用程序的一小部分，卻要求整個從新構建和部署。隨着時間的推移，很難再保持一個好的模塊化結構，使得一個模塊的變動很難不影響到其它模塊。擴展就須要整個應用程序的擴展，而不能進行部分擴展。編程

圖 1 整理架構與微服務架構設計模式

這致使了微服務架構風格（microservice architectural style）的出現：把應用程序構建爲一套服務。事實是，服務能夠獨立部署和擴展，每一個服務提供了一個堅實的模塊邊界，甚至不一樣的服務能夠用不一樣的編程語言編寫。它們能夠被不一樣的團隊管理。瀏覽器

咱們必須說，微服務風格不是什麼新東西，它至少能夠追溯到 Unix 的設計原則。可是並無太多人考慮微服務架構，若是他們用了，那麼不少軟件都會更好。緩存

微服務風格的特性

微服務風格並無一個正式的定義，但咱們能夠嘗試描述一下微服務風格所具備的共同特色。並非全部的微服務風格都要具備全部的特性，但咱們指望常見的微服務都應該有這些特性。咱們的意圖是嘗試描述咱們工做中或者在其它咱們瞭解的組件中所理解的微服務。特別是，咱們不依賴於那些已經明確過的定義。性能優化

組件化（Componentization ）與服務（Services）

自從咱們開始軟件行業以來，一直但願由組件構建系統，就像咱們在物理世界所看到的同樣。在過去的幾十年裏，咱們已經看到了公共庫的大量簡編取得了至關的進步，這些庫是大部分語言平臺的一部分。

當咱們談論組件時，可能會陷入一個困境——什麼是組件。咱們的定義是，組件（component）是一個可獨立替換和升級的軟件單元。

微服務架構（Microservice architectures）會使用庫（libraries），但組件化軟件的主要方式是把它拆分紅服務。咱們把庫（libraries）定義爲組件，這些組件被連接到程序，並經過內存中函數調用（in-memory function calls）來調用，而服務（services ）是進程外組件（out-of-process components），他們利用某個機制通訊，好比 WebService 請求，或遠程過程調用（remote procedure call）。組件和服務在不少面向對象編程中是不一樣的概念。

把服務當成組件（而不是組件庫）的一個主要緣由是，服務能夠獨立部署。若是你的應用程序是由一個單獨進程中的不少庫組成，那麼對任何一個組件的改變都將致使必須從新部署整個應用程序。可是若是你把應用程序拆分紅不少服務，那你只須要從新部署那個改變的服務。固然，這也不是絕對的，有些服務會改變致使協調的服務接口，可是一個好的微服務架構的目標就是經過在服務契約（service contracts）中解耦服務的邊界和進化機制來避免這些。

另外一個考慮是，把服務當組件將擁有更清晰的組件接口。大多數開發語言都沒有一個良好的機制來定義一個發佈的接口（Published Interface）。發佈的接口是指一個類向外公開的成員，好比 Java 中的聲明爲 Public 的成員，C# 中聲明爲非 Internal 的成員。一般只有在文檔和規範中會說明，這是爲了讓避免客戶端破壞組件的封裝性，阻止組件間緊耦合。服務經過使用公開遠程調用機制能夠很容易避免這些。

像這樣使用服務也有不足之處。遠程調用比進制內調用更消耗資源，所以遠程 API 須要粗粒度（coarser-grained），但這會比較難使用。若是你須要調整組件間的職責分配，當跨越進程邊界時，這樣作將會很難。

一個多是，咱們看到，服務能夠映射到運行時進程（runtime processes）上，但也只是一個可能。服務能夠由多個進程組成，它們會同時開發和部署，例如一個應用程序進程和一個只能由這個服務使用的數據庫。

圍繞業務功能的組織

當尋找把一個大的應用程序拆分紅小的部分時，一般管理都會集中在技術層面，UI團隊、服務端業務邏輯團隊和數據庫團隊。當使用這種標準對團隊進行劃分時，甚至小小的更變都將致使跨團隊項目協做，從而消耗時間和預算審批。一個高效的團隊會針對這種狀況進行改善，兩權相害取其輕。業務邏輯無處不在。實踐中，這就是 Conway’s Law 的一個例子。

設計一個系統的任何組織（廣義上）都會產生這樣一種設計，其結構是組織交流結構的複製。

——Melvyn Conway, 1967

Melvyn Conway 的意識是，像下圖所展現的，設計一個系統時，將人員劃分爲 UI 團隊，中間件團隊，DBA 團隊，那麼相應地，軟件系統也就會天然地被劃分爲 UI 界面，中間件系統，數據庫。

圖 2 實踐中的 Conway’s Law

微服務（microservice ）的劃分方法不一樣，它傾向圍繞業務功能的組織來分割服務。這些服務實現商業領域的軟件，包括用戶界面，持久化存儲，任何的外部協做。所以，團隊是跨職能的（cross-functional），包含開發過程所要求的全部技能：用戶體驗（user-experience）、數據庫（database）和項目管理（project management）。

圖 3 經過團隊邊界強調服務邊界

www.comparethemarket.com就是採用這種組織形式。跨職能的團隊同時負責構建和運營每一個產品，每一個產品被分割成許多單個的服務，這些服務經過消息總線（Message Bus）通訊。

大型的總體應用程序（monolithic applications）也能夠按照業務功能進行模塊化（modularized），儘管這樣狀況不常見。固然，咱們能夠敦促一個構建總體應用程序（monolithic application ）的大型團隊，按業務線來分割本身。咱們已經看到的主要問題是，這種組件形式會致使不少的依賴。若是總體應用程序（monolithic applications）跨越不少模塊邊界（modular boundaries ），那麼對於團隊的每一個成員短時間內修復它們是很困難的。此外，咱們發現，模塊化須要大量的強制規範。服務組件所要求的必需的更明確的分離使得保持團隊邊界清晰更加容易。

產品不是項目

大部分的軟件開發者都使用這樣的項目模式：至力於提供一些被認爲是完整的軟件。交付一個他們認爲完成的軟件。軟件移交給運維組織，而後，解散構建軟件的團隊。

微服務（Microservice ）的支持者認爲這種作法是不可取的，並提議團隊應該負責產品的整個生命週期。Amazon 理念是「你構建，你運維（you build, you run it）」，要求開發團隊對軟件產品的整個生命週期負責。這要求開發者天天都關注他們的軟件運行如何，增長更用戶的聯繫，同時承擔一些售後支持。

產品的理念，跟業務能力聯繫起來。不是着眼於完成一套功能的軟件，而是有一個持續的關係，是如何可以幫助軟件及其用戶提高業務能力。

爲何相同的方法不能用在總體應用程序（monolithic applications），但更小的服務粒度可以使建立服務的開發者與使用者之間的我的聯繫更容易。

強化終端及弱化通道

當構建不一樣的進程間通訊機制的時候，咱們發現有許多的產品和方法可以把更加有效方法強加入的通訊機制中。好比企業服務總線（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開發新的服務。他們使用簡單的工程，幫助他們定義服務的接口。使得在新服務的代碼開始編寫以前，這些接口就成爲自動化構建的一個部分。構建出來的服務，只須要指出這些接口適用的範圍，一個優雅的方法避免了新軟件中的’YAGNI ‘困境。這些技術和工具在使用過程當中完善，經過減小服務間的耦合，限制了集中式管理的需求。

也許分散治理普及於亞馬遜「編譯它，運維它」的理念。團隊爲他們開發的軟件負所有責任，也包含7*24小時的運行。全責任的方式並不常見，可是咱們確實發現愈來愈多的公司在他們的團隊中所推廣。Netfix是另一個接受這種理念的組件。天天凌晨3點被鬧鐘吵醒，由於你很是的關注寫的代碼質量。這在傳統的集中式治理中這是同樣多麼不思議的事情呀。

分散數據管理

對數據的分散管理有多種不一樣的表現形式。最爲抽象層次，它意味着不一樣系統中的通用概念是不一樣的。這帶來的覺問題是大型的跨系統整合時，用戶使用不一樣的售後支持將獲得不一樣的促銷信息。這種狀況叫作並無給用戶顯示全部的促銷手段。不一樣的語法確實存在相同的詞義或者（更差）相同的詞義。

應用之間這個問題很廣泛，但應用內部這個問題也存在，特別是當應用拆分紅不一樣的組件時。對待這個問題很是有用的方式爲Bounded Context的領域驅動設計。DDD把複雜的領域拆分紅不一樣上下文邊界以及它們之間的關係。這樣的過程對於總體架構和微服務框架都頗有用，可是服務間存在着明顯的關係，幫助咱們對上下文邊界進行區分，同時也像咱們在業務功能中談到的，強行拆分。

當對概念模式下決心進行分散管理時，微服務也決定着分散數據管理。當總體式的應用使用單一邏輯數據庫對數據持久化時，企業一般選擇在應用的範圍內使用一個數據庫，這些決定也受廠商的商業權限模式驅動。微服務讓每一個服務管理本身的數據庫：不管是相同數據庫的不一樣實例，或者是不一樣的數據庫系統。這種方法叫Polyglot Persistence。你能夠把這種方法用在總體架構中，可是它更常見於微服務架構中。

圖 4 Polyglot Persistence

微服務音分散數據現任意味着管理數據更新。處理數據更新的經常使用方法是使用事務來保證不一樣的資源修改數據庫的一致性。這種方法一般在總體架構中使用。

使用事務是由於它可以幫助處理一至性問題，但對時間的消耗是嚴重的，這給跨服務操做帶來難題。分佈式事務很是難以實施，所以微服務架構強調服務間事務的協調，並清楚的認識一致性只能是最終一致性以及經過補償運算處理問題。

選擇處理不一致問題對於開發團隊來講是新的挑戰，可是也是一個常見的業務實踐模式。一般業務上容許必定的不一致以知足快速響應的需求，但同時也採用一些恢復的進程來處理這種錯誤。當業務上處理強一致性消耗比處理錯誤的消耗少時，這種付出是值的的。

基礎設施自動化

基礎設施自動化技術在過去幾年中獲得了長足的發展：雲計算，特別是AWS的發展，減小了構建、發佈、運維微服務的複雜性。

許多使用微服務架構的產品或者系統，它們的團隊擁有豐富的持集部署以及它的前任持續集成的經驗。團隊使用這種方式構建軟件導致更普遍的依賴基礎設施自動化技術。下圖說明這種構建的流程：

圖 5 基本的構建流程

儘管這不是介紹自動部署的文章，但咱們也打算介紹一下它的主要特徵。咱們但願咱們的軟件應該這樣方便的工做，所以咱們須要更多的自動化測試。流程中工做的軟件改進意味着咱們能自動的部署到各類新的環境中。

總體風格的應用至關開心的在各類環境中構建、測試、發佈。事實證實，一旦你打算投資一條總體架構應用自動化的的生產線，那麼你會發現發佈更多的應用彷佛非不那麼的可怕。記住，CD（持續部署）的一個目標在於讓發佈變得無趣，所以不管是一個仍是三個應用，它都同樣的無趣。

另外一個方面，咱們發現使用微服務的團隊更加依賴於基礎設施的自動化。相比之下，在總體架構也微服務架構中，儘管發佈的場景不一樣，但發佈工做的無趣並無多大的區別。

圖 6 模塊化部署的區別

容錯性設計

使用服務做爲組件的一個結果在於應用須要有能容忍服務的故障的設計。任務服務可能由於供應商的不可靠而故障，客戶端須要儘量的優化這種場景的響應。跟總體構架相比，這是一個缺點，由於它帶來的額外的複雜性。這將讓微服務團隊時刻的想到服務故障的狀況下用戶的體驗。Netflix 的Simian Army能夠爲每一個應用的服務及數據中心提供平常故障檢測和恢復。

這種產品中的自動化測試可讓大部分的運維團隊正常的上下班。這並不意味着總體構架的應用沒有這麼精巧的監控配置，只是在咱們的經驗中它並不常見。

因爲服務能夠隨時故障，快速故障檢測，乃至，自動恢復變動很是重要。微服務應用把實時的監控放在應用的各個階段中，檢測構架元素（每秒數據庫的接收的請求數）和業務相關的指標（把分鐘接收的定單數）。監控系統能夠提供一種早期故障告警系統，讓開發團隊跟進並調查。

對於微服務框架來講，這至關重要，由於微服務相互的通訊可能致使緊急意外行爲。許多專家車稱讚這種緊急事件的價值，但事實是這種緊急行爲有時是災難。監控是相當重要的，它能快速發現這種緊急不良行爲，讓咱們迅速修復它。

總體架構，跟微服務同樣，在構建時是通明的，實情上，它們就是這樣子的。它們不一樣之處在於，你須要清楚的認識到不一樣進程間運行的服務是不相關的。庫對於同一進程是透明的，也所以不那麼重要了。

微服務團隊指望清楚的監控和記錄每一個服務的配置，好比使用儀表盤顯示上/下線狀態、各類運維和業務相關的指標。對斷路器（circuit breaker）狀態、目前的吞吐量和時延細節，咱們也會常常遇到。

設計改進

微服務實踐者，一般有不斷改進設計的背景，他們把服務分解成進一步的工具。這些工具可讓應用開發者在不改變速度狀況下，控制都他們的應用的需求變動。變動控制不意味首減小變動，而是使用適當的方式和工具，讓它更加頻繁，至少，很好讓它變得可控。

不論如何，當你試圖軟件系統拆分紅組件時，你將面臨着如何拆分的問題。那麼咱們的決定拆分咱們應用的原則是什麼呢？首要的因素，組件能夠被獨立替換和更新的，這意味着咱們尋找的關鍵在於，咱們要想象着重寫一個組件而不影響它們以前的協做關係。事實上，許多的微服務小組給它進一步的預期：服務應該可以報廢的，而不是要長久的發展的。

Guardian網站就是這方面的一個優秀的例子，它初期被設計和構建成一個總體架構，但它已經向微服務的發展了。總體構架仍然是它網站的核心，可是他們使用微服務來增長那些使用總體架構API的新特性。這種方法增長這些臨時的特性很是方便，好比運動新聞的特稿。這樣站點的一個部分可使用快速的開發語言迅速整合起來，當它過期後能夠一次性移除。咱們發現一家金融機構用類似的方法增長新的市場營銷活動，數週或者幾個月後把它撤銷。

可代替是模塊化開發中的一個特例，它是用模塊來應對須要變動的。你但願讓變動是相同模塊，相同週期中進行變化而已。系統的某些很小作變動部分，也應該放在不一樣的服務中，這樣它們更容易讓它們消亡。若是你發現兩個服務一直重複的變動時，這就是一個要合併它們的信號了。

把組件改爲服務，增長了細化發佈計劃的一個機會。總體構架的任務變動須要整個應用的完整的構建和發佈。然而，使用微服務，你只須要發佈你要修改的服務就能夠了。這將簡化和加速你的發佈週期。缺點是你須要爲一個變動服務發佈可能中斷用戶的體驗而擔憂。傳統的集成方法是使用版原本處理這些問題，可是微服務版本僅是最後的通告手段。咱們須要在設計服務時儘量的容忍供應商的變動，以免提供多個版本。

2微服務是將來嗎

咱們寫這篇文章的主要目的在於解釋微服務的主要思想和原則。可是發時間作這事的時候，咱們清醒的認識到微服務構架風格是一個很是重要的想法：一個值得企業應用中認真考慮的東西。咱們最近使用這種風格構建了幾個系統，認識那些也使用和喜歡這種方法的愛好者。

咱們認識的使用這種方式的先行者，包含亞馬遜、Netflix、The Guardian、The UK Government Digital Service、realestate.com.au、Forward和comparethemarket.com。2013看的巡迴會議充滿了向正在想成爲微服務一分子的公司，包含Travis CI。此外，大量的組件正在從事咱們認爲是微服務的事，只是沒有使用微服務的名字而已。（一般，它們被打上SOA的標籤，儘管，咱們認爲SOA有許多不一樣的地方。）

儘管有這些積極的經驗，而後，咱們也不急於確認微服務是將來軟件架構方向。至今爲止，咱們的經驗與總體風格的應該中相比出來的是有優點的，可是咱們意識知這樣的事實，咱們並無足夠的時間來證實咱們的論證。

你所使用的架構一般是你開發出來後，使用的幾年的實際成果。咱們看到這些工程是在一個優秀的團隊，帶着對模塊化的強烈追求，使用在過去幾年中已經衰退的總體架構構建出來的。許多人相信，這種衰退不太可能與微服務有關，由於服務邊界是清晰的而且很難再完善的。然而，當咱們還沒看到足夠多的系統運行足夠長時間時，咱們不能確定微服務構架是成熟的。

固然，還有緣由就是，有人指望微服務構架不夠成熟。在組件化方面的任何努力，其成功都依賴於軟件如何拆分紅適合的組件。指出組件化的準確邊界應該在那，這是很是困難的。改良設計要認可邊界的權益困境和所以帶來的易於重構的重要性。可是當你的組件是被遠程通訊的服務時，重構比進程內的庫又要困難的多。服務邊界上的代碼遷移是困難的，任務接口的變動須要參與者的共同協做，向後兼容的層次須要被增長，測試也變動更加複雜。

另外一個問題在於，若是組件並無清晰的劃分，你的工做的複雜性將從組件內部轉向組件間的關係。作這事不只要圍繞着複雜，它也要面對着不清晰和更難控制的地方。很容易想到，當你在一個小的、簡單的組件內找東西，總比在沒有關係的混亂的服務間要容易。

最後，團隊技能也是重要的因素。新的技術傾向於被掌握更多的技能的團隊使用。可是掌握多技能的團隊中使用的技巧在較少技能的團隊中並非必需的。咱們發現大量的少技能的團隊構建混亂的整合構架，可是它要發時間去證實使用微服務在這種狀況下會發生什麼。一個糟糕的團隊一般開發糟糕的系統：很難說，微服務在這種狀況下是否能幫助它們，仍是破壞它們。

一個理性的爭議在於，咱們據說，你不該該從微服務構架開始作。最好從總體構架開發，作模塊化開發，而後當總體構架出現問題是再把模塊化拆分紅服務。（儘管這種建議不是好主意，由於一個好的進程內接口並非一個好的服務接口。）

所以咱們持這種謹慎的樂觀。到目前爲止，咱們尚未足夠認識，關於微構架可否被大範圍的推廣。咱們不能確定的說，咱們要終結什麼，可是軟件開發的挑戰在於你只能在不完整的信息中決定你目前要處理的問題。

3其餘

微服務系統多大？

儘管「微服務」一詞在架構風格中愈來愈流行，它的名字很不辛讓人關注它的服務大小，以及對「微」這個組成的爭議。在咱們與微服務實踐者的談話中，咱們發現了服務的大小範圍。被報道的最大團隊遵循亞馬遜Tow Pizaa團隊理念（好比，一個團隊吃兩個比薩就能夠了。），這意味着不超過20號（一打）人。咱們發現最小配置是半打的團隊支撐起一打的服務。

這也引起這樣的考慮：規模爲一個服務一打人到一個服務一我的的團隊打上微服務的標籤。此刻咱們認爲，它們是同樣的，可是隨着對這種風格的深刻研究，也存在咱們改變咱們的想法的可能。

微服務與SOA

當前咱們談到微服務時，一般會問，這是否是咱們20年前討論的面向服務架構（SOA）。這是一個很好的觀點，由於微服務風格也SOA所提倡的一些優點很是類似。儘管如此，問題在於SOA意味的太多不一樣的東西了，所以一般時候咱們談的所謂「SOA」時，它與咱們談論的風格不一至，由於它一般是指在總體風格應用中的ESB。

此外，咱們發現面向服務的風格是這麼的拙劣：從試圖使用ESB隱藏複雜性，到使用多年才認識到發費數百美圓卻沒產生任務價值這樣的失敗，到集中治理模式抑制變動。並且這些問題每每很難發現。

能夠確定的時，微服務社區中使用的許多的技術都開發者是從大型機構的整合服務經驗中發展來的。Tolerant Reader模式就是這樣的一個例子。因爲互聯網的發展，利用簡單的協議這種方法，讓它從這些經驗傳達的出來。這是從已經很複雜的集中式標準中的一種反模式，坦白的說，真讓人驚歎。（不管什麼時候，當你須要用一個服務來管理你的全部的服務，你就知道這很麻煩。）

SOA的這種常見行爲讓微服務的提倡者拒絕打上SOA的標籤，儘管有人認爲微服務是從SOA中發展而來的，或許面向服務是對的。不管如何，事實上SOA表達這麼多的含義，它給一個團隊清醒的認識到這種構架風格就已經值的了。

多語言，多選擇

JVM作爲一個平臺，它的增加就是一個平臺中運行多語言的最大的例子。過去二十年中，它一般作爲更高層次語言的殼，以達到更高層次的抽象。好比，研究它的內部結構，、使用低級的語言寫更高效的代碼。儘管如此，許多總體風格並不須要這種層次的性能優化或者在語法及高層次上的抽象，這很常見（讓咱們很失望）。此外總體構架一般意味着使用單一的語言，這也限制着使用技術的數量。

實踐標準和強制標準

它有點尷尬，微服務團隊傾向於避免這種一般由企業架構隊伍定製的僵硬的強制標準，可是它們卻很是樂於甚至推廣這些開放的標準，如HTTP、ATOM、其它微規範。

關鍵的不一樣在這些標準是怎麼開發出來的，以及它們是怎麼被推廣的。標準被一些組件管理，如IETF認證標準，僅當它們在互聯網上有幾個在用的實現，一般源自於開源工程的成功應用。

這些標準單獨分離出來，與那種在企業中一般有沒有什麼編碼經驗的或者沒有什麼影響力的廠商標準進行區別。

讓作對事更容易

一方面，咱們發如今持續發佈、部署愈來愈多的使用自動化，是不少有用的工具開發出來幫助開發者和運營商的努力結果。爲打包、代碼管理、支撐服務的工具，或者增長標準監控的記錄的工具，如今都很是常見了。網絡中最好的，可能就是Netflix’s的開源工具，可是包含Dropwizard在內的其它工具也被普遍的使用着。

斷路器(circuit breaker)和產品中現有的代碼

斷路器(circuit breaker)出如今《Realease It!》一書中，與Bulkhead和Timeout這樣的模式放在一塊兒。實施起來，這些模式用於構建通訊應用時至關的重要。Netflix的博客在解釋它們的應用時，作了大量的工做。

同步是有害的

任務時候，你在服務間的調用使用同步的方法，都會遇到宕機時間的乘積效應。簡單的說，你的系統宕機時間是你係統的單獨組件的宕機時間的乘積。你面臨的選擇使用異步或者管理宕機時間。在www.guardian.co.uk中，它們在新平臺中使用一種簡單的規則來實現它：在Netflix中每次用戶請求的同步調用，他們從新設計的平臺API都會把它構建成異步的API來執行。