垃圾簡書，垃圾CEO，垃圾某豚，從此絕不再用。

本文是翻譯 https://martinfowler.com/articles/microservices.html 的內容，旨在介紹一下微服務這種設計架構，希望大家盡量閱讀原文。文中翻譯難免有疏漏，希望大家不吝指正，共同學習。

————————————————————————————————————

微服務架構的定義

“微服務架構”(Microservice Architecture)一詞在過去的幾年間涌現出來，作為一套可以獨立部署的服務，用來描述一種特殊的設計軟件應用的方式。雖然沒有這個架構風格沒有明確的定義，但圍繞業務功能的組織，自動部署（automated deployment），端智能(intelligence in the endpoints,)以及對語言和數據的分散控制存在某些共同的特征。

“微服務”，又一個出現在眾多軟件架構術語中的新詞。雖然我們主觀傾向于對這樣的概念不屑一顧， 但這個詞描述了一種讓我們覺得越來越有吸引力的軟件系統風格。我們已經看到在過去的幾年間有多個項目使用這種風格，到目前為止，結果都是樂觀的。以至于這已經逐漸成為了我們很多同事在構建企業級應用的默認方式。然而，遺憾的是，并沒有太多的信息去概述什么是微服務以及如何去做。

簡而言之，微服務架構風格就是將單一應用的開發分為多個小的服務，每個小的服務在自己的進程中運行并使用輕量級機制進行通信（通常是一個HTTP? API源），這些服務圍繞業務性能進行構建，并且通過完全自動化的部署機制獨立的部署。這些只需要最低限度的集中管理的服務，可以使用不同的編程語言編寫，以及使用不同的數據存儲技術。

為了闡述微服務架構，有必要讓其與Monolithic架構進行比較：一個Monolithic應用由一個單元構建。企業級應用通常由三部分構建：客戶端界面（包括HTML頁面和運行在客戶機器上瀏覽器里的javascript腳本），數據庫（許多表構成的、相互關聯的關系型數據庫管理系統）以及一個服務器端應用。服務器端應用處理HTTP請求，執行域邏輯（domian logic），從數據庫中查詢和更新數據，選擇并填充將要發送到瀏覽器的視圖。這個服務器端程度就是一個Monolithic - 單一的邏輯上可執行的應用。對這個系統的任何更改都會構建和部署一個服務器端應用的新版本。

Monolithic架構是構建這樣一種系統很自然的方式。處理請求的邏輯都在一個單一的進程中，允許你使用編程語言的基本特性將應用分割為類，函數以及命名空間。在某些場景中，你可以在開發人員的計算機運行和測試應用，并使用部署管道來確保對更改進行正確的測試以及部署到生產環境中。你也可以橫向擴展Monolithic應用，通過負載均衡將多個應用部署到多個服務器上。

Monolithic架構能夠成功 ， 但是越來越多的對其感到失望， 特別是越來越多的應用被部署到cloud中。變更周期被綁定了，對應用一個小的更改，將會重新構建者部署整個項目。隨著時間的推移，通常很難保持一個良好的模塊化結構，這使得更改時只影響應用的一個小模塊變得更加困難，擴展時需要擴展整個應用，而不只是進行部分部署。

Monolithic架構的這些缺陷導致了Microservices架構的出現：通過一系列的服務去構建應用。服務除了可以獨立部署和可擴展之外，每個服務還有固定的模塊邊界，甚至允許使用不同的語言去編寫不同的服務。它們也能被不同的團隊進行管理。

我們并不主張說Microservices架構是多么新的東西，它至少可以追溯到Unix設計規范之前。但是我們確實認為沒有足夠的人去考慮Microservices架構，如果他們使用Microservices架構，很多軟件系統將會變得更好。

微服務架構的特征

