我们是否已经全面采用微服务，又回到了非常古老的方法？

在软件架构和设计方面，微服务如何与中间件“堆叠”（双关语意）？我来自Java，似乎当您摆脱作为API的直接REST并抽象出不同的层和连接参数时，至少在Java中，您几乎已经完全回到了一些非常古老的想法。我们已经回到虚拟化……而JVM 已经是虚拟的。

以一种不可知论的方式，您可以并且我会争论将RESTful API抽象到CORBA的优点。或者，以Java为中心的方式，使用JMS或MDB。

EJB在Java上曾经是一个大问题，但在某种程度上它被认为是集群效果，但是现在，我们又回到了起点吗？

还是微服务提供了CORBA甚至更好的MDB所缺少的功能？当我读（TLDR）Martin Fowler解释微服务时，如果可以的话，它是解决一个严重问题的很好的解决方案。更确切地说，是一种封闭的方法，它引入了一定程度的复杂性，只能解决问题。如果这些服务确实是微服务，并且数量众多，则每个服务的运行和维护成本都为一美元。

此外，如果许多微服务中的一个微服务更改了其API，那么依赖该服务的所有内容都会中断。它并不显得松散连接，它似乎敏捷的对立面。还是我滥用这些话？

当然，在这些极端之间有很多不确定的选择。

鲨鱼与大猩猩...走吧！ （对于书呆子来说，这具有讽刺意味，完全不是我的意图。这个问题是从表面上考虑的。如果这个问题可以改善，请这样做，或者发表评论，我会解决的。 ）

设想在docker上运行的多个微服务都在一台机器上互相交谈...疯狂。难以维护或管理，几乎不可能更改任何东西，因为任何更改都会级联并导致不可预见的错误。这些服务分散在不同的计算机上如何更好？而且，如果它们是分布式的，那么肯定可以解决某些非常非常古老的技术，至少在一定程度上解决了分布式计算的问题。

为什么水平缩放如此普遍，或者至少是可取的？

TL; DR。我很高兴喝了很多Microserver风味的Kool-Aid，所以我可以说说它们背后的原因。

优点：

• 服务知道它们的依赖关系是稳定的，并且有时间参与进来
• 允许滚动部署新版本
• 允许在不影响更高层的情况下还原组件。

缺点：

• 您不能使用依赖项的新功能和闪亮功能。
• 您永远都不能破坏API向后兼容性（或者至少在许多开发周期中）。

我认为您从根本上误解了微服务架构应该如何工作。它的运行方式是，每个微服务（在此后称为MS）都具有其所有客户都同意的严格API。只要保留API，MS便可以进行所需的任何更改。只要保留API，就可以将MS扔掉并重新编写。

为了帮助进行松耦合，每个MS都依赖于其依赖项的版本n-1。这使得该服务的当前版本不稳定，并且风险更高。它还允许各种版本出现。首先升级一台服务器，然后升级一半，最后升级其余服务器。如果当前版本出现任何严重问题，则可以将MS回滚到以前的版本，而不会失去其他层的功能。

如果需要更改API，则必须以向后兼容的方式进行更改。

我们发明的每一种软件开发技术都以某种方式来管理复杂性。其中很大一部分已经并且将继续是抽象，封装和松散耦合。微服务是做这些事情的另一种方式，这也许就是为什么它在较高的理论水平上类似于许多旧技术的原因，但这并没有使它变得没有任何用处或相关性。

关于松散耦合，我认为您对目标有些误解。如果任务A需要调用任务B，将永远不可能使A和B 100％分离。永远不会发生。您可以做的是确保，如果任务B调用任务C，那么任务C永远不必担心对A的更改。如果这三个任务都在一个大的Blob中链接在一起，将结构彼此传递，则有一个如果他们中的任何一个有很大的机会，他们都将不得不改变。但是，如果所有三个都是微服务，那么您基本上可以保证对A的更改只会迫使B更新（除非对A的核心功能有如此大的更改，您可能应该将其更改为全新的服务）。如果所有微服务更新均应以向后兼容的方式完成，则尤其如此。

关于敏捷评论，我可以从个人经验中告诉您，我们的微服务y代码在敏捷方面的性能要比我们的“链接到大对象”代码更好。在后者中，每当有人修复了低级功能中的错误时，他实际上必须向整个研发部门发送一封电子邮件，内容为“请重新链接您的任务，否则它们将在星期五崩溃”。我们每个礼拜都会收到一些。如果他的代码在微服务中，那么只要他部署了新版本，我们都会从修复中自动受益。

我不完全理解有关COBRA和MDB的评论，因为它们似乎不是软件体系结构，而是其中的一个组件。据我了解，它们是定义您的微服务的消息传递协议和/或实现所述微服务的潜在方式，而不是微服务的替代品。

这些服务分散在不同的计算机上如何更好？

因为有云。

做笑了吗？严重的是-对于许多企业而言，软件的最大成本不再是软件。它是带宽，硬件，CDN成本等。现在每个人都拥有移动设备，因此流量越来越多。随着您的烤面包机获得自己的互联网连接，情况只会变得更糟。

因此，企业正在寻求管理这些成本。具体来说，他们正在尝试解决以下业务问题：“如果这件事发生了，我该如何为数以百万计的人使用/使用我的软件服务—而不用提前支付服务器为数以百万计的人使用/使用我的软件服务的费用。 ？”。

为什么水平缩放如此普遍，或者至少是可取的？

因为它回答了这个（巨大且不断增长的）业务问题。

当您有十几个用户时，您可以将所有服务都放在一个盒子中。这很好，因为您只想支付一盒即可。而且，当您的业务扩展时，您也不想为应用程序的更改付费以拆分各种服务。这些天来，您没有时间去做，直到客户的大批顾客将服务器点燃。

这也很好，因为它允许您处理服务器分配，以便您可以：

1. 使用您拥有的大多数服务器，而几乎没有浪费。
2. 衡量软件各个要素的性能。
3. 减少由发布引起的部署/停机时间。

进行非常精细的部署可以使这两项变得更容易/更好（除了有助于更好地分离问题）。