NSX ALB（下文可能也称 Avi）是一款纯软件定义的负载均衡器，其对市场带来的变革不亚于当年 SDN 对于传统网络市场带来的变革，或许有人会问多年以来负载均衡技术已经那么成熟稳定，为什么还会出现一种较为颠覆的技术呢？这和市场的发展密不可分，而市场发展就是各种技术的演进带来的技术栈的变化，比如在 4 年前，可能很多人并未听过 Kubernetes，部分人可能听说过 Docker，但了解之后觉得 Docker 离我们还很远，而现在在很多招聘启事中明确写了“熟练掌握 Kubernetes”，Kubernetes 和虚拟化、Linux、网络等一样成了 IT 基础知识体系的一部分。 再回到本文的主题，在初次接触 Avi 之后，立刻被它的简洁设计吸引，花了大量时间学习之后，发现产品在很多层面都是花了大量心思慢慢雕琢出来的，很有“工匠精神”，很想将一些心得分享给大家。

第一板斧：自动化

可能很多人一听到负载均衡器的自动化就慌了，这么重要的东西怎么可以自动化呢？人工管理挺好的啊？万一出了问题怎么办呢？

自动化是个很宽泛的词，自动化在某些时候或许真的会带来灾难，但大部分情况下自动化是一个加分项，甚至在一些场景中是一种重要的能力，稳定可靠和自动化并无直接关联。

通过自动化实现零维护

稳定性是很多 IT 人尤其是 SRE 最关注的一个词，为了实现稳定性企业会花大笔的钱购买冗余的设备及相关的维保费用，而很多时候能保证的也就只有容许单节点故障。一旦故障发生，熬夜加班是不可少的，找备件、申请停机窗口、维修、配置、检查、上线，而整个阶段还要背着会不会有第二个节点故障的心理压力。

很多技术产品都会使用一些自动化的程序来进行自愈，例如我们最常用的 vSphere HA，在虚拟化中，HA 是个和资源池化同等重要的功能。在 Avi 中，自愈更上了个层次。

Avi 使用类 SDN 的架构，控制平面和数据平面完全解耦，当把 Avi 部署在 vSphere 环境中时，Controller 可以与 vCenter 协同完成数据平面所有组件的生命周期管理，这种架构像极了 Kubernetes 目前的架构，虚拟服务会像 K8s Pod 一样由 Avi Controller 来统一调度，虚拟服务并不会与运行它的实体（服务引擎 Service Engine）进行绑定，当服务引擎出现故障时，虚拟服务会平滑漂移到其他正常工作的服务引擎，保证业务访问不受影响。

针对原有故障的引擎，Avi 有两种处置方式：1，通过控制层面 API 进行重启，尝试恢复，如果多次尝试失败后，自动重建。2，如果初次出现问题，故障服务引擎会保留一段时间，方便售后人员排错以发现根因。

下图为 Avi 与 vSphere 环境集成架构图

通过自动化实现快速部署

接着上文的零维护，Avi 通过自动化实现的另一个功能是快速部署。当传统负载均衡设备上线时，管理员通常要进行设备入库、申请机柜空间、申请管理网络、业务网络 IP 、协调网络接线等工作，在 Avi 软件架构下，管理员更像一个指挥家，规划好整体的部署架构，申请计算资源，申请 IP，剩下的就是点点鼠标的事。

通常在部署 Avi 时唯一需要人工部署的只有控制器，部署方式则是按照向导完成 OVA 的导入。
接着，管理员需要规划一套管理网络 IP 池，用于服务引擎的带外管理；一套业务网络 IP 池，用于承载 Virtual IP 以及让负载均衡器连接到后端 server。在 Avi 初始化时完成这些配置之后，管理员即可开始创建虚拟服务，剩下的工作控制器会自行完成。通常一套 Avi 的部署在一个小时内可以完成。
部署详情请看上篇“Avi 学习手记 (1): 快速部署”

通过自动化完成云原生业务交付