我們不能說微服務架構有一個正式的定義，但我們可以去嘗試描述與“微服務”這個標簽相匹配的體系架構的共同特征。正如用一個定義概括任何其他具有共同特征的事物一樣，并非所有的微服務架構具有這些所有的特征，但我們確實希望所有的微服務架構具有大多數的這些特征。

盡管筆者們已經是這個相當松散的社區的積極成員，我們的意圖是嘗試去描述在我們自己的工作中所發現的，以及我們所知道的其他團隊類似的努力。特別是我們沒有下明確的定義遵守這個架構的時候。

——————————————————————————————————————

組件化（Componentization） 與服務 (Service)

自從我們開創軟件行業以來，就會一直希望將組件連接在一起的方式去構建系統，就像我們在物理世界中所看見的一樣。在過去的幾十年中，我們看見了大量簡編的公共庫取得的巨大進步，它們是大多數語言平臺的一部分。

在談論組件時，我們遇到了定義上的難題即什么構成了組件。我們的定義是，組件是一個獨立的，可替換的和可升級的軟件單元 。

微服務架構會使用庫，但是其組件化自身軟件的主要方式是將其拆分為服務。我們將庫定義為連接到程序中的組件，并使用內存中的函數進行調用，而服務則是進程外的組件，這些組件通過webservice請求或者遠程過程調用（RPC）等機制進行通信。（組件和服務在很多面向對象編程中是不同的概念）

使用服務作為組件（而不是庫）的主要原因是服務是可以獨立部署的。如果你的應用由單個進程中的多個庫組成，則對單個組件的任何更改都將導致不得不重新部署整個應用。但是，如果將應用分解為多個服務，你可以期望單個服務的更改只需要重新部署該單個服務即可。當然，這也不是絕對的，一些更改將改變服務接口，從而會產生一些協調。但是優秀的微服務架構的目的是通過服務契約中的解耦服務邊界和進化機制將這些更改最小化 。

使用服務作為組件的另一個結果是更顯式的組件接口。 大多數語言都沒有良好的機制來定義顯式的發布接口。通常只有文檔化和規則才能防止用戶破壞組件的封裝，從而避免組件之間的緊密耦合。通過使用顯式的遠程調用機制，服務可以更容易的避免這種這種情況。

使用這樣的服務確實有缺陷。遠程調用比在進程內調用更消耗資源，由于遠程API需要粗粒度的，這通常更難于使用。如果你需要更改服務之間的職責分配，那么當你跨越進程邊界時，這種行為方式將會變得更加困難。

在第一種類似情況中，我們注意到服務映射到運行時進程，但這只是第一種類似情況。服務可以由多個進程組成，這些進程將始終被開發和部署在一起，例如應用程序進程和僅由該服務使用的數據庫 。

——————————————————————————————————————

圍繞業務功能組織

當將一個大型應用分為多個部分時，通常管理會集中在技術層面，UI團隊，服務端團隊和數據庫團隊。當團隊沿著這條線分開時，即使是簡單的變更也會導致跨團隊間的項目時間和預算審批的花費。一個聰明的團隊會優化這個問題-兩害相權取其輕-只需將邏輯置于它們想要訪問的應用中。換句話說，邏輯無處不在。這是Conway定律得一個例子。

微服務的劃分方法是不同的，它傾向于圍繞業務功能的組織來分割服務。此類服務對該業務領域進行了廣泛的軟件實現，包括用戶界面、持久化存儲和任何的外部協作。因此，團隊是跨職能的，包括開發過程所需的全部技能：用戶體驗、數據庫和項目管理。

有一個以這樣的方式進行組織的公司 ：www.comparethemarket.com ?？绻δ軋F隊負責構建和執行每個產品，并將每個產品分割成多個單獨的服務，通過消息總線進行通信。

大型的Monolithic應用也可以圍繞業務功能進行模塊化，盡管這不是常見的情況。 當然，我們會敦促一個構建Monolithi應用的大型團隊，以便將其沿著業務線進行劃分。

