微服務優勢:

每一個服務都很easy，僅僅關注於一個業務功能。
每一個微服務能夠由不同的團隊獨立開發。
微服務是鬆散耦合的。
微服務能夠通過不同的程式語言與工具進行開發。

微服務劣勢:

運維成本過高
故障恢復後，20個服務可能要佔領40——60個程序，同一時候彈性問題也浮現出來了。在加入了負載均衡與訊息中介軟體後，程序的數量還會持續新增。運維與編排全部這些服務是個“令人望而卻步的任務”，Wootton說到：

實現全部這些需求須要高質量的監控與運維基礎設施。保持一臺應用server的持續執行就須要專人來負責，但如今我們還得確保幾十、甚至是幾百個程序都處於執行狀態、不能將磁碟空間耗盡、不能出現死鎖，還要保證效能。這真是一個很棘手的任務。
運維的過程須要自己主動化，只是由於“並沒有多少框架和開源工具能夠對此提供支援”，結果就是“使用微服務的團隊要在他們編寫具有業務價值的第一行程式碼前須要大量使用自己定義指令碼或是進行開發以管理這些程序”。

DevOps是必須的
Wootton覺得實現微服務的組織須要DevOps，這是由於：
你不能簡單地將通過這樣的風格構建的應用拋給運維團隊。開發團隊須要很關注運維與產品，由於基於微服務的應用與其環境上下文是很緊密地整合到了一起的。
由於許多服務可能都須要自己的資料儲存，因此開發人員還須要“搞清楚怎樣部署、執行、優化以及支援各種NoSQL產品”。

介面不匹配

服務依賴於彼此間的介面進行通訊。改變一個服務的介面會對其它服務造成影響，Wootton談到：
改動了契約一方的語法或是語義，那麼全部其它服務都須要理解這個改變。在微服務環境下，這意味著簡單的交叉改變會導致許多不同的元件發生變化，這些元件須要以一種協調一致的方式進行公佈。
當然了，我們能夠通過向後相容的方式避免這些變化的發生，只是實際情況卻是業務驅動的需求讓我們沒法實現分階段的公佈。
假設彼此協同的服務向前推進而且不再同步了，比方說使用canary公佈方式，那麼改動訊息格式的效果就難以可視化了。

程式碼反覆
為了避免將“同步耦合引入到系統中”，Wootton覺得有時須要向不同服務加入一些程式碼，這就會導致程式碼反覆，而程式碼反覆“是很不好的，由於每一個程式碼例項都須要進行測試和維護”。一種解決方式是在服務間使用共享庫，只是“在多語言環境下這即可不通了，而且引入了耦合就意味著服務須要並行公佈來維護彼此間的隱式介面”。

分散式系統的複雜性
作為一種分散式系統，微服務引入了複雜性和其它若干問題，比方說“網路延遲、容錯性、訊息序列化、不可靠的網路、非同步、版本號化、應用層中的負載變化等等”。

非同步
Wootton覺得微服務經常會使用非同步程式設計、訊息與並行，假設要求某個操作必須是同步且具有事務的，那麼這就很複雜了，這要求我們得“管理好相關聯的ID以及分散式事務，將各種動作繫結在一起”。

測試
使用微服務架構時，測試是還有一個須要考慮的問題，由於“不管是手工測試還是自己主動化測試，我們都很難以一致的方式重現環境”，Wootton說到：
當加入了非同步與動態訊息負載後，要測試以這樣的風格構建的系統就難上加難了，同一時候也無法對將要公佈到生產的各種服務抱有信心。
我們能夠測試每一個服務，只是在這樣的動態環境下，很微妙的行為都會從服務間的互動中產生出來，這是難以做到視覺化的，也不易想清楚，更不必說全面的測試了。