到目前为止，我一直没有写这篇博文…但是今天在我的邮箱里我看到了以下：是的，因为PayPal从Java到节点.js。让我们先把一件事弄清楚……那就是"更快"的虚拟机……我喜欢JVM。我认为这是一个极好的工程。当它第一次问世时，Java很慢…但是到了2006年它已经相当快了。当时，当我用Java编写web应用程序时，我哥哥要求帮助我使用不同的蛋白质折叠建模算法。我用Java开发了其中的几个，并开始运行它们，同时在C中手工调整算法。早在2006年，当第一个10000次迭代通过JVM的全流优化时，我就开始运行它们了。我最拿手的C版算法比JVM慢了至少20%，所以我的第一反应是"我在手工调优C时一定没用"，于是我在Java中实现了一个蛋白质折叠的标准算法，并将其与我兄弟的主管花了大量资金进行优化的同类最佳本机代码版本进行了比较……在达到编译阈值之后，JVM在服务器模式下的速度仍然更快当然，在…10%到15%之间的原因是JVM可以针对它运行的确切的CPU架构进行优化，并且可以从调用流分析以及其他方面获益。那是Java 6。节点.js在v8javascript虚拟机上运行。这是一个非常快速的JavaScript虚拟机。在处理JavaScript时，您有一个优势，因为JavaScript是单线程的，您可以进行JVM无法实现的各种优化，因为****Java虚拟机必须处理潜在的多线程代码。V8的缺点是它处理的是JavaScript，这种语言可以为虚拟机提供少得多的提示。类型信息必须被推断出来，一些JavaScript编程模式几乎可以进行这种类型推断不可能。所以哪个虚拟机更快，V8还是JVM？我相信，当你在任何一个虚拟机的最基本的构建块（即JavaScript与JVM字节码）中编码时，JVM每次都会胜出。如果你开始比较高一点，你可能最终会比较苹果和橘子，看到错误的比较。例如，如果我们考虑V8与JVM在数学计算方面的性能比较。这篇博文告诉我们，如果我们放松我们的规范，我们可以更快地计算。这是V8必须使用的规格数学.pow下面是JVM必须用于的规范数学.pow请注意，JavaScript规范允许"依赖于实现的近似值"（精度未指定），而JVM版本还添加了计算结果必须在精确结果的1ulp以内。结果必须是半成品-单调的。还有对于何时可以将数字视为整数还有其他限制。V8有更快的版本数学.pow因为它正在实现的规范允许更快的版本。如果我们摆脱了JVM运行时规范的束缚，我们可以（如果你阅读博客文章的话）得到同样快的结果……如果结果证明我们甚至不需要V8的实现的准确性，我们可以做出更多的取舍，更快表演。我的重点是这个：你会的看看人们抛出的微基准测试表明JVM比V8快或者V8比JVM快。除非这些基准测试进行相似的比较，否则这两个虚拟机之间固有的规范差异可能会使这种比较毫无用处。一个有效的比较将是说纳肖恩或戴恩斯和V8。至少我们是在同一规格的基础上进行比较……贝宝比较的是什么？以下是我们对PayPal最初的Java ap的了解复制：它使用他们基于Spring的内部框架在最小负载下，最好的页面呈现时间是233msIt，它的伸缩性不是很好，达到了每11个请求的水平第二，这里是我们对贝宝的了解节点.js美联社复制：它使用他们的内部克雷肯.js我们比较了两个最差的应用程序的可伸缩性，因为我们比较了两个最差的应用程序的frametime和24msit节点.js一个比例稍微好一点节点.js比Java好。我只能说一件事…我们可以得出的结论是，基于Spring的内部框架对于手头的任务来说过于复杂。施瓦茨男爵说：真的吗？在Java中，单个用户的页面数为1.8页/秒，而在Node.js？如果延迟的时间真的归咎于应用程序和运行它的容器，那么这就太低了。如果它所依赖的API调用不是很慢，我希望看到每秒数百个页面，如果不是数千个甚至更多。有人需要解释更多彻底的。谁也就是说，如果他们把Java应用程序构建在一个更现代的框架上，他们能够达到什么样的性能。Spring带来了很多功能。功能可能太多了。大多数人正在从单一的应用程序转移到更小更轻量级的框架……但是如果你有一个公司授权的框架，你必须在内部开发Java应用程序时使用……那么你可能没有太多选择。另一方面，如果你转移到一个不同的技术栈，可能没有你必须的公司框架使用。现在我们得到了第二个"好处"，即更快发展。我们从PayPal的博客文章中得知，在比较点上，两个应用程序具有相同的功能…我们确定吗？基于Spring的内部框架"免费"带来了多少功能（或者更准确地说是性能成本）？我并不是在为内部的Spring框架辩护，但我确实觉得认为这两个应用程序提供了完全相同的功能是不合理的。我相信上下文特定的功能测试是由两个应用程序通过的。所以这告诉我们用户不会看到两个应用程序之间的区别。但是记录请求、事务等呢？可伸缩性和负载报告呢？我不想为内部Spring框架辩护，部分原因是我发现Spring从一开始就是一个过火的框架，但是这个框架可能会带来更多的东西。如果我们抛开所有这些额外的"优点"，Java开发人员是否能够更快地开发应用程序？如果我们问节点.js开发人员添加所有这些额外的"优点"，他们是否能够以同样快的速度交付？我们很可能不知道这些问题的答案，但我们所知道的是，内部框架增加的额外"好处"似乎是浪费时间，因为他们很乐意投入生产，没有他们。进来换句话说，内部框架听起来有点像其中之一（至少从编写这个特定应用程序的人的角度来看）：因此，当您从内部框架的束缚中解脱出来后，您可以开发应用程序，这一点也不奇怪，在减少33%的代码行和减少40%的文件…作为一个基础框架，Spring喜欢有很多小文件和大量的样板文件，即使有注解，Spring也可能是XML的重量级如果你使用的是一个更现代的基于Java的框架，很可能你不会有同样的限制。例如，我喜欢使用Jersey作为我的基本框架，我发现它只需要很少的样板文件，并且可以帮助您避开许多开发人员陷入的多线程货物邪教。节点.js也可以帮助你远离多线程的货物邪教…强迫你生活在一个单一线程世界。好的，因此内部框架过于成熟，确实提供了非常糟糕的性能，因此我们只剩下的好处是js节点版本的制作速度几乎是原来的两倍，当你在一个紧密的代码库中工作时，两个人的开发速度要比五个人的团队快。应用程序本身有三条路径。如果你有一个最多由三个开发人员组成的团队，你要给每个人一个路由，让他们把这个路由的代码发送出去。如果你有三个以上的开发人员，你将有一个以上的每一个路线，这意味着他们要么结束结对编程或踩到对方的脚趾。再加上交付规范中不明确的差异，即内部框架增加的"优点"……这需要在你走出大门之前连接起来……我们真正能说的是，这充其量可能是一个不公平的比较，最坏的情况是苹果对桔子比较。所以我们能得出什么结论？@乔姆卡恩。。。有时候你需要抛弃旧的平台，这样管理层会让你从头开始重写…-斯蒂芬·康诺利（@Connolly_s）2013年11月25日，当我阅读PayPal博客时，我最初的想法是，在这个应用程序的范围内，内部框架是在过度烘焙的Spring框架之上过度设计的，它可能不会给桌面带来太多实际价值，只会带来显著性能方面的成本打中了。有吗构建在JVM之上的解决方案在技术上能够与内部"集成"框架唯一的政治途径避免内部框架被抛弃JVMNode.js同时"足够酷"和"足够严肃"成为一个有效的非JVM候选者（你可以试试Ruby，但这已经有足够长的时间了，很可能也有一个内部框架来实现这一点……无论如何，你可以在JVM上运行Ruby……所以这可能不是你需要的逃避）我给你带回家，一个读过我在这篇文章中漫不经心的读者…不要把你的应用建立在一堆垃圾上框架.PayPal可能已经抛弃了一堆基于Spring的垃圾框架。不清楚的是什么