我們在這里看到的主要問題是，這種組件形式會導致太多的依賴。如果Monolithic跨越了許多模塊化的邊界，那么團體的個體成員很難將其融入到他們的短期記憶中。此外，我們還發現，模塊化需要大量的規則來執行。服務組件要求的分割越明確，使得保持團隊之間的界限變得越容易。

——————————————————————————————————————

微服務有多大？

盡管“微服務”已經成為了這種架構風格的流行名稱，但是它的名字確實導致了對服務規模的不幸關注，以及關于什么構成“微”的爭論。在我們與微服務實踐者的交流中，我們看到了一系列服務的大小。 據報道，

最大的規模遵循了亞馬遜“Two Pizza Team”的概念（即整個團隊兩個比薩就夠了），也就是不超過12個人。在規模較小的團隊里，我們看到的是小規模的團隊提供小規模的服務這種配置。

這樣就引出了一個問題：在這個范圍內是否存在足夠大的差異，即每個成員的服務和每個團隊的服務的大小不應該被歸入一個微服務標簽。目前，我們認為最好將它們組合在一起，但當我們進一步探索這種架構風格時 ，我們當然有可能改變我們的想法。

——————————————————————————————————————

產品不是項目

我們看到的大多數應用開發工作都使用了一個項目模型：目的是為了交付一些軟件，然后就被認為是完成了。軟件完成后被移交給維護部門，構建軟件的項目組解散。

微服務的支持者們傾向于避免這種模式，他們更傾向于一個團隊應該負責產品的整個生命周期。這是一個共同的靈感，是亞馬遜“你構建，你運維”的概念，一個開發團隊對軟件的開發承擔全部的責任。

這使得開發人員每天接觸到他們的軟件在開發過程中的行為，并增加與用戶的聯系，因為他們至少要承擔一些售后支持負擔。

產品的理念，與業務功能聯系在一起。并不只是將軟件看成一組要完成的功能，還有一個持續性的問題，即軟件如何幫助用戶提高其業務能力。

我們并沒有理由不能使用Monolithic應用，但是服務的粒度越小，就越容易在服務提供者和用戶之間建立緊密關系。

——————————————————————————————————————

強化終端及弱化通道（Smart endPoints and dumb pipes）

在構建不同進程間的通信結構時，我們發現很多產品和方法能夠更加有效的將其自身加入到通信機制中。其中一個很好的例子是企業服務總線(ESB)，ESB產品通常包括用于消息路由，編排，轉換和應用業務規則。

微服務社區支持的另一種方法：強化終端及弱化通道 。從微服務中構建的應用的目標是盡可能的解耦和盡可能的內聚-它們擁有自己的域邏輯，就像在經典的Unix意義上的過濾器-接收請求，適當的應用邏輯并生成響應。這些都是使用簡單的RESTish協議編排的，而不是像WS-Choreorgaphy或BPE或者由集中式框架編制的復雜協議，最常見的兩種協議是攜帶資源的HTTP請求-響應以及輕量級的消息傳遞。

——————————————————————————————————————

微服務和SOA

當我們討論微服務時，一個常見的問題是：這是否僅僅就是我們10年前看到的面向服務的架構（SOA）。這一點是有價值的，因為微服務的風格非常類似于SOA的一些支持者所倡導的。然而，問題是SOA意味著太多不同的東西，而且大多數時候我們遇到的東西被成為“SOA”，它與我們在這里描述的風格有很大的不同，通常是因為ESB用于集成Monolithic應用。

特別是我們已經看到了許多面向服務的拙劣實現-從ESB中隱藏復雜性的傾向-到那些花費數百萬美元但并無交付價值，到積極抑制改變的集中管理模式，有時很難看到過去的這些問題。

