微服務是當前比較流行的一種應用開發形式，吸引了不少開發者的關注。前文我們講了微服務與SOA之與其重用不如抓住敏捷性，本文將繼續講解微服務對SOA的影響。

細粒度的可擴展性

在傳統的軟件開發周期中，開發一直關注的重點是以整體方在單一的應用服務器上編寫應用。這就是Java的工藝所在，應用服務器將下載大量的組件，并把它們像Spring框架一樣使用。“問題是隨著應用的擴展，不同的應用部署將消耗不同數量的內存或CPU，” Anuff說。

微服務哲學還給企業提供了框架，用于思考如何拆分應用，以一種可擴展成不同部分的應用形式。其中一個較好的方法是把應用拆分成獨立的容器，使用內部應用相互通信，而不是使用傳統的SOA進行內部應用通信，Anuff說。

有了微服務，電腦的最小單元就是最小的Docker容器，10行的node.js代碼。

這使得實現如產品查詢這樣的服務成為可能，這在特定用戶界面的數據庫中可查詢三個表，以一種容器化的方式。這一簡單的服務可以單獨擴展，不必拆分應用的其它部分，這可能會產生報告。

改進SOA遺留部分

微服務原則與敏捷軟件開發緊密相連，也許是SOA原則的進化，為傳統企業服務總線瘦了身。Haddad指出，微服務方法一個限制是，這一服務需要在原子孤島中實施，這他們就可以獨立地操作。“這一概念很有可會扭轉企業架構師的大抱負，轉變興趣為在性能和跨領域的觀點上，并高效地模型化，”他說。

問題在于，對于工作成立已久的企業中的企業架構師來說，他們需要與大量的現成的(COTS)應用打交道，這些應用通常規模很大，很完整。來自于微服務方法的架構如何能修正在架構和高性能應用上的投資，識別出這一點是一個挑戰。

例如，企業COTS應用抑制了微服務方法，因為它捆綁在多個業務功能中。“在時間卡和工資或訂單和發票之間，你并沒有獨立的堆棧。有的只是一個完整的應用程序，” Haddad說。

雖然這種方法有可能為訂單和發票提取出兩個獨立的微服務，但這種方法也限制了微服務范式的實現。問題是訂單和發票不能獨立擴展，因為他們指向了同一個后端應用。“整個微服務的前提是運轉多個后端服務，并分離出不同服務實體之間的解決方案堆棧，這樣當他們失敗時，也不會影響到對方，另外他們還可以各自擴展，” Haddad說。

最后，微服務并不是什么新東西，只是比SOA好點。據Genender說，“幾年來，我們一直構建微服務作為ESB或SOA終端。微服務SOA后端的新術語。由于實現的不好，SOA和ESB對他們也就沒有什么好意義， 術語的企業宣傳和濫用意味著太多不同的東西。”