在云原生时代，业务的架构由原来的多层架构转变为微服务，原来静态的管理方式变成了基于 API 的动态编排调度系统，在 Kubernetes 的思想中，基础架构资源如网络、安全、存储、计算等均跟随着一个个服务而生，要适应这种框架，产品必须也得像 Kubernetes 一样高度自动化，Avi 便是这样一种架构。

通常在 Kubernetes 中有下列四类网络服务需求：

• Pod 内容器到容器的访问：在一个 Kubernetes Pod 之内，多个容器共享网络堆栈，自然可以通过 Localhost 直接通信；
• Pod 间的访问：通常由 CNI 负责 Pod 间的网络连通；
• Pod 到服务的访问：通过 kube-proxy 借由 IPVS/IPtables 实现。部分 CNI 则使用自己的 Proxy 实现 Service，例如 NSX Container Plugin 的 nsx-kube-proxy，或者 Project Antrea 的 antrea-proxy；
• 外部网络到集群内 Service 的访问：Kubernetes 提供 NodePort、Loadbalancer、Ingress 等多种方式，一般在企业应用中最多的则是后两者，一般都会交由专业的负载均衡器产品来实现，例如 Avi。

Avi 与 Kubernetes 集成的架构如下，相比 Avi 自身的架构，只多了一个组件 Avi Kubernetes Operator（简称 AKO），在此架构下 AKO 用于监听 Kubernetes 中 Ingress 及 Service type LoadBalancer 的创建事件，并将 Kubernetes 的配置转化为 Avi Controller 可以识别的 API 来进行负载均衡器的自动化配置。

除了单 Kubernetes 集群的业务发布之外，Avi 也支持多 Kubernetes 集群业务的发布。现在很多企业为了提高可靠性都会在不同地理位置建设多个数据中心，多个数据中心使用 1:1 的规模和自治管理体系，资源和管理分开可以有效避免单中心故障，但同时带来一个问题，如何给用户带来一致的服务体验，这时候便需要全局负载均衡器（以下简称 GSLB）入场。

GLSB 简而言之可以根据用户属性来将不同的用户引流至不同的数据中心，基于这种特性可以实现访问路径优化、提供站点级别高可用、均衡使用多个站点的计算资源。

Avi 自带 GSLB 功能，为了实现多 Kubernetes 集群业务的发布，在原来 AKO 的基础上增加了一个组件 AMKO，AMKO 用于监控多个 Kubernetes 集群中创建的 GSLB 类型的业务（通过指定的 Label 识别），然后自动调度 Avi Controller 实现 GSLB 业务的发布。

通过自动化实现自动扩缩

上文提到 Avi 的架构之下服务引擎的生命周期是由 Avi Controller 去进行管理的，如果加上合理的配置，便可以很容易实现服务引擎的自动扩缩。

Avi Controller 会同时从每个服务引擎以及 vCenter 来获取服务引擎的资源消耗情况，当发现负载均衡器集群的处理性能不足时可以动态增加服务引擎的数量，以此扩大整个集群的处理能力。下面是一个自动扩缩的动画演示：

除了服务引擎的自动扩缩外，Avi 也可以调度虚拟化平台的接口，实现业务层面的扩缩，这种实现方式很类似于以前 vRA 针对业务的横向扩容，这里限于篇幅不详细介绍。

通过自动化实现云端安全联动

负载均衡是最贴近应用的基础架构类产品，在负载均衡器上提供应用的安全增强功能变得理所应当，Avi 的架构下支持很多层面的应用保护，部分功能需要人工根据应用的特性来进行配置，部分则完全可以通过云端的联动来自动实现，例如 IP 黑名单，通过这样简单的技术可以高效阻止已知攻击源的攻击。

下图为 Avi 可以提供的多种安全功能

第二板斧：可视化

每个使用过 Avi 的用户都会被 Avi 的可视化功能折服，并不是因为 UI 有多炫，而是真的可以帮助他们解决实际的问题。

