近十年前，面向服务的架构（SOA）就已被宣告消亡。网络是导致其衰落的因素之一，但鲜少有人提及。服务之间的延迟使架构师无法按促进复用所需的粒度，将应用完全拆分为服务，最终也难以构建可组合应用。
微服务架构（MSA）由此登场。其原则要求进一步拆分应用，并将功能（动词）而非对象（名词）作为主要拆分依据。这一看似细微的侧重点变化，使服务的粒度更细，因为在任何给定系统中，功能的数量都远多于对象。
网络已准备就绪。物理网络的速度和吞吐量已大幅提升。计算能力也遵循摩尔定律不断增强，使网络延迟几乎不再成为问题。
遗憾的是，通信延迟将取而代之。
我们在用于部署微服务的容器环境内部复现了互联网的复杂性。虽然微服务可能不需要DNS，但仍依赖与互联网运行机制相同的名称解析方式。应用标签（即元数据）必须转换为IP地址。服务注册表和复杂的IP表条目如同微型DNS，将标签转换为地址，从而支持服务之间的通信。
微服务及其关联容器的短暂生命周期进一步加剧了这一过程带来的延迟。它们的生命周期只有几秒或几分钟，而不是几小时或几个月，因此每次调用都必须进行名称解析。实际上，容器环境中的生存时间（TTL）为零。
即使忽略这种对通信延迟主要来源之一的重现，TCP相关的延迟仍然存在。建立或断开TCP连接并非没有开销，过去也从来不是。这个延迟来源虽然很小，但必然会累积。执行单个事务所需的每个连接，也就是每个微服务，都会增加延迟，最终超出可容忍的范围。
尽管HTTP/2的工作方式发生了显著变化，但它并未解决这一问题。HTTP/2旨在通过同一连接传输多个对象，从而降低网页和Web应用等多对象内容的延迟。理想情况下，微服务的设计应使每项服务仅返回一个响应。虽然通过已建立的连接发送多个请求确实可以减少通信开销，但如果多个请求分散在多个彼此独立的服务中，则无法实现这一点。
因此，问题不在于网络延迟，而在于通信延迟。连接数仍然会产生影响，而旨在提升基于Web的多事务通信性能的协议改进，对多服务事务并无帮助。
由此产生了SOMA，即面向服务的微架构。这是面向服务架构与微服务架构的一种奇特混合体，让人难以分辨两者的界限。将应用分解为由多个基于功能的服务组成的结构，会受到通信延迟的制约，并最终受限于代码库的可持续维护性。网络技术的进步确实提高了应用可合理分解的粒度，但并未消除这一限制。另一个因素是，应用中的函数数量比对象多出几个数量级。这使得管理采用纯微服务架构的应用对网络运维而言近乎一场后勤噩梦，更不用说应用开发人员了。再加上通信延迟带来的固有问题，越来越多的组织开始开发面向对象的微服务，而非真正面向功能的微服务。
这正是应用最终会突破传统三层架构进行拆分，却又不会彻底按功能进行分解的原因。
除非我们解决基于连接的（TCP）通信所固有的延迟问题，无论是采用新技术，还是着力改进系统级实现，否则微服务架构仍将受到限制，难以实现更细粒度的“微”，而更偏向于“服务”。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
2023年应用策略现状：成本与复杂性是推动多云网络发展的首要因素
多云网络解决方案可在核心、云和边缘环境之间实现无缝、安全的互联，为解决当今混合IT面临的挑战提供支持，因而备受业界关注。