當然，在微服務中使用的許多技術都是從在大型組織中集成服務的開發人員的經驗中成長起來的。Tolerant Reader模式就是一個例子。使用web的努力已經做出了貢獻，使用簡單的協議是從這些經驗中獲得的另一種方法 - 從那些已經達到復雜性的中心標準，坦率的說，是驚人的。（任何時候，你需要一個本體來管理你的本體，你知道你身陷困境）。

SOA的這一常見表現致使一些微服務的擁護者完全拒絕SOA，盡管其他人認為微服務是SOA的一種形式，或許面向服務是正確的。無論怎樣，SOA都意味著不同的東西，這意味著又一個更清晰的定義這個架構風格的術語是很有價值的。

微服務團隊使用萬維網（很大程度上是Unix）構建的原則和協議。經常使用的資源可以通過開發人員或者操作人員很少的努力來緩存。

第二種方式是在輕量級消息總線上進行消息傳遞。這種通信協議非常單一（單一到只負責消息路由）- 簡單的實現比如 RabitMQ 和ZeroMQ甚至沒有提供可靠的異步機制，以至于需要依賴產生或者消費信息的終端或者服務來處理這類問題。

在Monolith架構中，組件在進程中執行，它們之間的通信通過方法調用或者函數調用來進行。將Monolith架構轉換為微服務架構的最大問題在于改變通信模式。從內存調用到RPC的轉換會導致不好的信息通信。相反，你需要使用粗粒度的通信方式來代替細粒度的通信。

——————————————————————————————————————

去中心化管理

去中心化管理的結果之一是在單一的技術平臺上進行標準化的趨勢。經驗表明，這種方法是相對的-并不是所有的問題都是釘子，并不是每個解決方案都是錘子。我們更喜歡使用合適的工具來來完成工作，而Monolithic應用可以在一定程度上利用不同的語言，這并不常見。

將Monolithic的組件拆分為服務，我們可以在構建它們的時候有一個選擇。你想要使用Node.js來建立一個報表頁面？去吧！對于一個幾乎接近實時的組件使用C++ ? 很棒。你想要換一種不同的數據庫，以便更好的適應一個組件的讀取行為嗎？我們有重新構建它的技術。

當然，僅僅是因為你可以這樣做，并不意味著你應該這樣做-但是以這種方式劃分的系統意味著你有選擇。

構建微服務的團隊也喜歡用不同的方法來達到標準。與其將一組定義的標準寫在紙上，它們更傾向于使用其他開發人員可以使用的有用工具來解決他們面對的類似問題。這些工具通常從實現中獲取，并與更廣泛的團隊共享，但不完全使用內部的開源模型。現在，git和github已經成為了事實上的版本控制系統，開源實踐正變得越來越普遍。

Netflix是遵循這種理念的一個很好的例子。共享有用的，最重要的是，當代碼庫鼓勵其他開發人員以類似的方式解決類似的問題時，如果需要的話，還可以選擇不同的方法。共享庫往往集中在數據存儲、進程間通信等常見問題，以及我們在下面討論的基礎設施自動化。

對于微服務社區來說， 開銷問題是特別引人注意的 。 這并不意味著社區不重視服務 交互的價值。 恰恰相反，因為發現它們的價值。這使得它們在尋找各種方法解決它們。像 Tolerant Reader Pattern和Consumer_Driven Contracts Pattern 這樣的模式經常被應用到微服務中。這些模式解決了獨立服務在交互過程中的交互問題。作為構建的一部分，使用Consumer_Driven Contracts 增強了信心，并提供了關于服務是否運行的快速反饋。事實上，我們知道澳大利亞一個團隊，他們使用Consumer_Driven Contracts 來推動新服務的建立。它們使用簡單的工具來定義服務的接口。 在新服務的代碼編寫之前，就已經成為了自動化構建的一部分。然后，只需要指出這些接口的適用范圍，這是一種優雅的方法，可以避免在構建新軟件時出現"YAGNI"困境。這些技術和工具在使用過程中完善，通過減少服務之間的耦合來限制集中式 管理的需求。

