为了真正能够在任何地方提供数字能力，企业必须放弃熟悉的“直接迁移”并转向 CNP（Cloud-NativePlatform，云原生平台）。CNP 运用云计算的核心能力，向使用互联网技术的技术创造者提供可扩展的弹性IT相关能力“即服务”，从而加快价值实现时间并降低成本。因此，Gartner 预测到 2025 年，云原生平台将成为 95% 以上新数字倡议的基础，而在 2021 年这一比例只有不到 40%。

　　由于云原生平台会以容器、Kubernetes （K8S）等技术为基础，因此可以说，企业未来的 IT，是云化与容器化的天下，这已经是无法逆转的趋势了。为什么这些技术现在会这么火，为什么它们已经成为 IT 的潮流和方向，我们还是得从应用交付这项技术的历史以及它现在面临的问题和挑战谈起。

　　企业都需要采购网络设备、服务器、虚拟化软件来搭建一套基础架构平台，但没有任何一家企业会为买网络设备而买网络设备，也不会为买服务器和虚拟化软件而去采购。企业有这些采购需求，其原因只有一个，那就是需要安装、运行应用，并交付出去，让内部和外部的 end user 使用。这个需求下，催生了一个新的行业的诞生，就叫做“应用交付”。

　　其实提到应用交付，还有一个更响亮的名称，就是“负载均衡”。应用交付说白了就是负载均衡发展到一定阶段后赋予的新含义。1996 年，随着互联网大规模发展，企业发现单台服务器或小型机无法为这么多互联网用户提供服务了，因此需要多台计算机来提供同一个应用服务。但是如何让这些计算机比较平均地分摊访问请求呢？人们很快想到了办法——互联网发布的应用都需要通过域名访问，那在 DNS 服务器上增加轮询功能，就可以负载平摊了。但是 4 台提供同一服务的服务器挂了一台怎么办？DNS 服务器对后端应用服务器的健康状况不知情，就会有 25% 的 end user 无法访问应用。为了解决这个问题，有几家初创公司开发了一种名为“负载均衡器”的设备，通过“健康检查”机制，让负载均衡器监控应用服务器的健康状况，如果有问题就将其标记为下线，这样就既解决了负载均衡的问题，又实现了应用高可用性和业务连续性。

　　负载均衡技术的实现，主要是通过“反向代理”的机制。中国移动的 10086 客服电话总机就是一种典型的反向代理，总机知道我的需求后，然后找一个空闲的且对处理我的需求经验最丰富的专家接线员来解决。这就是因为总机知晓客户端和服务端两端的情况，就能提供最好的服务。负载均衡器其实就像这样的一台总机，充当了一个代理人的角色。它知晓客户端的需求，又知晓服务器端的状况，因此后来负载均衡技术得到了长足发展，除了负载均衡之外，还能实现会话保持、网页和图片压缩、页面缓存、终端加速和优化、多链路选择、网页防篡改、DDoS 防御、SSL 卸载等各种功能。由于负载均衡器已经不再单单实现负载均衡了，因此人们后来一般将其称为“应用交付控制器”，简称 ADC （英文 Application Delivery Controller 的缩写）。

　　但是现今，我们的应用已经发生了天翻地覆的变化。比如，遇到一些突发的流量，应用需要自动化的扩容，ADC 就不能通过手动调整配置的方式来应对，因为突发流量经常有，应用需要实现弹性的伸缩，但是 ADC 的自动化配置还难于实现，硬件 ADC 的自动化资源调用则是完全无法实现。应对突发流量，现在经常采用的做法是调用公有云的资源，但是 ADC 如何做到本地和公有云上的交付策略的一致性？其中最大的挑战在于 end user 在使用应用时遇到了 bug、或者有新的功能建议，因此应用的版本迭代会越来越快，我们如何做到持续调整 ADC 的策略？

　　在这样的需求背景下，应用开发模式已经发生了根本变化。在以往，我们一般会使用“瀑布式开发”的模型。瀑布式开发意味着会在应用的代码设计阶段将占到整个应用开发的生命周期的一半以上，并且由于其单体式、紧耦合的架构，会将框架锁定，之后如果需求变更，就很难修改。这就意味着，现在的企业在需要随时提升 end user 体验、快速实现版本迭代的背景下，瀑布式开发就不会再流行了。因此人们需要实现敏捷开发，用松耦合的方式来实现代码架构。换句话说，人们将大的代码框架分成了多个模块或多个服务，一旦需求有变更，只会对一个模块或服务进行修改，这就规避了瀑布式模型下牵一发而动全身的弊端。敏捷开发的应用也被称为“敏态应用”。这种架构，对企业的 IT 平台提出了新的要求。

