有人称流行语为警察：我们正在处理一个严重的微服务清洗案例。 “microservices-washing”一词来源于“whitewashing”，意思是用虚张声势和胡说八道来掩盖一些不便的真相。
几年前我们看到了大量的 云清洗 ，因为供应商和企业都假装他们在做的是云，尽管事实并非如此。今天，围绕微服务的炒作导致了同样的混淆，因为供应商和企业技术人员都在说他们正在构建微服务——尽管粗略地看一下他们真正在做什么并不会发现一个。
只有剥去微服务清洗的炒作，供应商和从业者才能从微服务中获得真正的价值。
如果不是微服务，那又是什么？
随着 Web 服务的兴起，服务作为公开软件功能的一种方式的概念在本世纪初形成了自己的概念。由于受够了 CORBA（通用对象请求代理架构）的不灵活和紧密耦合，供应商社区敲定了一套与 XML 相关的标准来实现抽象软件端点底层实现的软件接口。
在 微服务兴起之前， 其实服务的概念就是软件接口。供应商喜欢这个定义，因为它允许他们创建自己的专有执行环境以添加到他们的中间件产品中，并将它们重命名为企业服务总线 (ESB)。
相比之下，微服务是一个简约、内聚的执行单元。它本身绝对不是软件界面，尽管它显然有一个。相反，微服务的核心是运行代码本身。微服务还包含自己的运行时，因此它们不需要在 ESB 上运行。
这种区别触及微服务清洗流行病的核心，因为构建、运行和集成服务的含义完全不同，具体取决于您所指的服务是微服务还是 Web 服务。
供应商微服务-洗涤趋势
多年来，供应商一直在为服务故事而苦苦挣扎，因为围绕 Web 服务的所有讨论很快就转移到了面向服务的架构 (SOA)。尽管供应商在过去十年中为 SOA 消息传递投入了数百万美元，但一个简单的事实总是让他们感到困惑：SOA 是您 做的 事情，而不是您 购买的 东西。
今天我们看到了微服务架构的出现。它还没有完全成熟，但已经足够成熟，可以看出虽然它继承了 SOA 的一些基本原则，但它从根本上是一套不同的实践——因为整个环境已经完全转变。
SOA 的环境是 2000 年代的企业 IT：大量遗留的、重量级的中间件和在整个公司运行的各种应用程序。相比之下，微服务架构的环境是 无边界企业 ：利用完全虚拟化基础设施的端到端、以云为中心的数字应用程序。
对于现有供应商（即那些产品在 SOA 时代或更早时期成熟的软件公司）来说，这个新世界有望颠覆他们的整个产品线。为了生存，他们基本上必须重写所有软件。公平地说，他们中的许多人确实正在进行这样的改造。
然而，他们的营销人员不喜欢等待。他们现在想 跳上微服务的潮流 。也许他们的产品实际上有一些微服务，但谁知道呢？说你“准备好微服务”或“用微服务构建”与提供软件或基于软件的服务是完全不同的，后者是新的无边界数字现实的成熟参与者。
企业中的微服务洗涤
早在 2000 年代，您就在您的组织中实施了 SOA，但您仍然有许多生产 Web 服务可以解决您的问题。你应该把它们变成微服务吗？
可能不会。毕竟，如果您在生产中拥有的服务仍在工作并提供价值，那么您应该遵循的基本原则是， 如果它没有坏，就不要修理它 。相反，许多架构师团队正在做的是将这些遗留服务重命名为“企业服务”。
它们可能是 Web 服务，或者您可能在当天实现了 RESTful 服务。无论如何，如果您已经在生产中拥有主要目的是公开遗留应用程序功能或数据的服务，那么将它们重新工作为微服务不太可能值得麻烦。
话虽这么说，您可能首先想要更改这些企业服务的原因是它们没有充分满足当前的需求。当您分析问题时，您可能会发现问题归结为它们 太大了 。他们想做的太多了，因此没有做太多好事。由于微服务应该是简约的，也许它们只是门票。
没那么快。简约原则——微服务应该尽可能小但不能更小——适用于构成微服务的代码。但请记住，给您带来如此多麻烦的大型旧 Web 服务是软件界面。虽然它背后肯定有代码，但当我们说 Web 服务太大时，我们可能是指它有太多操作。
Web 服务有两种基本类型：实体服务和任务服务。实体服务表示业务实体类似于对象表示此类实体的方式，其中服务的操作表示您将对实体执行的操作。例如，您可能有一个客户实体服务，它的操作可能是 createNewCustomer 、 changeCustomerAddress 、 authorizeCustomer 等。您可能对客户做的事情越多，您拥有的操作就越多——有时数十个甚至数百个单个实体服务。
相反，任务服务表示单个任务。换句话说，他们只有一个操作，或者您甚至可以将整个服务视为操作。
每种类型的服务都有其优点和缺点。实体服务有更多的业务上下文，但它们不太灵活且难以组合。任务服务更容易组合和更新，但通常缺乏清晰的业务背景。
因为任务服务是简约的，所以它们类似于微服务。事实上，我们可以将微服务接口视为任务服务，但反之则不成立。仅仅因为服务是任务服务，并不意味着它是微服务。这就是微服务清洗的用武之地。
大多数企业服务实际上是实体服务。如果你有一个企业服务是一个实体服务，并且因为它太难更新而不能满足当前的需求，解决方案更有可能将它重新加工成支持原始服务的 ESB 上的几个任务服务，而不是尝试重新实现它作为微服务。
换句话说，微服务并不总是解决旧服务问题的最佳方式。除非您将 服务基础架构迁移到云端 ，否则期望将现有服务重新实现为微服务只是自找麻烦，您不需要。
何时考虑微服务
当您准备好从传统的中间件驱动的 SOA 基础领域分支出来并构建新的基于云的应用程序功能时，微服务至少应该在您的路线图上找到自己的出路。如果您正在实施容器，那么微服务突然成为默认选择。
微服务不需要容器（反之亦然），但它们在设计上很容易容器化。此外， 如果您正在实施容器， 将除微服务之外的任何新的可执行代码放入其中是困难的，而且通常是不明智的。
但是，如果您已经拥有的服务不容易容器化，那么它们要么是微服务实现不佳，要么根本不是微服务。但不要用微服务清洗它们。相反，让您的微服务作为 微服务数据层 的一部分与它们交互。
回到 SOA 时代，我们通过实施基于 Web 服务的数据服务来构建数据服务层，这些数据服务将遗留数据创建-读取-更新-删除 (CRUD) 查询公开为 Web 服务操作。今天，我们可以使用微服务将此类数据服务抽象为 RESTful 资源，其中各个微服务通过抽象底层 CRUD 操作来响应 RESTful 调用。
是否实现微服务数据层的决定，当然是一个架构的决定，更进一步说，是一个面向服务的架构决定。当然，SOA 并没有消失，但也没有保持原样。这就是微服务清洗的真正教训：为了获得正确的微服务架构，我们必须保留一些经过验证的 SOA 实践，同时添加新的——这是一个需要合理的架构成熟度水平的挑战。好的架构没有捷径。
既然我们 了解了如何为云构建架构 ，并且现在微服务架构和容器已在我们的路线图上，那么是时候更新我们的 SOA 书籍以适应新一代架构——不允许微服务清洗。