大家先冷静一下。深吸一口气，然后我们再慢慢走进互联网上激战正酣的微服务与单体架构之争。
要点：
Amazon最近发布了一项案例研究，记录了其放弃微服务、转而采用单体架构的决定，并称成本降低了90%。这项案例研究在互联网上引发了大量评论和讽刺性推文，微服务与单体架构也因此被推上了技术擂台。
实际情况：
如果您觉得这种技术场景似曾相识，那并不是错觉。2009年前后，面向服务的架构（SOA）也曾面临同样的处境，当时Anne Thomas Manes宣告SOA已死。该链接指向David Linthicum对Manes文章的评论，因为原文似乎已从互联网上消失。
Manes当时的说法有些夸张，也带有几分讽刺意味，因为众所周知，面向服务的架构并没有消亡。它很快便以微服务的形式重获新生，而从互联网上的一片哀叹来看，设计人员仍未认识到“网络”对性能有多么重要。
SOA之所以“消亡”，有两个原因：
- 相互竞争且臃肿的XML标准让架构变得过于复杂。没有人会怀念WSDL、SOAP和UDDI。一个也没有。
- 物理定律和互操作性标准将网络数据包的传输速度限制在光速以内，并将数据包大小限制为1500字节。
我们或许已经克服了第一个挑战，但第二个呢？要应对第二个挑战，过去和现在唯一的办法都是在服务设计粒度与充分了解服务间数据传输所需时间之间谨慎权衡。
传输数据并非没有开销，而是需要时间。服务之间的通信不存在“零成本”。将数据包发送到网络、传输数据包、从数据包中提取数据并最终进行处理，都需要时间。传输通信本身也需要时间。打开套接字和接受请求同样会产生开销，将有效负载序列化和反序列化为服务可处理的格式也需要时间。
现在，将这项总成本乘以要使用的服务数量。
系统设计的粒度越细，处理请求所需的时间就越长。换言之，处理请求的总时长取决于该请求必须经过的服务数量。
粒度越细，处理时间越长。服务越多，网络越拥塞；网卡和设备需要对数据包进行排序并请求重传，最终导致处理时间增加。
因此，与SOA一样，微服务也可能并且必然会受到依赖过度细粒度的设计模式影响。
Amazon选择用单体应用取代其微服务。这意味着，对于Amazon的用例，单体架构是更合适的选择。这是否意味着微服务已死？
不是。相反，我们应该从中得出两个要点：
- 首先，我们应借鉴Amazon的经验，在设计依赖服务的系统时更加审慎周全，并确保充分了解将职责拆分到过多小型服务中会对性能产生哪些影响。
- 其次，应当记住，单体架构也是一种可行的应用架构选择。以下数据并非偶然：企业应用组合中有60%的应用采用“传统”架构，另有16%的组织没有淘汰这些应用的计划。
应用架构本身并无好坏之分，也并非适用于所有用例。组织需要退一步，仔细思考希望实现什么目标，以及哪种架构更能满足这一需求，而不是仅仅因为某种架构正流行，就选择所谓最“现代”的架构。
我们所说的未来是混合IT，不仅指多云与本地部署并存，也意味着在可预见的未来，企业应用组合仍将采用混合模式，传统架构与现代架构的应用并存。因此，F5产品组合将继续支持所有应用，无论应用部署在本地、公有云中，还是同时部署在两者之中。
关于作者
Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。
Lori Mac Vittie 的更多博客文章相关博客文章
2023年应用策略现状：成本与复杂性是推动多云网络发展的首要因素
多云网络解决方案可在核心、云和边缘环境之间实现无缝、安全的互联，为解决当今混合IT面临的挑战提供支持，因而备受业界关注。