整体式架构与微服务

微服务（以及其经常被提及的 BFF，容器）开始赢得广大开发人员的青睐。 不仅仅是初创公司采用微服务的松散耦合、仅 API、细粒度的设计原则；大型企业也加入了这一行列。

随着应用的不断增多（云基础设施监控提供商Datadog自2014年9月以来的12个月内增长了近5倍），随之而来的是，人们强烈呼吁单体应用的消亡，而其完全不合适的架构不仅过时，而且非常糟糕。

但正如Gigaom 最近的一篇文章所指出的那样，在拿出手提钻并将每个整体式应用程序拆分成数百个不同的微服务之前，需要考虑一些权衡。 顺便说一句，这并不是一个新概念。 微服务之父马丁·福勒 (Martin Fowler)很久以前就写过关于这些权衡的文章，并警告称，对微服务的“盲目采用”只能被视为一种行为。  事实上，Gigaom 文章大体上表达了与 Fowler 相同的观点，只是格式更简洁。

如果您正在寻找两者的 TL;DR，基本上可以归结为：微服务增加了操作复杂性，并可能在性能方面对应用体验产生负面影响。 这两种后果都是不受欢迎的，而且往往是意想不到的，需要提前了解，以免数据中心里的那个人开始用手提钻进行破坏。

话虽如此，但 Lori 到底为何关心这些？ 毕竟，她和 F5 都不是从事应用构建或设计业务的。 F5 将交付这些应用程序，无论它们是整体式应用程序、微服务还是下一代应用程序架构。

全部都是真的。 但我们的业务是构建和部署交付这些应用的应用服务，而 DevOps 和微服务（以及容器热潮）等最新动向给我们的领域带来了同样的问题。 即，您是否应该将通常部署在 ADC 平台上的应用服务分解为更细粒度的、与应用程序相关的服务，并以更符合微服务架构的模型进行部署？

仍需权衡

无论我们谈论的是应用程序架构还是应用服务架构，答案仍然是在做出这样的决定之前了解所涉及的权衡。

平台（整体）方法

这是提供保护、扩展和优化所有类型的应用所需的应用服务的传统方法。 服务部署在单一共享平台上。 由于底层代理的架构，这种方法具有提高性能的优势。 这是因为所有请求（和响应）都可以遍历所需的服务而无需离开同一环境。 这意味着不需要额外的网络跳数（和相关的延迟）或连接（资源、延迟）。 每个服务仍然可以单独扩展和管理，但它们都依赖于单个共享的硬件（COTS 或定制）。 这意味着共享硬件是单点故障，会影响多个服务

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

该模型与 DevOps 和新兴应用架构实践更加契合。 每个服务都单独部署、管理和扩展。 虽然这会产生额外的管理成本（毕竟需要管理更多实例），但如果每项服务都部署在同一平台上，其中一些成本就会降低，但确实提供了“混合搭配”不同提供商的服务的能力。 这种方法的优点是服务可以与应用架构更紧密地关联（因此包含在内），包括与流行的自动化框架的集成。

同样的缺点（即性能和复杂性增加）也与将应用交付分解为复合应用服务有关。 相反，开发人员采用微服务、避免整体式架构的原因（即对敏捷性、多样性和模块化的渴望）也同样适用于应用交付。

我将简单引用马丁·福勒的话： “许多开发团队发现微服务架构风格比单片架构更优越。 但其他团队发现它们是一种降低生产力的负担。 与任何架构风格一样，微服务既有成本，也有收益。 为了做出明智的选择，您必须理解这些并将其应用于您的具体情况。”

这句话同样适用于应用服务。 传统（单体）和现代（微服务）方法都有成本和收益，需要在它们将要交付、保护和优化的应用环境中考虑。