也許去中心化最高點是亞馬遜推廣的 build it/ run it理念。團隊負責他們構建的軟件的所有方面，包括全天候的運營軟件。移交這一級別的責任肯定不是常態，但是我們確實看見越來越多的公司將責任推給開發團隊。Netflix是另一個采用這種理念的組織。每天晚上3點被你的尋呼機吵醒，毫無疑問是你在編寫代碼時專注質量的強大動力。這些想法與傳統的中心化管理模式相去甚遠，然而它是可能的。

——————————————————————————————————————

去中心化的數據管理

數據管理的去中心化有許多不同的方式。在最抽象的層次上，這意味著通用概念模型將在系統之間有所不同。在跨大型企業集成時，這是一個常見的問題，客戶的銷售視圖與支持視圖不同。在銷售視圖中，一些被稱為客戶的東西可能就根本沒有出現在支持視圖中。那些可能有不同的屬性和（更糟糕的）公共屬性，具有微妙的不同語義。

這個問題在應用之間很常見，但是也會發生在應用內，特別是應用被劃分為獨立的組件時。一種有用的思考方式是有界上下文（Bounded? Context）的領域驅動設計概念。領域驅動設計將一個復雜的域分割成多個有界的上下文，并映射出它們之間的關系。這個過程對Monolithic架構和微服務架構都很有用，但是在服務和上下文邊界之間存在自然的相關性，正如我們在業務功能所描述的那樣，強行進程拆分。

除了決定將概念模型去中心化，微服務還決定將數據存儲的去中心化。雖然Monolithic應用更喜歡單一邏輯的數據庫來持久化數據。但企業更喜歡跨多個應用的單一數據庫。許多決策也通過供應商的商業模式授權來驅動。微服務更喜歡讓每個服務管理自己的數據庫，或者同一數據庫技術的不同實例，又或者完全不同的數據庫系統 - 一種被稱為多持久化（Polyglot Persistence）的方法。你可以在Monolithic架構中使用多持久化的方法，但是它更頻繁的出現在微服務中。

在微服務中對數據去中心化對管理更新有影響。處理更新的常用方法是在更新多個資源時使用事務的一致性。這種方法常用于Monolithic架構。

使用這樣的事務有助于保持一致性，但是在跨多個服務中造成了嚴重的耦合問題。眾所周知，分布式事務很難實現，因為微服務架構強調服務之間的事務協調并明確一致性可能只是最終的一致性，而問題是通過補償操作來處理的。

選擇以這種方式來管理非一致性對許多開發團隊來說是一個全新的挑戰，但它常常與業務實踐相匹配。通常，企業會處理一定程度的非一致性，以快速響應需求，同時有一些逆轉過程來處理錯誤。只要糾正錯誤的成本低于在更大的一致性下損失的業務的成本，這種權衡就是值得的。

——————————————————————————————————————

基礎設施自動化

基礎設施自動化技術宅過去幾年中有了巨大的發展-特別是云和AWS的發展，降低了構建、部署和運維微服務的復雜性。

許多使用微服務構建的產品或者系統都是由具有廣泛持續部署（Continuous? Delivery）經驗的團隊構建的，這是一個持續集成（Continuous Integration）的先驅，以這種方式構建軟件的團隊廣泛使用基礎設施自動化技術。這在下面所示的構建管道中說明。

由于這不是一篇關于自動部署的文章，我們將會把注意力集中在這里的幾個關鍵特性上。我們希望我們的軟件應該這樣方便的工作，所以我們運行大量的自動化測試。

一個Monolithic應用通過這些環境會構建，測試和推動得非常愉快。事實證明，一旦你為Monolithic應用進入自動化的道路，然后部署更多的應用程序，看起來就不那么可怕了。請記住，CD（持續部署）的目標之一是使發布變得無趣，所以無論是它的一個或者多個應用，它都一樣的無趣。

