关于数据平面不是商品，为何将它当作商品对待2023/7/3 9:49:45

sqz920 · 发表于 2023-7-3 09:49:46

本文转载自TNS。时至今日，人们对NGINXPlusAPIGateway也有着很多的依赖性，对产品的预期也越来越高。NGINX 已成为 F5, Inc 的一员，而 F5, Inc 则是当前全球热门的开源项目 NGINX 背后的公司。https://www.nginx-cn.net/products/nginx/api-gateway/[align=center]https://www.nginx-cn.net/wp-content/uploads/2023/06/tutorial-deploy-configure-microservices_code-review-768x425-02.png[/align]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

		自动登录	找回密码
密码			立即注册