单体架构与微服务之比较

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

微服务（以及经常与之相提并论的“最佳搭档”容器）正逐渐受到各类开发人员的青睐。采用微服务松耦合、仅通过API交互和细粒度的设计原则，不再只是初创企业的选择，大型企业也开始加入这一行列。

随着采用率不断提高（Datadog是一家云基础设施监控提供商，自2014年9月起的12个月内增长了近5倍），宣称单体应用已死的声音也愈发高涨，认为其架构完全不合时宜，不仅已经过时，而且根本就很糟糕。

不过，正如Gigaom最近的一篇文章所指出的，在大刀阔斧地将每个单体应用拆分成上百个不同的微服务之前，需要权衡利弊。顺便说一句，这并不是什么新概念。微服务之父Martin Fowler早已撰文探讨过这些取舍，并对所谓的“盲目采用”微服务提出了警示。事实上，Gigaom的文章总体上与Fowler的观点相同，只是表述得更为简洁。

如果想快速了解这两篇文章的要点，基本可以归结为：微服务会增加运维复杂性，并可能因性能问题对应用体验产生负面影响。这两种后果都不理想，而且往往并非本意。因此，在数据中心里的那个人挥起那把比喻中的风镐之前，需要先充分了解这些后果。

话虽如此，Lori为什么会关心这些？毕竟，她和F5都不从事应用构建或设计。无论这些应用采用单体架构、微服务架构，还是<此处填写下一种应用架构>，F5都会负责交付。

确实如此。但我们的业务是构建和部署用于交付这些应用的应用服务，而DevOps、微服务等近期趋势（以及容器热潮）也给我们的领域带来了同样的问题。具体来说，是否应采用更贴近微服务架构的模式，将通常部署在ADC平台上的应用服务拆分为粒度更细、与应用关联更紧密的服务？

仍需权衡取舍

无论讨论的是应用架构还是应用服务架构，在做出此类决策之前，都需要了解其中涉及的权衡取舍。

平台（单体式）方法

这是交付各类应用所需应用服务的传统方法，可用于保护应用、扩展应用规模并优化应用。服务部署在单一的共享平台上。得益于底层代理的架构，这种方法有助于提升性能。这是因为所有请求（及响应）都可以在同一环境中经过所需服务，无需离开该环境。因此，无需额外的网络跃点（及其相关延迟）或连接（会占用资源并产生延迟）。每项服务仍可单独扩展和管理，但都依赖同一套共享硬件（商用现成硬件或定制硬件）。这意味着共享硬件会成为单点故障，不仅影响一项服务，还会影响多项服务

每应用代理（微服务）方法

此模型更符合DevOps和新兴的应用架构实践。每项服务均单独部署、管理和扩展。虽然这会增加管理成本（毕竟需要管理更多实例），但如果将各项服务部署在同一平台上，便可降低部分成本，同时还能灵活组合不同提供商的服务。此方法的优势在于，服务可以与应用架构更紧密地关联，并纳入应用架构，包括与常用自动化框架集成。

将应用交付分解为多个组成应用服务，也会带来同样的弊端，即性能问题和复杂性增加。反之，开发人员采用微服务并避免单体架构的原因，即追求敏捷性、多样性和模块化，也同样适用于应用交付。

我直接引用Martin Fowler的一段话：“许多开发团队发现，微服务架构风格相比单体架构更具优势。但也有一些团队发现，微服务会成为拖累生产力的负担。与任何架构风格一样，微服务既有成本，也有收益。要做出合理选择，就必须了解这些成本和收益，并结合具体情境加以权衡。”

这一观点同样适用于应用服务。传统（单体式）方法和现代（微服务）方法各有利弊，需要结合其所交付、保护和优化的应用场景加以权衡。

关于作者

Lori Mac Vittie杰出工程师兼首席技术布道师 | F5

Lori MacVittie是F5首席技术官办公室的杰出工程师兼首席技术布道师，在应用交付、自动化战略和基础设施领域拥有深厚的专业知识。无论是为AI智能体定义防护机制、剖析脆弱的多云架构，还是探索可扩展系统的极限，她都善于化繁为简。她在应用开发、IT架构以及网络和系统运维领域拥有30多年的行业经验。加入F5之前，她曾担任技术编辑，并因出色表现获得奖项。 MacVittie拥有计算机科学硕士学位，著述颇丰，出版作品涵盖安全、云和企业架构领域。她还热衷于桌面游戏和电子游戏，并且对奶酪有着毫不掩饰的鲜明见解。

Lori Mac Vittie 的更多博客文章