我們看到團隊使用廣泛的基礎設施自動化的另一個領域是在生產中管理微服務。與我們上面斷定的不同的是，只要部署很無趣，Monolithic應用和微服務應用之間就沒有那么大的差別，每個操作環境都有明顯的不同。

——————————————————————————————————————

容錯性設計

使用服務作為組件的結果是，應用需要被設計，以便它們能夠忍受服務的故障。任何服務調用都可能由于供應商的無法使用而故障，客戶端必須盡可能的優雅的做出響應。與Monolithic架構相比，這是一個缺點，因為它引入了額外的復雜性。其結果是，微服務團隊不斷的想到服務失敗如何影響用戶體驗。Netfix的 Simian? Army 可以為每個應用的服務及數據中心提供日常故障監測和恢復。

這種自動化的生產測試足以讓大多數的運維團隊在一周的工作中能正常上下班。這并不是說Monolithic架構的應用不能進行復雜的監控， 只是在我們的經驗中并不常見。

由于服務在任何時候都可能故障，所以能夠進行快速檢測以及自動恢復 服務是很重要的（如果可能的話）。微服務應用非常重視對應用的實時監控，同時檢查架構元素（每秒請求數據庫的連接是多少）和業務相關的度量標準（例如：每秒鐘收到多少訂單）。語義監控可以提供一些異常的早期警報系統，從而觸發開發團隊的跟進和調查。

這對于微服務的架構尤其重要，因為微服務相互的通信會導致緊急行為。雖然許多專家稱贊偶發情況的價值，但事實是，緊急行為有時候是一件壞事。監測對于及時發現不良的緊急行為是至關重要的，以便能夠進行修復。

Monolithic應用可以被構建為像微服務一樣透明 - 事實上，它們應該像這樣。區別在于，你必須知道在不同的進程中運行的服務何時斷開。對于同一進程中的庫，此類透明度不太可能有用。

微服務團隊希望看到每個單獨服務的復雜監控和日志設置，如顯示 上/下狀態的儀表盤以及各種操作和業務相關的度量。關于斷路器狀態、當前吞吐量和延遲的詳細信息是我們經常遇到的其他例子。

——————————————————————————————————————

設計改進

微服務實踐者，通常來自于一個不斷改進設計的背景，他們將服務分解看作是進一步的工具，使應用的開發人員能夠在不減慢更改的情況下控制應用的更改。變更控制并不意味著更改的減少 - 使用正確的方式和工具，你可以對軟件進行頻繁、快速和可控的更改。

當你試圖將一個軟件系統分割為組件時，你將作出如何分割這些組件的決定 - 我們決定將應用分割的原則是什么 ？ 一個組件的關鍵屬性是獨立的、可替換的和可升級的概念，這意味著我們要尋找到一個點，可以在不影響其之前的協作的情況下而重寫組件。事實上，許多微服務組織都明確的希望，許多服務是能被取消的，而不是長期的發展下去。

《衛報》網站是一個應用很好的例子，它被設計為Monolithic架構，但是它在向著微服務的方向發展。Monolithic架構仍然是網站的核心，但是它們更喜歡通過使用Monolithic API的微服務來構建新的功能。這種方法對于那些本質上是臨時的特性特別有用，比如專門的頁面來處理體育賽事。網站的這一部分可以很快的和快速開發語言結合起來，一旦賽事結束，就可以刪除。我們在一家金融機構看到了類似的方法，在那里，新的服務會被加入到新的市場機遇中去，并在幾個月甚至幾周后拋棄。

這種可替換性的強調，是模塊化設計一般原則的一個特例，即通過改變的模式來驅動模塊化。你希望在同一模塊中同時保留更改的內容。一個系統的某些部分，幾乎不應該對那些正在經歷大量生產的系統提供不同的服務。如果你發現自己在不斷的在一起更改兩個服務，這表明它們應該被合并。