操作变更

变更是 IT 人常见的工作任务，但变更就像黑盒子，即使有再完善的测试和预案也不能保证变更的一切顺利，当变更操作完成后，往往我们需要守着电脑，围着电话等待不同部门的人来告诉我们变更是否影响到他们的业务。

有了 Avi 之后，我们则可以更加主动的观测到变更的影响。下图为某个虚拟服务的可视化分析界面，每当系统中有一个变更，在横轴上会出现一个蓝色的配置图标，以图标为界，变更前和变更后业务的访问情况一目了然，在每个时间点，我们也可以查看该时间点的会话延迟情况、吞吐、连接数、请求数等。

下图第一个蓝色图标的位置管理员手动执行了服务引擎的扩容操作，操作完成后可以明显观察到端到端延迟下降，吞吐量上升，连接数增加，证明我们的操作如预期一样，可以提高系统性能。

排错

应用集群部署时难免遇到配置不同步，或者遇到单一节点部分故障等问题，加上复杂的网络环境，出现故障时往往很难排查，在 Avi 下，定位一个故障只需要花费很少的时间。

下图是一个应用的日志访问记录，默认 Avi 会展示该应用的所有异常访问日志，将其放在 Significant Logs 中，下图中我标记了两条日志，第一条是 404 not found，说明部分用户请求页面时有文件缺失；第二条是 200，但是应用访问速度缓慢。我们以 404 问题为例来进行故障排除。

第一步，我们对 Response Code 404 相关日志进行过滤，过滤后发现 URI 是一个图片路径。

第二步，查看右侧不同分类的日志统计数，寻找问题根源。例如可以点击 Client Analytics>IP Address 来查看是不是部分终端连接时会出现 404，结果发现来自不同的 IP 的用户均会有 404 日志，表示问题应该不在 Client 侧。

接着我们点击 Load balancer Analytics>Server IP Address，查看到所有 404 日志均来自于服务器 10.79.186.200，也就说明问题可能是此服务器缺少相应路径的文件，接着我们便可以将此情况告诉应用部门，让他们检查并修复问题。

应用兼容性问题分析

当开发 Web 应用时难免碰到部分终端（浏览器）不兼容性的情况，有了 Avi 可视化之后定位兼容性变得非常简单。和上文的故障排除类似，可以使用日志可视化系统进行问题分析，我们简单的通过 Browser 类型进行过滤，即可查看这类终端访问服务器时的日志，分析是否有异常日志出现。

针对任意一个会话，可以通过 Client IP 和时间进行过滤，查看具体的 Client 请求信息、LB 处理信息以及 Server 返回信息等，帮助定位问题。

健康度一览表

默认登陆 Avi 之后会显示该用户下的所有虚拟服务，使用易于区分的色块和健康度评分来进行展示，展示的拓扑包含虚拟服务的整体健康状态、其使用的服务器池的状态、连接服务器使用的网络端口组，以及每个池成员的状态。

如果应用有红色警告，可以将鼠标悬浮在红色图标上方查看具体的故障原因。

WAF 策略配置

WAF 全称为 Web 应用防火墙，用于阻止针对业务漏洞的相关攻击。WAF 和防火墙类似，需要基于黑白名单来进行正确的防护，和防火墙不同的是，WAF 的名单要复杂的多，每个应用可能会有自己独特的黑白名单。

为了简化 WAF 上线，WAF 产品一般都会具备学习功能，将一定时间内用户的访问情况作为基线，设为白名单，剩余的流量则使用 CRS 库进行检测和过滤。

但基于白名单的 WAF 策略很容易出现误报，而且较难适应动态响应的网站，因此在 WAF 上线时避免不了人工进行防护策略的优化。Avi WAF 的可视化功能则可以帮助安全管理员快速分析应用的访问情况，优化安全策略。

