数据平面不是商品，为何将它当作商品对待？

本文转载自 The New Stack。

宝马公司是一家汽车制造商，设计精美的驾驶设备意味着它们的每个部件都价格不菲。举例来说，许多型号的更换轮胎都售价每条 250 美元，并且必须从经销商处购买。这些轮胎通常需要宝马公司与制造商密切合作，根据汽车的驱动方式量身定制而成。虽然你可以购买打折的普通轮胎，但这会降低汽车性能。

同样，如果您已经打算要倾注大量时间和精力来实施 服务网格 和 Kubernetes 了，又何必使用不成熟的、经过极少测试的数据平面呢？它的编程语言甚至都不能保障处理线速应用的流量。事实上，微服务的好坏与数据平面有很大关系，数据平面直接影响着客户的性能体验。微服务有什么问题，看数据平面就知道了。数据平面能够最先、最敏锐地感受到扩展需求。响应缓慢的数据平面会降低整个 Kubernetes 引擎的速度，并且会影响系统性能。

与轮胎一样，数据平面也相对容易更换。您不必大费周章就可选取一个看中的数据平面并将它安装到您常用的服务网格和 Kubernetes 平台上，但是要小心，不同的选择，结果可能有很大的差别。

数据平面决策指导清单

当您构建 Kubernetes 环境并选择服务网格时，这有一份清单可供参考。清单涵盖了挑选数据平面（例如 Ingress 控制器 或 反向代理 解决方案）时需要考虑的关键问题，可以帮助你顺利将数据平面整合到 Kubernetes，并确保获得所需的出色性能。最重要的是，你要想想你的数据平面能否满足服务网格和应用提出的性能要求。

1、这个数据平面已经上市多少年了？

我们说 Linux 和 MySQL 等软件是生产环境最值得信赖的选择是有充足的理由的。它们已长期用于在严苛环境中大规模交付应用。理想情况下，您的数据平面最好应该已经上市十年以上。诚然，这比许多 Kubernetes 部署还要早。然而，实际上数据平面的核心是执行负载均衡器和反向代理多年来所做的工作，即 HTTP 流量服务、整形和保护。我们没有理由不站在巨人的肩膀上，部署久经时间考验，被大型企业和机构放心用在生产环境中去支持最关键应用的那些核心技术。

即使你刚开始没有在 Kubernetes 中运行任务关键型工作负载，但总有一天你会的。服役久、资历深对数据平面来说很关键。

2、它的容量是多少？

大多数数据平面都会发布关于每秒连接数或事务数的容量数据以及资源消耗要求。这就需要赌一把了。如果容量偏低，那么当需要扩展到高容量时，你要么更换数据平面，要么构建一个可以水平扩展的系统，但这都会增加成本和复杂性。至于那些容量数字，则要保持怀疑的态度。基本容量数字并不能反映全况，并且初始资源使用量通常会在负载下呈指数级增长，一旦数据平面开始处理安全流量，这种 CPU 占用率低的优势就会消失。

要真正了解数据平面在特定环境中的表现，你需要进行大规模测试，并向有生产环境使用经验的人请教。有时数据平面还没达到容量阈值，性能就下降了。因此，你需要看看数据平面的容量验证测试，并亲自验证数据平面是否与宣传的一致。

3、它是否具有你将来需要且想要的集成功能？

服务网格、Kubernetes 环境和应用是非常有活力的系统。随着企业的发展，你可能还需要不同类型的应用。不同的团队可能会选择使用不同的语言、数据存储、应用服务器和框架来交付应用。集成性差的数据平面将会限制这些选择，让你的团队陷入困境。

举例来说，如果某个团队想要使用图形数据库限制所需的 API 调用次数，那么这将需要一个可以在多数情况下轻松支持 GraphQL 的数据平面。在计算数据平面能否满足未来需求时，不妨多去了解一下它的集成能力以及支持数据平面的公司或社区是否正在快速进行集成创新。

4、它如何衡量并提供可观察性？

停机是不可避免的。我们真正需要思考的是，应用停机的成本是多少？你的数据平面如何处理灾难性故障？在开发集群中，故障成本微乎其微甚至干脆没有。而在生产集群发生停机的成本就很高并会快速累积，如果你的平台无法及时提供对整个平台的洞察和可观察性，那么问题将更加严重。这可能会影响其他应用，导致客户和关键业务流程掉线，并引发安全漏洞。在数据平面上拥有能够近乎实时地解决停机问题的可视化工具非常重要，有助于快速追踪停机事件及其根本原因。还有一点也很重要：无需精通日志文件或时间序列解析的人员，便可灵活、快速、轻松地访问应用和服务数据。

5、它能否从灾难性故障中动态恢复？

为了快速恢复，服务网格必须能够动态响应基础架构和应用故障。在 Kubernetes 领域，动态是一个相对的概念。虽然我们经常使用 Kubernetes 作为弹性控制平面，但有些事情是 Kubernetes 无法控制的，例如 pod 可用性时间。在有些云平台中，动态意味着五分钟内快速重启。但在有些云中这一速度更快。在 Kubernetes 中，我们倾向于以秒为单位测量动态重启时间。因此，务必要了解服务网格和底层云平台从故障中快速恢复的实际能力。反向代理 sidecar 可以说是网格中最重要的组件。就像那些打折的轮胎一样，如果 sidecar 坏了，服务到服务的流量就会停止。集群中运行的所有应用都将停止工作。

你是否确定你的 Sidecar 代理可提供企业级弹性和恢复能力？如果不确定，那么就要小心了，你对服务网格的选择可能存在较大的风险。

结论：数据平面很重要，要择优而选。

这并不是说“服务网格的其他部分不重要”。如果你的控制平面不好用，无法有效帮助你管理和了解服务流量和应用拓扑，那么可能就会给服务网格拖后腿。我们在选择服务网格时，也要重视服务网格中接触客户及其他服务最多的组成部分，也就是数据平面。就像好车要配好轮胎一样，一个好的数据平面会成就一个响应敏捷、快速、可靠和适应性强的服务网格。