无论您将微服务架构的关注放在侧重点的改变还是方式的改变，其工作原理都对提升系统存在潜在的影响。

我们之所以能够知道“微服务”这个词，要感谢2014年3月Martin Fowler所写的一篇文章。文章中他提到：“该微服务的架构特点是要开发一种独立的应用作为一套微小服务。各自运行在自己独立的进程中，并与其它轻量级装置进行沟通，通常是HTTP型API。这些服务都是建立在业务能力的基础上，并以全自动化开发设备作为保障独立运行。”

起初，此时的微服务与几年前SOA专家所提倡的服务并无多大差异。上述陈述的确属实，2000年代中期SOA所呈现的效益也是事实，但是遗憾的是，未能按照Thomas Erl的定向服务原则或者微服务架构支持原则进行设计。这些曾经的努力和付出换来的更多的是新型的技术（例如SOAP集成接口或者企业服务总线）而非服务。Fowler在定义时试图全面地描述出SOA成功的案例，例如Amazon Web Services和Netflix。因此，我们不妨分开来看看。

首先，我们先单独谈谈微服务。它可以在“自己的程序”中运行，并通过“轻量级设备与HTTP型API进行沟通”。关键在于该服务可以在自己的程序中运行。通过这一点我们就可以将服务公开与微服务架构（在现有系统中分布一个API）区分开来。在服务公开中，许多服务都可以被内部独立进程所限制。如果其中任何一个服务需要增加某种功能，那么就必须缩小进程范围。在微服务架构中，只需要在特定的某种服务中增加所需功能，而不影响整体进程。

微服务不需要像普通服务那样成为一种独立的功能或者独立的资源。定义中称，微服务是需要与业务能力相匹配，这种说法完全正确。不幸的是，仍然意味着，如果能力模型粒度的设计是错误的，那么，我们就必须付出很多代价。如果你阅读了Fowler的整篇文章，你会发现，其中的指导建议是非常实用的。在决定将所有组件组合到一起时，开发人员需要非常确信这些组件都会有所改变，并且规模也会发生变化。服务粒度越粗，就越难以符合规定原则。服务粒度越细，就越能够灵活地降低变化和负载所带来的影响。然而，利弊之间的权衡过程是非常复杂的，我们要在配置和资金模型的基础上考虑到基础设施的成本问题。

在许多企业中，其成本单位仍然是以CPU核心为基础，至少要有2-3个高可用性方案。一天能够收到100个请求的服务必须具备同等数量的基础设施，从而能够应付得了每天100,000个服务请求。较为难处理的是，要想获得细粒度的服务就意味着要添加更多的移动组件。这就是为什么定义中会提到“部署全自动化开发设备”的一大原因。如果不能实现全自动化，那么，后期增加的移动部件就会削弱人工流程。

关于上述定义，我想说的最后一点就是所使用的“开发方法”。该方法不仅仅是在所谓的“服务”中简简单单地创建Visio图标就可以了。成功的案例必须与决策、开发、部署以及服务的整个生命周期紧密相连。你必须将这些服务视为非常重要的产品而不是简单的项目。很多，但并非全部IT部门仅仅成为执行项目的发动机，对“产品”生命周期并没有任何概念。

站在产品的角度来思考，你会更长远的看。你会想出更有效的服务设计方法，那就是良方法，从而避免对现有消费者造成影响。此外，这种基于产品的设计方法也会改变其所有权。Fowler指出，过去，开发方式所有权是归技术或者传统方所有（例如，UI团队、服务团队以及数据团队）。如今，以产品为基础的设计思想与业务能力紧密相关，强调自上向下的所有关系，这就意味着，在需要的时候，你可以使用各种不同的技术。

在文章的结尾部分Fowler提到，只有时间可以证明微服务是否能继续下去。但是有了这种进化的设计精神，微服务就会成为SOA演化的一部分。无论你认为微服务是在侧重点上有所变化还是在方法上所有变化，其所呈现出来的设计原则都会对系统改善有所影响。