下图为 Avi 的 WAF 可视化界面，我们可以设置时间范围查看该范围内 WAF 匹配到的攻击信息，默认会按照 Rule Group、Rule、Client IP、Path 等进行分组，当选择红色分组中的元素+蓝色分组中的元素，即可快速添加信任名单。

步骤如下，只需要点几下，便可以快速添加信任：

针对指定的客户端，则可以通过日志系统快速检索 WAF rejected 记录，然后查看该会话具体匹配到了哪个 Rule Group 和 Rule。点击 Rule/Rule Group 右侧的“加号”图标，便可以快速添加白名单。

第三板斧：横向扩缩

现在之所以微服务可以大行其道，很大一部分原因是微服务可以很容易地实现横向扩缩、部分服务升级、滚动升级、蓝绿发布等功能，Avi 在很多层面也可以和微服务一样灵活。

通过横向扩缩提高性能，提高资源利用率，减少故障域

负载均衡器在工作时有下列几项任务比较依赖 CPU 资源：
- SSL Termination
- WAF
- Throughput

提高上述任务性能的办法只有一个，增加更多的计算资源，而最传统的办法是纵向扩容，即给单个负载均衡器增加非常多的 CPU 核心，这种方式在工作上没太大问题，但有两个硬伤：资源利用率低，故障域大。

传统负载均衡一般都会使用 Active/Standby 或者分业务 Active/Active 这两种高可用架构，为了满足高可用需求，一般至少要预留 50% 的资源不能使用，就整体而言资源利用率低于 50%；当发生故障时，至少 1 半的应用会受到影响。

避免以上问题的方法便是横向增加负载均衡器节点（即横向扩容），将业务分散在多个小的负载均衡器节点之上，这里说的分散并不是将不同的业务运行在不同的负载均衡器节点，而是同一个业务由多个服务引擎处理，很类似于网络中等价多路径路由的工作方式。

如下图所示，Avi 支持一种名为 Elastic Active/Active 的高可用架构，可以将单个业务分散在多个 SE 上并行运行，既可以减少故障域，也可以满足应用对于性能的要求。在这种架构下，同样为 FTT=1 时，Avi 的资源利用率可以达到 80% 以上。

通过横向扩容，WAF、SSL Termination 等性能可以实现快速增长。在 Avi 中，手动扩缩只需要点击鼠标即可实现：

平滑升级

在横向扩缩能力的背后，实际上意味着底层技术可以实现业务的在线迁移，就像 vSphere vMotion 功能一样，有了这种技术，便可以轻松实现大批量的在线滚动升级。

Avi 在进行升级时升级顺序为：先升级控制器集群，再自动或者手动完成每个服务引擎组的升级。一般生产环境下用户可以针对每个 SE Group（代表一个 SE 故障域集群）计划升级窗口，组内的 SE 会进行滚动平滑升级，在此期间业务不会受任何影响。

节约 SNAT 地址池

传统负载均衡架构下，受限于单个 SNAT IP 的端口数限制（最大 65535），为了提高并发连接数一般需要使用 SNAT 地址池，SNAT 地址池一般需要在每个 VS 上进行配置，当应用规模很大时 SNAT 地址池的管理会变得很复杂。

在 Avi 的 Elastic A/A 架构下，每个 vs 至少会分布在两个 SE 上运行，而针对于每个 SE IP + SE port + Server IP + Server Port，可以有 64K 的连接数，假如一个 VS 后端有两个 Real Server，那系统可以实现的最大连接数为 2264K，这对于大部分企业用户来说已经足够，不再需要使用 SNAT 地址池来提高连接数。如果确实需要更大的连接数，可以使用 Avi 的横向扩容能力，同时提高连接数和性能，两全其美。

其他斧

除了上面提到的三板斧之外，Avi 还有很多好用的功能，例如：
- 简洁的 UI ，能够方便用户快速进行业务配置
- 100% 开放 API，方便实现第三方平台集成
- 多云支持，可以运行在任意平台
- 转控分离的架构，数据平面不会存储任何敏感的信息（例如 SSL 证书）
… …