　　微服务意味着一个应用会由多个甚至无数个服务来组成，每个服务都有自己的代码开发逻辑，想要调整或迭代版本就会非常便捷和快速。而容器、K8S 技术又是实现微服务的最好的平台。

　　应用需要敏捷性、随需扩展、自动化处理突发流量、自愈等特性，那就必须使用云化平台作为其底层基础架构。

　　代码的开发、运维、bug 处理、新版本上线与老版本下线等，将实现一体化。持续集成（CI）、持续部署（CD）将越来越流行。现在这个概念已经更深入了一步，发展为 DevSecOps，将安全态势感知和动态调整引入并结合了进来。

　　在这样的技术趋势下，我们的服务创建时间、应用的生命周期将会是秒级，将实现 100% 的自动化，应用是微服务的架构，底层则是通过容器、K8S 搭建的 PaaS 和 CaaS 平台。我们将这样的新型应用的模型，称为现代化应用 “Modern Application”。在这个应用模型下，对网络提出的挑战其实更大，容器网络的互连互通、7 层服务之间调用、外部访问容器时的入向路由和负载均衡都是我们需要直面的问题。为了实现自动化，我们还需要以应用为中心来驱动网络作出自动化配置和弹性调整。这套平台还需要实现更好的可视化功能，这样才能提前发现问题并调整，最终完成运维和开发的一体化。最终，我们通过这样的网络平台再把现代化应用给交付出去让 end user 可以使用。为此，我们需要重新定义这样的现代化应用交付平台。由于这个平台不只关注将服务交付（或者说发布）出去，还得关心底层 2-3 层网络的连接、服务之间如何调用。因此我们在重新定义这样的现代化应用交付平台的时候，会称它为“现代化应用连接平台”。

　　敏态应用在云化与容器化的网络环境中需要实现服务全连接，再安全、灵捷、智能地实现从开发到测试再到交付的一体化。这个平台的要求是：

　　无论应用部署在云端还是本地，是虚拟机搭建的容器环境还是物理机搭建，都需要实现一致的体验。

　　我们需要实现云网融合，做到统一的网络和安全策略，并实现 API 网关的功能。

　　整个平台将是全自动化的，无论是自动化的配置下发还是自动化的弹性伸缩，以及自愈、自修复能力都是必需的。此外我们需要对应用和网络实现全可视化和分析功能，才能更好的做到开发、安全和运维一体化。

　　现代化应用连接平台的底层物理网络之上，需要虚拟网络处理容器环境的 2-4 层流量，包括虚拟机与 Node 的网络连接、Pod 网络的连通性、多云和跨集群的网络连通。对于 7 层应用服务，需要东西向的服务调用以及南北向的服务暴露、发布、负载均衡。整个平台需要完整的安全策略以及深度的可视化和监控。VMware 是业界唯一能提供完整的解决方案的厂商。

　　对于虚拟机、容器 Node 的网络互连，在非 VMware 环境一般使用的是物理网络。但是 VMware NSX-T 解决方案可以打通物理网络的孤岛，抽象出网元实现转控分离的 SDN 架构和一致的网络功能，甚至打通多中心、多云环境，实现整个虚拟网络，实现多云、多中心一致的网络和安全策略。NSX-T 最早来自 VMware 在 2012 年收购的 SDN 鼻祖公司 Nicira，现在已经是非常成熟的解决方案了，有广泛的客户在生产环境中使用。

　　由于容器、K8S 开源的属性，催生了很多开源的网络解决方案。

　　容器的最小功能单元叫做 Pod。敏态应用的特点就是版本的快速迭代和上线，因此容器的做法是直接销毁一个 Pod 并基于新版本拉起一个新的 Pod。加上为了应对突发流量，Pod 随时可能被复制并调用更多的资源提供服务。因此 Pod 的地址经常变动且经常扩展，传统网络的路由和交换协议就不适用了。K8S 容器接口 CNI 的标准，就是为了实现 Pod 互连而提出的。开源的实现主要有 Flannel 和 Calico。Flannel 主要通过各种 NAT 实现交换功能，配置会非常复杂，且不支持多集群、多中心。而 Calico 则通过运营商级别的路由协议 BGP 来实现全路由，但是很少有金融和企业客户真正把它用好，这是因为底层物理网络需要配置 BGP 协议来配合，且该协议本身非常复杂，有 13 条选路原则，K8S 的运维人员和应用开发者并非网工出身，就只能寻求网络部门的帮助，而网络部门的人又不一定懂容器，不一定懂 Calico。如果用户同时需要 K8S 路由和交换功能，那么 Flannel 和 Calico 的组合使用会更加复杂。

　　

　　第一个方案叫 NCP，全称是 NSX Container Plugin。

