Node.js的事件驱动有什么不同?我们不能在ASP.Net的HttpAsyncHandler中这样做吗?

我在网络编程方面不是很有经验, 我还没有在Node.js中编写任何代码,只是对事件驱动的方法感到好奇。看起来确实不错。 本文解释了当我们使用基于线程的方法处理请求时可能发生的一些不好的事情,并且应该选择事件驱动的方法。 在基于线程的情况下,收银员/线程一直困扰着我们,直到我们的食物/资源准备就绪。在事件驱动下,收银员将我们送到请求队列之外的某个地方,这样我们就不会在等待食物时阻止其他请求。 要扩展基于阻塞线程,需要增加线程数。 对我而言,这似乎是一个不正确使用线程/线程池的错误借口。 难道不能使用IHttpAsyncHandler正确处理? ASP.Net接收请求,使用ThreadPool并运行处理程序(BeginProcessRequest),然后在其中我们使用回调加载文件/数据库。那个线程应该可以自由处理其他请求。文件读取完成后,再次调用ThreadPool并执行剩余的响应。 对我来说没有那么不同,那为什么不那么可扩展呢? 我所知道的基于线程的缺点之一是,使用线程需要更多内存。但只有这些,您才能享受多核的好处。我怀疑Node.js根本没有使用任何线程/核心。 因此,基于事件驱动vs基于线程(不要带“因为它是Javascript和每个浏览器...”的论点),有人可以指出我使用Node.js而不是使用Node.js的实际好处是什么现有技术? 这是一个很长的问题。谢谢 :)     
已邀请:
首先,Node.js不是多线程的。这个很重要。你必须是一个非常有才华的程序员来设计在线程环境中完美运行的程序。线程很难。 你必须是一个上帝来维护一个没有正确设计的线程项目。在非常大的项目中,有很多问题难以避免。 其次,整个平台被设计为异步运行。您是否看到过每个IO交互都是异步的ASP.NET项目?简而言之,ASP.NET并非设计为事件驱动的。 然后,由于我们每个开放连接有一个线程和整个扩展问题,因此存在内存占用。如果我错了,请纠正我,但我不知道如何避免为ASP.NET中的每个连接创建新线程。 另一个问题是Node.js请求在没有被使用或等待IO时是空闲的。另一方面,C#线程休眠。现在,可以睡眠的这些线程的数量是有限的。在Node.js中,您可以在一台开发机器上同时轻松地同时处理10k个客户端。您尝试在一台开发计算机上并行处理10k个线程。 JavaScript本身作为一种语言使异步编码更容易。如果你还在C#2.0中,那么异步语法真的很痛苦。如果你在整个地方定义
Action<>
Function<>
并使用回调,很多开发人员会感到困惑。以普通方式编写的ASP.NET项目无法由普通的ASP.NET开发人员维护。 至于线程和核心。 Node.js是单线程的,可以通过创建多节点进程进行扩展。如果你有一个16核,那么你运行你的node.js服务器的16个实例,并在它前面有一个Node.js负载均衡器。 (如果你愿意,也许是一个nginx负载均衡器)。 这一切都是从一开始就以极低的水平写入平台。这不是后来的一些功能。 其他优点 Node.js还有更多内容。以上只是Node.js处理事件循环的方式比使用ASP.NET中的异步功能更好的原因。 性能。它很快。真快。 Node.js的一大优势是它的低级API。你有很多控制权。 您将整个HTTP服务器直接集成到您的代码中,然后外包给IIS。 你有整个nginx与Apache的比较。 整个C10K挑战由节点处理,但不由IIS处理 AJAX和JSON通信感觉自然而轻松。 实时通信是Node.js的一大优点。它是为它而制造的。 与基于文档的nosql数据库很好地配合使用。 也可以运行TCP服务器。可以进行文件写入访问,可以在服务器上运行任何unix控制台命令。 您可以使用例如CouchDB和map / reduce在javascript中查询数据库。您使用JavaScript编写客户端。在Web堆栈上进行开发时,没有上下文切换。 丰富的社区驱动的开源模块。 node.js中的所有内容都是开源的。 占地面积小,几乎没有依赖性。您可以自己构建node.js源代码。 Node.js的缺点 这个很难(硬。它很年轻。作为一名熟练的JavaScript开发人员,我在使用Node.js编写网站时遇到了困难,因为它具有低级特性和我的控制级别。它感觉就像C.很多灵活性和力量要么用于我,要么挂我。 API未冻结。它正在迅速变化。我可以想象必须在5年内完全重写一个大型网站,因为届时Node.js的数量会有所改变。它是可行的,您只需要知道node.js网站上的维护并不便宜。 进一步阅读 http://blog.mixu.net/2011/02/01/understanding-the-node-js-event-loop/ http://blip.tv/file/2899135 http://nodeguide.com/     
关于node.js与ASP.Net和异步编程有很多误解。您可以在ASP.NET中执行非阻塞IO。当您使用.Net 2.0及更高版本中的开始/结束模式执行Web服务调用或其他I / O绑定操作时,大多数人都不知道.Net框架使用下面的Windows iocompletion端口。 IO完成端口是Windows操作系统支持非阻塞IO的方式,以便释放应用程序线程,以便IO操作完成。有趣的是,node.js通过Cygwin在Windows中使用了不太优化的非阻塞IO实现。路线图上有一个新的Windows版本,在微软的指导下将使用IO完成端口。在那一点上,没有区别。 也可以在ADO.NET中进行非阻塞数据库调用,但要注意ORM工具,如NHibernate和Entity Framework。它们仍然非常同步。 同步IO(阻塞)使控制流程更加清晰,因此它变得流行。计算机环境是多线程的原因只是表面上与此有关。它通常与多个CPU的时间共享和利用有关。 只有一个线程可能会在冗长的操作中导致饥饿,这可能与IO和复杂的计算有关。所以,即使经验法则是一个线程pr。当使用非阻塞IO时,仍应考虑足够的线程池大小,以便简单的请求不会因更复杂的操作(如果存在)而变得不足。多线程还允许在多个CPU之间轻松分割复杂操作。像node.js这样的单线程环境只能通过更多进程和消息传递来协调动作来利用多核处理器。 我个人还没有看到引入其他技术如node.js的任何令人信服的论点。但是,可能有很好的理由,但我认为它们与通过非阻塞IO服务大量连接几乎没什么关系,因为这也可以通过ASP.NET完成。 BTW tamejs可以帮助使你的nodejs代码更具可读性,类似于即将推出的新的.Net Async CTP。     
很容易低估Node.js和ASP.NET社区之间的文化差异。当然,IHttpAsyncHandler存在并且它自.NET 1.0以来一直存在,所以它甚至可能是好的,但围绕Node.js的所有代码和讨论都是关于异步I / O,而在.NET方面则绝对不是这样。想使用LINQ To SQL?你有点可以,有点儿。想记录东西?也许“CSharp DotNet Logger”可能会起作用。 所以是的,IHttpAsyncHandler就在那里,如果你真的很小心,你可以编写一个事件驱动的web服务,而不会在某个地方绊倒一些阻塞I / O,但是我并没有真正得到很多人使用的印象它(当然它不是编写ASP.NET应用程序的突出方式)。相比之下,Node.js是关于事件I / O,所有代码示例,所有库以及它是人们使用它的唯一方式。因此,如果您打算在哪个I / O模型实际上一直工作,那么Node.js可能就是那个。     
根据当前时代的技术改进和阅读下面的链接,我可以说,这是专业知识的问题,并根据重要的特定情况选择完美的组合。 NodeJS越来越成熟,ASP.NET方面我们有ASP.NET MVC,WebAPI和SignalR等,以使事情变得更好。 Node.js与.Net的性能 http://www.salmanq.com/blog/net-and-node-js-performance-comparison/2013/03/ 和 http://www.hanselman.com/blog/InstallingAndRunningNodejsApplicationsWithinIISOnWindowsAreYouMad.aspx 谢谢。     

要回复问题请先登录注册