整体式 vs. 微服务架构： 微服务已过时，单体式架构卷土重来

对于那些感觉自己正遭受严重的技术似曾相识感的人来说，你们并没有错。 这与 2009 年Anne Thomas Manes 宣布面向服务架构 (SOA) 死亡时的情况相同。 该链接指向 David Linthicum 对 Manes 帖子的评论，因为原文似乎已被互联网吞噬。

现在，Manes 的说法有些夸张甚至有点讽刺，因为众所周知，面向服务的架构并没有消亡。 它很快就以微服务的形式复活了，而互联网的哀叹是，设计师仍然没有认识到“网络”在性能中扮演着多么重要的角色。

SOA 的“消亡”有两个原因：

1. 相互竞争且臃肿的基于 XML 的标准使得架构变得过于复杂。 没有人会记得 WSDL、SOAP 和 UDDI。 没有人。
2. 物理定律和互操作性标准将网络数据包的交换限制为光速和 1500 字节。

我们可能已经克服了第一个挑战，但第二个呢？ 第二个问题的唯一答案一直是、并且将继续是在服务设计粒度与对服务之间传输数据所需时间的良好理解之间取得微妙的平衡。

传输数据不是免费的。 这需要时间。 当谈到服务之间的通信时，不存在“零成本”这一说法。 将数据包放到网络上、进行传输、从数据包中取出并最终进行处理都需要一些时间。 不要忘记，运输通讯也需要时间。 打开套接字和接受请求也不是免费的，将有效负载序列化和反序列化为服务可以处理的内容所花费的时间也不是免费的。

现在，将总成本乘以您尝试使用的服务数量。

系统设计的越精细，处理请求所需的时间就越长。 换句话说，处理请求的总时间取决于该请求必须经过的服务数量。

粒度更大？ 处理时间更长。 更多服务？ 网络拥塞加剧，最终导致处理时间增加，因为网卡和设备需要整理数据包并要求重新传输。

因此，与 SOA 一样，微服务也会受到依赖过多粒度的设计模式的影响。

亚马逊选择了一个整体来取代其微服务。 这意味着对于他们的用例来说，单片架构是最佳选择。 这是否意味着微服务已消亡？

不。 相反，我们应该记住两个关键点：

• 首先，我们应该向亚马逊学习，更加慎重、周到地设计依赖于服务的系统，并确保我们了解在太多小服务之间分配职责对性能的影响。
• 其次，我们应该记住，整体式架构是一种可行的应用架构选择。 60% 的企业应用程序组合都是基于“传统”架构的应用，而 16% 的企业没有淘汰这些应用程序的计划，这是有原因的。

application架构没有好坏之分，也不适用于每种用例。 组织需要退一步，仔细考虑他们想要实现的目标以及哪种架构可能最能满足这一需求，而不是仅仅因为最“现代”的架构很流行就选择它。

当我们说未来是混合 IT 时，我们的意思不仅仅是多云和内部部署的混合。 我们还意味着，在可预见的未来，企业应用程序组合仍将保持混合状态——传统与现代的混合。 这就是为什么 F5 产品组合继续支持所有应用（无论是在本地还是在公共云中，或两者兼而有之）。