　　其实现是将 NSX 的一个插件安装在容器的 Node 里，由其提取 Pod 的信息交给 NSX 控制器再由 NSX 的数据平面实现全网的路由和交换。这样做的好处是可以为一些租户、一些专门的应用集群分配专门的地址段，这个地址段能被外部的物理防火墙等安全设备或流量分析设备所识别。它还消除了复杂的 Flannel 和 Calico 的路由和交换实现，用自上而下的统一的控制器去下发所有的 2-4 层网络配置，并转发流量。这个方案一般用于部署在 VMware vSphere 环境上的 K8S 平台。

　　第二个方案叫 Antrea。

　　Antrea 是 VMware 发起的开源项目，它创新地利用了OVS（Open vSwitch）的网络功能实现了 CNI 的容器网络标准。由于 OVS 同时支持路由和交换，就不需要 Flannel 和 Calico 的组合，且因为其配置简单、易于扩展等特性，可以让 K8S 集群支持到数千 Node 以及数万 Pod 的规模。目前VMware 自己的 Tanzu 平台就是通过 Antrea 实现 CNI 网络功能，而且也有开源 K8S 已经使用 Antrea 了。VMware 的 Antrea 企业版会有更强的功能、更好的可视化，且可以被 NSX-T 的控制器管理和控制。这个方案一般用于 VMware Tanzu 环境或非 vSphere 平台上的 K8S 如裸机 K8S、公有云等。

　　此外，我们还可以使用 NCP 和 Antrea 的组合方案。

　　这个方案下，其实管理和控制平面只有 NSX控制器。通过 NCP 实现更高级的功能，借助 Antrea 实现更强的扩展性。这个方案可以使用在任何 K8S 环境。

　　实现容器集群内部服务之间的东西流量的访问，一般都是通过域名的方式，也是就是纯 7 层网络流量的访问了，这时候 CNI 的标准已不适用。开源的解决方案是 Istio，它提供了 NameSpace 这种简单的方式来为已部署的服务建立 Service Mesh 网络全连接并实现服务隔离，该网络具有内部负载均衡、服务间认证、监控等功能。

　　但是 Istio 的 NameSpace 只能实现单集群的 Service Mesh 和隔离。不只是 Istio，大多数服务网格实现只关注服务而忽略了用户和数据。用户使用服务来访问数据，如果应用运行在多集群或多云环境中，就无法集中管理用户、服务和数据之间的通信和访问。

　　为此，VMware 创新的使用 TSM（Tanzu Service Mesh）功能来实现 Global NameSpace （全局命名空间，GNS）。它通过将 Service Mesh 扩展到 K8S 集群之外并提供跨异构平台和技术（包括虚拟机和其他服务网格）的统一操作层，解决了与分布式微服务应用的挑战。

　　TSM 通过将这些对象排列在称为 GNS 的逻辑组中，为分布式应用中的资源提供服务网格功能。GNS 不绑定到单个集群，而是连接两个或多个集群之间的资源。每个 GNS 都为其对象管理服务发现、可观察性、加密、策略和服务级别目标 (SLO)，而不关心它们驻留在何处，无论是在多个集群、边缘站点还是云端。

　

　　用户的应用以 Pod 的形式运行在 K8S 集群的 Node 中。但是由于 Pod 的 IP 地址经常在变化，用户就无法使用某个固定的 IP 地址来访问 Pod。另外，Pod 可以以集群的方式横向扩展的，这就有了服务发现和负载均衡的需求。和传统的应用类似，部署在 K8S 中的应用除了负载均衡，也需要实现各种应用交付的策略，比如基于 Virtual Host、基于各种策略的消息路由、会话保持、页面缓存、压缩和优化、SSL、HTTP Header 的处理、WAF 等等。并且相对于传统应用来说，K8S 平台上运行的应用由于其动态性和申明式的特点，其应用交付的方式还有所差别的。

　　开源的做法是通过 Nginx 或 HA Proxy 来实现，它们将自己的反向代理实例在 Node 里充当一个 Pod 来实现入向路由，但是高级的应用交付功能，需要 K8S 集群外部的传统 ADC来实现。这样的实现首先路径不优化——外部的 ADC 需要随机找到一个 Nginx 或 HA Proxy 的 Pod，然后 Nginx 或 HA Proxy 再通过内部的机制，找到最优的服务提供给访问者，流量需要两层寻址。再者，云化环境中，外部的 ADC 使用硬件已不再合适，但是传统 ADC 厂商的软件，和其硬件几乎没什么区别，尤其是目前还没有任何一家传统 ADC 厂商能在其软件 ADC 上实现 vMotion、HA、DRS 等功能，这就意味着传统 ADC 的软件版本仍然是竖井式、烟囱式的架构，无法实现资源池，也无法灵活调度资源，更无法实现自动化。我们为什么要从小型机转向虚拟化，为什么要从磁盘阵列转向超融合，相信读者都是清楚的——这就是为了消除竖井式的服务器、竖井式的存储架构，并实现资源池。传统 ADC 厂商的在云化环境中的软件版本，仍然走了竖井式、烟囱式的架构的老路。最后就是性能，由于 Nginx 和 HA Proxy 都是自己作为 Pod 安装在 K8S 集群内部，这样会消耗 K8S 集群性能，能扩展的 Pod 就会变少，K8S 集群整体性能和扩展性都会受到影响。

