面向云环境的ADC

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

云就绪应用交付控制器（ADC）并非传统ADC。它可部署在定制硬件或商用现货（COTS）硬件上，是一种可扩展的软件解决方案，可支持快速、安全且高可用的应用交付和部署。云就绪ADC支持采用现代化的双层数据中心架构，将传统的稳定性、安全性和可扩展性与现代、灵活、适用于云和DevOps的可编程功能相结合。

这个描述不错，但它究竟是什么意思？

我之前曾撰文探讨，要具备哪些条件才能称为现代应用代理。这无疑是云就绪ADC所需能力的一部分，但要满足当今严苛环境的需求，仅有技术能力还不够，还需要实现运营和生态系统集成，并能够支持现代及新兴应用架构。

坦率地说，市面上有许多ADC也声称已为云环境做好准备，并支持传统及新兴应用架构，此外还有其他诸多主张。因此，今天我想先深入探讨云就绪型ADC与传统ADC有何不同，然后再进一步说明它为何在当今的应用领域如此重要。

五个层面的差异化

云就绪ADC与传统ADC基本上有五个方面的区别（严格来说是六个）。早在我加入F5之前，F5就已在很大程度上定义了ADC应有的形态，因此我们对ADC有着深刻的理解，既了解它过去需要具备哪些能力，也清楚它必须如何演进，才能继续以企业所需的速度、安全性和稳定性来交付应用。

性能

这显而易见，对吧？毕竟，如果ADC要部署在应用前端并为其提供代理，速度就应该与所交付的应用一样快，甚至更快。传统ADC采用设备形态交付，包括机箱、硬件和设备。但传统ADC仍受其定制硬件中CPU的限制。ADC属于平台，因此往往侧重整体速度，就像通用CPU侧重通用处理一样。不过，它们几乎总会提供多种硬件加速选项，而这些选项必须在部署前确定。这个想法或许有些大胆，但我们认为，面向云环境的ADC应该能够突破这一限制，并理解不同应用对各项服务的需求侧重可能不同。按需调整计算资源用途是整个云计算概念的基础。同样，投资任何类型硬件的组织也应该能够调整这些硬件的用途。

这对于网络之上的服务层非常重要，因为将常见任务卸载到专用硬件（FPGA）后，CPU便可用于处理其他任务，例如请求和响应检查、修改、清理等。这样可以缩短流量在代理处的整体处理时间，从而降低延迟，改善用户体验。

正因如此，云就绪型ADC能够突破限制，利用软件定义的性能，让组织可以通过编程方式提升ADC在安全等特定处理任务上的性能。这意味着，当组织的需求发生变化时，也可以按需调整该硬件的性能配置。这就是硬件敏捷性。听起来有些矛盾，对吧？但这正是云就绪型ADC的一项特性：能够重新配置专用硬件的用途，从而保护现有投资，并避免成本高昂的整体替换式升级。

可编程性

我多次听客户提到一个长期困扰他们的问题：在脚本编写能力方面，网络运维（NetOps）与开发运维（DevOps）之间存在分歧。传统ADC仅提供最基本的脚本功能，而且使用的是NetOps更熟悉、DevOps较为陌生的语言。DevOps愿意学习并利用数据路径中的脚本功能，因为这可以支持更敏捷的请求和响应路由、多种扩展策略，甚至安全服务。但传统ADC位于上游的核心网络中，NetOps自然不愿让DevOps部署可能干扰流量传输的脚本。

虚拟版本的推出意味着，DevOps现在可以使用以虚拟机形式提供的专属私有ADC，但仍不得不学习偏网络运维的脚本语言。这并不理想。面向云环境的ADC既应支持核心网络中的NetOps，也应支持应用网络（例如云环境）中的DevOps。尤其是DevOps和开发人员，更倾向于使用node.js等对开发人员更友好的语言。这不仅是因为他们熟悉这些语言，还因为已有丰富的库（例如NPM）和服务，可帮助他们更快地与对开发人员友好的基础设施集成。因此，面向云环境的ADC应同时支持这两类需求。

应用安全

