三年前，Arnon Rotem-Gal-Oz探讨了在当时看来还比较新颖的话题微服务以及它们与SOA的关系，并提出了有关Nanoservices的问题。在近日发表的一篇文章中，Arnon仍然认为，微服务可能不是某些人所认为的灵丹妙药，它可能是一种营销活动：

\u0026#xD;\u0026#xD;

\u0026#xD;

在我看来，能说明有关微服务的整个宣传是一种顾问式营销活动的其中一个证据是，一个东西要么是微服务，要么是单体，好像没有东西是介于两者之间。另一方面，现如今，似乎所有通过一个端点交付并运行在自己进程中的一切都被称为微服务。

\u0026#xD;

\u0026#xD;\u0026#xD;

也许他说的有点道理，但显然，其他人看到的是一系列的方法，而不是这种二元划分。例如，Gartner等就在谈论“迷你服务（Miniservices）”，其定义如下：

\u0026#xD;\u0026#xD;

\u0026#xD;

迷你服务是真正的SOA（不像微服务），可以包含许多微服务。它位于微服务之上，是服务的一种“外延方法（external approach）”，而微服务关注的是“内在尺度（internal scale）”，从根本上改善外部功能。

\u0026#xD;

\u0026#xD;\u0026#xD;

当然，还有其他类似迷你服务的概念，如所谓的Microlith。让我们回到Arnon的观点，他担心的是那个推断，即如果你开发的不是一个微服务，那么你的服务就会存在某种程度的缺陷或者是一个单体：

\u0026#xD;\u0026#xD;

\u0026#xD;

[...]如果每个独立部署的组件都是一个微服务，并且需要具备微服务的所有特性，那么生活真得就太复杂了。这些特性、隔离\u0026amp;自治需要付出艰苦的工作来避免API耦合、事务耦合、时空耦合、内部结构耦合，等等。不过，我们现在的情况是，什么都叫微服务，即使它不完全符合微服务的原则。

\u0026#xD;

\u0026#xD;\u0026#xD;

对于他的文章，其中有一位评论者指出，我们过去也曾多次报道过，REST存在同样的情况：

\u0026#xD;\u0026#xD;

\u0026#xD;

术语微服务和REST一样失去了原来的意义。（几乎）每个通过http使用json的API现在都被称为REST，同样地，几乎每个服务都被称为微服务。

\u0026#xD;

\u0026#xD;\u0026#xD;

Arnon认为，服务的这种二元方法（要么是好的微服务，要么是不怎么好的服务）是反生产力的：

\u0026#xD;\u0026#xD;

\u0026#xD;

最好是承认，服务就是这些围绕业务能力构建的东西，是通过端点提供并受外部策略限制的自治性API（或契约），诸如此类。另一方面，我们又需要将服务分解成更小的半独立组件，它们遵循大部分原则，并且具有独立部署、开发周期这样的优点，但仍然可以共享部分依赖，尤其是数据结构和存储。我将它们称为半独立组件“方面（aspects）”。

\u0026#xD;

\u0026#xD;\u0026#xD;

他继续写道，区分方面和服务可以确保不同服务的不同方面仍然保持服务边界。将服务拆分成方面有助于保持服务的灵活性和简单性，因为随着服务规模和复杂性的提升，它们可能会背离微服务当前的定义。Arnon举了一些真实世界的例子，那是他参与研发的一个系统，其中有些服务比较小（Arnon并没有给出“小”的定义，也许是根据代码行数），只有一个方面。不过，他们也有包含多个方面的更复杂的服务：

\u0026#xD;\u0026#xD;

\u0026#xD;

一个方面负责将事件数据接收到服务，执行转换和“数据梳理（data munching ）”（构建新数据和现有数据的关系图），另一个方面负责处理用户修改数据，而第三个方面提供了一个查询API（通过graphQL），用于访问那份数据。每个方面都有自己的生命周期，每个方面都是独立部署的，这些方面使用了多种语言（Scala和JavaScript），但是，一方面它们会共享数据，另一方面他们会保持和其它服务设定的界限。

\u0026#xD;

\u0026#xD;\u0026#xD;

按此情形，这些方面听上去很像微服务，即使它们是一起部署并作为一个相关单元来运营，但不管怎么样，微服务不会孤立存在。也许，整体的架构方法和Martin Fowler等人以前探讨的Strangler模式类似。Arnon总结道：

\u0026#xD;\u0026#xD;

\u0026#xD;

控制耦合水平并保持服务界限很重要。理解什么是方面，什么是服务，有助于控制整体架构，确保它不会成为一个错综复杂的相互依赖网络，并通过使用较小的组件提高灵活性，缩短周转时间。

\u0026#xD;

\u0026#xD;\u0026#xD;

虽然名称不同，但不管“方面”是不是实际上的“微服务”，至少有另外一个人（Udi Dahan）也得出了类似的结论，虽然他对这些软件组件的叫法有点不同：

\u0026#xD;\u0026#xD;

\u0026#xD;

我一直使用术语自治组件（AC）来描述包含一个服务的软件程序包，它可能会部署为一个单独的端点，也许会和其它AC托管在一起。在构建复合UI时，这种共同托管模型最有用。

\u0026#xD;

\u0026#xD;\u0026#xD;

在Udi的定义中，自治是指它们不依赖于其它AC，关于这一点，他在多年之前讨论SOA时就做过说明。幸好，几年之后，Udi又写了更多关于AC和微服务的内容，他写道：

\u0026#xD;\u0026#xD;

\u0026#xD;

微服务差不多可以和自治组件同样看待。为什么是“差不多”？因为自治组件（AC）不一定是一个物理部署单元，经常，我们会看到多个AC在同一个物理进程中部署。其中一个最常见的情况是，在Web前端作为一个复合UI构建。在同一个Web服务器进程中，我们会看到来自多个服务的组件。

\u0026#xD;

\u0026#xD;\u0026#xD;

方面/自治组件和微服务之间的差别似乎是单体架构和纯粹的微服务架构之间一个有益的过渡，然而，由于微服务没有一个标准的定义，所以这些组件本身也被说成了微服务。也许其他人已经这样做了，但并没有像我们这样明确地说出来。

\u0026#xD;\u0026#xD;

查看英文原文：Aspects and Services - an Important Distinction?