微服务： 减少微服务，增加服务

面向服务架构（SOA）近十年前就被宣告死亡。 导致其衰落的一个但很少被讨论的因素是网络。 服务之间的延迟阻碍了架构师将应用完全分解为具有鼓励重用和最终可组合应用所需粒度的服务。

进入微服务架构（MSA）。 它的原则要求进行更大程度的分解，以功能（动词）而不是对象（名词）作为划分应用的主要标准。 这种看似微妙的焦点变化带来了更大的服务粒度；在任何给定系统中，功能的数量都比对象的数量多得多。

网络已准备就绪。 物理网络的速度和反馈已大幅增加。 计算也按照摩尔定律不断进步，网络延迟几乎不再是问题。

不幸的是，通信延迟将取而代之。

我们在用于部署微服务的容器环境内部复制了互联网的复杂性。  虽然微服务可能不需要 DNS，但它仍然依赖于运行互联网的相同类型的基于名称的解析。 application标签 - 元数据 - 必须转换为 IP 地址。 服务注册表和复杂的 IP 表条目充当微型 DNS，将标签转换为地址并实现服务之间的通信。

微服务及其相关容器的短暂性加剧了与此过程相关的延迟。 由于生命周期以秒或分钟而不是小时或月来衡量，因此每次调用都必须进行名称解析。 容器世界内的生存时间（TTL）实际上为零。

即使我们忽略这个最大的通信延迟来源之一的再现，我们仍然会遇到与 TCP 相关的延迟。 建立或拆除 TCP 连接并不是免费的，也从来不是免费的。 这种延迟源当然很小，但绝对会产生附加影响。 执行单个事务所需的每个连接（每个微服务）都会增加延迟，最终超出对延迟的容忍度。

尽管 HTTP/2 的行为发生了巨大变化，但并未解决这个问题。 HTTP/2 旨在促进通过同一连接传输多个对象，从而减少网页和基于 Web 的应用等多对象内容的延迟。 微服务的理想设计是每个服务都返回单个响应。 虽然通过已建立的连接发送多个请求肯定会减少通信开销，但在多个请求分布在多个离散服务上的系统中，它无法做到这一点。

那么，问题就不在于网络延迟，而在于通信延迟。 连接仍然很重要，旨在提高基于网络的多交易通信性能的协议改进不会对多服务交易有帮助。

结果就是 SOMA。 面向服务的微架构。 面向服务和微服务架构的奇怪混合体，让人不禁疑惑一个在哪里结束，另一个在哪里开始。 将应用分解为基于复合功能的服务受到通信延迟以及最终代码库可持续性的限制。 虽然网络的进步确实增加了合理完成分解的粒度，但并没有消除限制。 另一个因素是，应用中的功能比对象多几个数量级，这使得管理纯微服务架构应用的任务对于网络操作来说成为一场后勤噩梦，更不用说应用程序开发人员了。 结合通信延迟引发的固有问题，组织越来越多地开发面向对象的微服务，而不是真正面向功能的微服务。 

这最终就是为什么我们看到应用分解超越了传统的三层架构，但还不能忠实地表示基于功能的分解。

除非我们解决基于连接（TCP）通信所固有的延迟问题（无论是采用新方法还是通过集中于系统级实现），否则我们将继续受限于微服务架构，这种架构微型化程度较低、服务较多。