传统ADC长期以来一直提供基本的应用安全功能。由于部署在应用（尤其是Web应用）前端，它们通常是数据中心内最先能够识别攻击并采取应对措施的设备，过去如此，现在依然如此。可以理解的是，这些安全功能大多侧重于协议层安全。长期以来，SYN洪水攻击防护、DDoS检测以及其他与TCP和基本HTTP相关的安全选项，一直是传统ADC不可或缺的组成部分。

但面向云环境的ADC应该更进一步。为满足当今应用必然面临的扩展需求，ADC很可能是少数会纳入应用架构本身的“设备”之一，因此同样重视全栈安全顺理成章。至少我们是这样认为的，尤其是因为这样做有助于提升性能。如果必须停下来执行某类处理，那么同时尽可能多地完成其他处理显然更合理。这样效率更高，也能避免数据在多个设备之间传输所产生的延迟。如果曾带孩子长途旅行，应该不难理解：加油站就有洗手间，谁也不想5分钟后又在休息区停车，对吧？网络安全也是如此。尽可能一次完成更多处理，以减少开销，因为这类开销往往会让客户和企业都感到困扰。性能至关重要，面向云环境的ADC应尽其所能，提供更快速的应用体验。

这可能意味着提供新的模式，以应对移动设备与应用之间对安全通信支持日益增长的需求（在某些情况下是强制要求）。这意味着支持前向保密（FS）及其所需的加密技术。还意味着采用新的模式，将计算开销较大的加密和解密处理卸载到专为此类任务设计的硬件上，同时不破坏支持微服务和新兴应用所需的架构。面向云的ADC应同时支持这两方面，既实现快速又实现安全的通信，并无缝融入当前的架构和云环境。

合作伙伴生态系统与自动化

另一种API经济对于私有云取得成功，以及企业通过提高自动化和编排水平获得竞争优势至关重要。然而，无论统一服务多么理想，数据中心始终会存在来自不同供应商的各种服务，其集成和对象模型也各不相同。这通常会导致API驱动的自动化过程十分繁琐，并要求人员熟悉每个必要组件。实际上，需要实现两个层面的集成：一个用于编排，另一个用于自动化（没错，两者并不是一回事）。平台本身通过API和模板提供自动化功能，同时还需要与合作伙伴生态系统进行原生集成，而编排在其中发挥着主导作用。云就绪ADC必须同时具备这两项能力。前者可通过专有产品、自定义脚本以及Puppet和Chef等框架实现自动化；后者则可通过OpenStack、VMware和Cisco等日益重要的控制器实现编排。

云就绪型ADC应提供原生集成，并通过现有框架和系统提供编排功能，从而形成全面的编排解决方案。

云就绪ADC理应支持云模板，这一点无需反复强调。

所以，关于这一点，我就不再多说了。

应用模型

传统ADC源于为传统应用提供一套强大服务的需求，也就是为单体应用而生。如今的应用日益分布式、多样化，与传统应用相比也更加不同，并采用各种架构、平台和部署模型。无论使用容器还是虚拟机，也无论部署在云环境还是类云环境中，应用仍然需要其中一些服务。如果需要同时使用多项服务（例如负载均衡和应用安全），就需要ADC。传统ADC可能不适合微服务，但云就绪ADC可以满足需求。它涵盖更广泛的服务，这些服务可受益于负载均衡和安全能力，并且完全属于DevOps而非NetOps的范畴，例如memcached。

云就绪型ADC仍是一个平台，但它支持满足可编程性、集成和外形规格方面的必要要求，从而在传统应用和新兴应用所需的环境中提供其所需的服务。

传统ADC与云就绪ADC有许多相似之处。两者都是平台，能够通过统一的运维模式支持多种服务；都具备可编程能力，可与其他数据中心和云系统集成，并可灵活满足不同的性能需求。但云就绪ADC不止具备传统ADC的能力，还能支持业务和应用未来发展，满足其日益多样化的需求，使其能够与各种基础设施和环境集成并互操作。

关于作者

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

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

Lori Mac Vittie 的更多博客文章