Node.js / Express Netflix问题
我对Netflix和Express遇到的这个问题有点困惑。 他们开始在API中看到延迟的构build。 我们使用快递的一切，我想避免任何突然的问题。
这里有一篇文章的链接。
http://www.infoq.com/news/2014/12/expressjs-burned-netflix
它的写法，这听起来像是一个问题，以及如何处理路由。 但是最后他们提出以下几点：
“在深入了解源代码之后，团队发现了这个问题，它驻留在一个周期性的函数中，每小时执行10次，主要目的是刷新来自外部源的路由处理程序。该function将停止添加重复的路由处理程序，延迟和CPU使用率增加消失。
我不明白他们到底在做什么。 我不相信这是Express自己做的事情。 听起来他们做了一些古怪的事情，但没有成功。 我想负载testing会揭示这一点。 无论如何，谁能更好的理解这个问题谁能评论一下这个问题呢？ 文章顶部的整个部分讨论Express如何通过路由列表进行轮换，但是我真的不知道如何迭代不应该是一个非常大的数组会导致很大的延迟。
这个我见过的最好的对应解释是Eran Hammer的 。 评论也很有启发。 特别感兴趣的是以下摘自Yunong Xiao（Netflix的作者）的评论：
我们遇到的具体问题不是全局处理程序，而是使用简单stringpath的快速静态文件处理程序。 我们每次刷新路由时都添加相同的静态路由器处理程序。 因为这个路由处理程序在全局路由数组中，这意味着每个由我们的应用程序提供服务的请求都必须遍历这个处理程序。
这绝对是我们错误的使用Express API造成的 – 毕竟，我们正在泄漏特定的处理程序！ 但是，Express 1）没有在全局路由数组中使用简单的string存储静态处理程序，并且2）拒绝了重复的路由处理程序，或者3）没有花费1ms的CPU时间来仅仅遍历这个静态处理程序，那么我们就不会经历如此剧烈的性能问题。 Express会掩盖我们有这个漏洞的事实 – 也许这会让我们以另一种微妙的方式走上一条路。
我们的应用程序有超过100个GET路由（甚至在不断增长），即使使用Express的路由器function – 可以让你为全局路由数组中的每个path组成一个处理程序数组，我们仍然需要遍历每个请求的所有100个处理程序。 相反，我们构build了自己的自定义全局路由处理程序，它接受请求（包括其path）的上下文，并返回一组特定于请求的处理程序，以便我们不必遍历不需要的处理程序。
这是我们的实现，它将每个请求所需的全局处理程序与特定于每个请求的处理程序分开。 我确定有更好的解决scheme。