微服务是当前比较流行的一种应用开发形式，吸引了不少开发者的关注。前文我们讲了微服务与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对他们也就没有什么好意义， 术语的企业宣传和滥用意味着太多不同的东西。”