將組件放入服務中為更細粒度的發布計劃提供了機會。對于Monolithic應用，任何更改都需要整個應用的完整構建和部署。然而，對于微服務，你只需要重新部署你修改過的服務。這可以簡化并加速發布過程。缺點是，你不得不擔心對一個服務的更改會破壞它的使用者。傳統的集成方式是使用版本控制來解決這個問題，但是在微服務領域是只將版本控制作為最后的手段。我們可以通過設計服務來避免產生很多的版本，以盡可能的容忍供應商的變化。

————————————————————————————————————————————

微服務架構是未來嗎？

我們寫這篇文章的主要目的是解釋微服務的主要思想和原則。通過花時間來做這件事，我們清晰的認為，微服務架構是一個很重要的想法，它值得企業應用認真的考慮。我們最近建立了幾個使用這種風格的系統，并了解使用和支持這種方式的其他人。

我們所知道的那些在某種程度上開創了架構風格的人，包括亞馬遜、Netflix、《衛報》、英國政府數字服務公司、realestate.com.au、Forward和comparethemarket.com。在2013的會議上，有很多公司的例子，他們正在轉移一些可以使用微服務的東西，包括 Travis.CI。 此外，還有許多組織長期以來一直在做我們認為可以作為微服務的東西，當從來沒有使用過這個名稱。（通常這被稱為SOA - 盡管我們已經知道，SOA有許多相互矛盾的形式）

盡管有這些積極的經驗，但是我們并不確信微服務是軟件架構的未來方向。雖然到目前為止我們的經驗以Monolithic架構相比是積極的，但我們意識到，沒有足夠的時間讓我們做出全面的判斷。

通常，你的結構決策的真實結果在你完成后幾年才會顯現出來。我們已經看到了一些項目，一個好的團隊，對模塊化的強烈愿望，已經建立了一個Monolithic架構，多年來已經衰敗。很多人認為，這種衰敗不太可能發生在微服務架構上，因為服務的邊界是明確的，很難修補。然而，在我們看到足夠多的老系統之前，我們無法真正評估微服務架構是如何成熟的。

有一些原因可以解釋為什么人們會認為微服務很不成熟。在組件化的任何努力中，成功取決于軟件與組件的匹配程度。很難弄清組件邊界的確切位置。進化設計意識到正確的獲得邊界的困難，因此明白簡單重構的重要性。但是，當你的組件是遠程通信的服務時，重構比在進程內要困難得多。移動代碼很難跨越服務邊界，任何接口的更改都需要在參與者之間協調，需要添加層次的向后兼容性，并且測試更加復雜。

另一個問題時，如果組件不干凈，那么你做的事情就是將復雜性從組件內部轉移到組件之間的連接上。這不僅僅是將復雜性轉移到一個更不明確，更難以控制的地方。當你看到一個簡單的小組件內部時，很容易會認為事情會更好，同時還會忽略服務之間的混亂連接。

最后，還有團隊技能的因素。新技術往往被更熟練的團隊使用。但是對于一個更熟練來說，一個更有效的技術并不一定能為不太熟練的團隊工作。我們已經看到了許多不太熟練的團隊構建雜亂的Monolithic架構的案例，但是要知道這種情況發生在微服務上的時候會帶來什么。一個差勁的團隊總會創造一個糟糕的系統。- 很難判斷微服務是否能減少這種情況，或者使其變得更糟。

我們聽到的一個合理的觀點是，你不應該從一個微服務架構開始。相反的是，可以從一個Monolithic架構開始，一旦Monolithic架構成為一個問題，就使用模塊化，并將其分解為微服務。（盡管這個建議并不理想，因為良好的進程內接口通常不是一個好的服務接口）。

所以我們審慎樂觀的寫這篇文章。到目前為止，我們已經看到了足夠多的微服務風格，認為這是一條值得涉足的道路。我們不能確定我們最終會在哪里，但是軟件開發的一個挑戰是，你只能根據你目前掌握的不完全信息做出決定。