。

近来#xff0c;为了从新版本的性能改进和新功能中受益#xff0c;我们将

Node.js

这样的基础设施绝非易事#xff0c;尤其是有着许多第三方依…在

Tubi我们使用

应用进行服务端渲染及代理请求。

近来为了从新版本的性能改进和新功能中受益我们将

Node.js

这样的基础设施绝非易事尤其是有着许多第三方依赖的大型项目因为我们无法预测可能会出现的问题。

在升级过程中我们很快便遇到了第一个问题服务器端发送的每个请求都会失败并返回

404

库发送请求复现了该问题request.get(https://foo.bar/get)服务端返回了包括

404

模块来发送请求。

为了探究发送请求时究竟发生了什么我们又给测试添加了NODE_DEBUGhttp,net

{cat:node,node.http,name:http.client.request,args:{data:{path:/}}}

https://foo.bar/get但

库但这两个案例都无法复现这一异常情况。

这让我们开始怀疑我们的代码库中是否有可能存在问题

在深入研究代码库之前我们在该库

require(./path/to/local/https);

现在我们可以打印日志、添加断点了还可以直接修改模块代码。

我们还发现了更多线索http(s)

模块接受

URL.search。

而这个库传递的对象上不存在这些属性于是导致了真正发出的请求中

path

https://github.com/nodejs/node/blob/36c72c8b2fb03414e02ffd8402c05129647ce123/lib/https.js#L367C5-L369

function

urlToHttpOptions(ArrayPrototypeShift(args));}

https://github.com/nodejs/node/blob/36c72c8b2fb03414e02ffd8402c05129647ce123/lib/internal/url.js#L1322C1-L1344

function

https://github.com/nodejs/node/blob/36c72c8b2fb03414e02ffd8402c05129647ce123/lib/internal/url.js#L761

function

都存在各自的问题所以修复这一问题将变得十分棘手但问题的根源在于

Node.js

呢虽然我们可以这样做但这并不是一个最理想的解决方案因为其他属性可能会引起性能问题。

isURL

的这一评论做了深入思考“这有点像鸡生蛋还是蛋生鸡的问题我们既不能检查

URL

由多个第三方库交互而引发的问题可能很难调试与修复但有一种方法是从底层开始逐步追踪问题的源头将其分解为更小的问题以更容易处理。

这相当于在代码中放置了一个定时炸弹它最终一定会爆炸。

我们在实践中便遇到了这一问题。

我们有计划替换已弃用的库但在工作完成之前这一定时炸弹就爆炸了。

patch

http(s)会使调试变得更加困难尤其是对于第三方库工程师们应避免这种做法。

Tubi

升级过程中出现的未预期的请求问题。

我们快速锁定了由第三方依赖引起的

URL

对象检测变化是这一问题的根源。

如果你和我们一样对这一类问题的解决感兴趣欢迎加入我们

Tubi