　　VMware 的解决方案是 NSX ALB，全称是 NSX Advanced Load Balancer，它来自 VMware于 2019 年收购的纯软件 ADC 公司 Avi Networks，因此我们一般简称这个产品叫做 Avi。Avi 首先使用了基于 SDN 的转控分离的架构，配置和部署就变得非常简单且能实现资源池，有很好的弹性以及自愈的架构，这就解决了我之前提到的竖井式 ADC 架构问题。此外，对于容器的入向路由，Avi 的做法是将 AKO（Avi K8S Operator）或 AMKO（Avi Muti K8S Operator）以插件的形式部署在 K8S Node 内（是不是和 NCP 的实现很像）。这样做的好处是，AKO 或 AMKO 提取各种 Pod 信息，告诉 Avi 控制器，再由控制器自动下发配置给 Avi 的转发平面SE（Service Engine）。这样带来的优势是扁平架构，流量无需两层选路就能找到最优的服务暴露给 End User，其次也解决了 Nginx 和 HA Proxy 的实现带来的性能问题，因为 AKO 和 AMKO 没有 K8S 集群内部的性能损耗，Avi 控制器和 SE 又是部署在 K8S 集群外部，充分发挥了云化环境资源池的威力。

　　Avi 还有自带的 Waf 功能，一般暴露出来的服务很多都是 Web 服务，Avi 就可以通过 Waf 来保护它们。Avi 还可以实现 DNS 和 GSLB （全局负载均衡）功能，对于 TSM 的多云、多集群的 GNS 功能可以实现很好的配合。

　　Avi 现在甚至可以被 NSX 控制器管理和控制，这就意味着，整套现代化应用连接平台的解决方案，从 VM、Node 网络，到 Pod 互连，到服务暴露和入向访问、负载均衡，都是可以统一管理的。

　　

　　Avi 还内置了可视化和分析模块，甚至能取代一些专业 APM 厂商提供的功能，如每个服务的延时、分析安全事件、分析终端类型和地理位置、智能排错等，下面几张图片分别就是这些功能的截图。而传统 ADC 针对应用实现可视化和分析，往往是将 log 吐给专业的分析工具如 ELK 或 Splunk 来实现，这就意味则分析不是实时的，且架构会变得非常复杂。

　　

　　VMware 还有完整的现代化应用安全解决方案，基于零信任的框架。由于介绍起来篇幅会比较长，我们以后会专门再写一篇文章来介绍 VMware 针对现代化应用的零信任案解决方案。

　　关于可视化和分析，我们刚才其实已经提到了，Avi 天生可以实现一些 APM 的功能（该功能是免费的）。而针对 NPM，VMware 同样有强大的 VRNI 软件。并且我们还可以通过结合现代化应用零信任安全解决方案，通过安全态势感知，自动化地触发策略实现现代化应用连接平台的配置变更，保护您的应用。

　　有了 VMware 现代化应用连接平台，现代化应用在数据中心内部就可以实现按需扩展，并可以方便的扩展到公有云和服务商边缘，在业务对外交付、发布的过程中实现全局一致的网络和安全策略，以及无缝的业务迁移，并可以由 NSX 全局管理跨云的所有网络服务。应用从开发到上线无需考虑复杂的网络架构。

　　平台有内置的分析和可视化，加上扁平、轻量级的架构，可以提升运维效率，还有基于零信任框架的安全，最终实现 DevSecOps 一体化，助力应用敏捷开发、上线和迭代。

　　本文从应用交付的历史谈起，介绍了现代化应用开发的特点、现代化应用连接平台以及 VMware 的解决方案。该解决方案为您在的容器化的环境中带来全新的应用连接和交付体验。

　　如果您想了解更多技术细节，欢迎与我们的销售或售前工程师联系。谢谢。

　　范恂毅

　　VMware 大中华区 Avi 产品经理

　　14 年 IT 行业经验，持有安全、语音、数据中心三个方向 CCIE 认证，曾在 F5、Nutanix 等知名 IT 公司担任技术顾问，现任 VMware 大中华区 Avi 产品经理，负责 VMware 应用交付业务的推广和销售工作。