有人用nodejs做流媒体服务器吗

倒是不用全部都自己重写，媒体解析这块node有现成的库 ，可以去搜搜看node ffmpeg，用别人封装好的ffmpeg来解析，但是在流媒体协议层这一块好像我没有搜到node关于rtmp的封装，不过现成的流媒体服务器可能有，实在不行就可能需要手动造轮子自己去给node封装rtmp了

不过最好还是不要用node直接处理流媒体处理和传输这一块，拿node来处理请求在把请求转给后台的流媒体服务器可能更好吧

手机游戏开发其实是j2me,是java语言的一个发展方向，用j2me就可以制作手机游戏以及软件，对于自学的话我个人推荐《java me 使用详解——用eclipse进行移动开发》这本书，讲解很详细，适合入门学习，从高级用户界面开始学习，然后低级用户界面，用户存储，游戏开发，这样的一个学习过程，但是说实话，你如果是自学的话入门可以，但是如果想编一个像样的游戏的话那估计难度有点大，因为在手机游戏开发过程中很多东西都是经验，很多人说j2me简单，其实说实话，是简单，不就是那11个包里的那几个类的调用吗？但是用这些类里的方法什么的结合起来编写一个游戏，那就不简单了，这时候就需要一个老师或者有经验的人给你指点一下了，就是这样。

手机游戏开发（也就是j2me）其实不难，技术性的东西不难，难就难在逻辑思考，重在算法的编写，游戏中间需要许多的NPC，这些NPC的活动都是需要你编写很多的代码来实现人工智能的，所以，加油！祝你成功！

一般只问好处，没听说过要找坏处的。

使用Nodejs搭建Web服务器是学习Nodejs比较全面的入门学习了。

因为实现Web服务器需要用到几个比较重要的模块：http模块、文件系统、url解析模块、路径解析模块、以及301重定向技术等。

Node本身运行V8 JavaScript。V8 JavaScript引擎是Google用于其Chrome浏览器的底层JavaScript引擎。Google使用V8创建了一个用C++编写的超快解释器，该解释器拥有另一个独特特征：您可以下载该引擎并将其嵌入任何应用程序。V8 JavaScript引擎并不仅限于在一个浏览器中运行。因此，Nodejs实际上会使用Google编写的V8 JavaScript引擎，并将其重建为可在服务器上使用。

更多技术问题请加qq群讨论：533677775

Nodejs优点：

1、采用事件驱动、异步编程，为网络服务而设计。其实Javascript的匿名函数和闭包特性非常适合事件驱动、异步编程。而且JavaScript也简单易学，很多前端设计人员可以很快上手做后端设计。

2、Nodejs非阻塞模式的IO处理给Nodejs带来在相对低系统资源耗用下的高性能与出众的负载能力，非常适合用作依赖其它IO资源的中间层服务。3、Nodejs轻量高效，可以认为是数据密集型分布式部署环境下的实时应用系统的完美解决方案。Node非常适合如下情况：在响应客户端之前，您预计可能有很高的流量，但所需的服务器端逻辑和处理不一定很多。

更多技术问题请加qq群讨论：533677775

Nodejs缺点：

1、可靠性低

2、单进程，单线程，只支持单核CPU，不能充分的利用多核CPU服务器。一旦这个进程崩掉，那么整个web服务就崩掉了。

不过以上缺点可以可以通过代码的健壮性来弥补。目前Nodejs的网络服务器有以下几种支持多进程的方式：

#1 开启多个进程，每个进程绑定不同的端口，用反向代理服务器如 Nginx 做负载均衡，好处是我们可以借助强大的 Nginx 做一些过滤检查之类的操作，同时能够实现比较好的均衡策略，但坏处也是显而易见——我们引入了一个间接层。

#2 多进程绑定在同一个端口侦听。在Nodejs中，提供了进程间发送“文件句柄” 的功能，这个功能实在是太有用了（貌似是yahoo 的工程师提交的一个patch） ，不明真相的群众可以看这里： Unix socket magic

#3 一个进程负责监听、接收连接，然后把接收到的连接平均发送到子进程中去处理。

在Nodejs v0510+ 中，内置了cluster 库，官方宣称直接支持多进程运行方式。Nodejs 官方为了让API 接口傻瓜化，用了一些比较tricky的方法，代码也比较绕。这种多进程的方式，不可避免的要牵涉到进程通信、进程管理之类的东西。

此外，有两个Nodejs的module：multi-node 和 cluster ，采用的策略和以上介绍的类似，但使用这些module往往有一些缺点：

#1 更新不及时

#2 复杂庞大，往往绑定了很多其他的功能，用户往往被绑架

#3 遇到问题难以解决

从大型工程的角度来说，go 是完爆 Node

的。性能，内存开销，静态类型，对异步的处理，异常的处理，可调试性，系统稳定度，工具链的成熟度，等等，都是 go 占优。但是 Node

在依赖处理方面更好，npm 对依赖版本的管理 （go 的依赖不能指定版本，还需要借助非官方的工具）非常优秀，另外 Node 社区的活跃度要比

go 好，如果你想要快速做一个东西，npm 上各种现成的包可以用。

Node 在做网站这方面，尤其是需要直接面向用户的 http

服务器这方面，有一个天然的优势，那就是前后端的语言统一。一方面可以减少切换语言的脑力成本，提高开发者的效率，另一方面可以实现前后端共享模板，从而

实现首屏服务器渲染，局部更新浏览器渲染的架构，提高首屏的加载速度。

如果你做的网站后台就是个简单的 CRUD 应用，或者是做产品原型，或者你同时还想兼顾前端，Node 会是更好的选择；但如果你的后台很复杂，需要区分各种服务，搞数据分析，分布式集群等等，那绝对是选 go。

最后，其实两者结合起来用也是完全可以的，把 Node 作为面向用户的大前端的一部分，专门负责页面的生成，后端用 go 或者其他语言实现，前后端之间通过规范的数据接口通信。

文章阅读，来自 前端之巅 去哪儿网 部分摘录

1项目分离，页面分离

第一种是项目分离，承载页面分离。他的特点是简单，快速，前端只关注浏览器方面，除浏览器端之外都是后端负责。

缺点 ：

沟通成本高，前期，前端需要使用 ng 或者代理工具调试，后期，还要把页面给到后端，并且新建一个对应的路由。

2项目分离，只是后端的页面，放到了前端项目里

后端只需要配置路由，最终上线时，由发布系统负责把前端中的页面，自动同步到后端相应的目录中。其中相应的目录需要前后端提前约定，不然后端在渲染页面的时候，就会找不到相应的文件。相比第一种方案，稍微有点进步。沟通成本会有一定的降低。

缺点 ：

不过如果需要在页面里做一些业务逻辑处理，还需要前端同学掌握和学习 velocity 语法，对于新同学而言看似掌握的了一门新语法，但实际操作起来并非想象中的流畅。

3第三种方案是使用 Nodejs 作为页面渲染层，后端只负责数据的生产工作

这也是目前阶段主要的使用方式。它的优点是前端同学对于整个页面的生命周期有完全的控制权，包括开发，调试，部署，上线以及后期的性能监控，应用监控等等。可做的事情也更多，比如使用 React SSR 做同构渲染。

缺点 ：

对于前端同学的要求也会很高，除学习前端知识外，还要学习后端知识。

整个应用都是由前端统一负责，所以还需要接收报警电话或者短信，724 小时，都在待命状态。

1一些前端开发，只关注浏览器端，服务器端开发关注很少，或者根本就不关注 ;

2认为 Nodejs 只适合开发一些工具类的功能，相对于后端开发来看它只是个玩具 ;

3Nodejs 的生态不如其他后端语言生态健全 ;

4涉及到后端开发的知识面比较广，在没有这些基础知识或者经验积累的基础上，考虑问题比较片面，最终做出的系统问题比较多，容易被后端鄙视 ;

看似问题很多，但实质上只有两个原因，

1，自身知识储备不够。

2，对 Nodejs 了解不深，不敢应用在生成环境中，即使应用到生产环境，一旦出现问题，不能快速及时的处理，导致高层认为还不如其他后端语言稳定，降低了我们的话语权。 (很中肯，不摸底，不敢用于项目)

1，提高开发效率，因为有了 Node 之后就不需要配置 Nginx 了，也不需要配置一些代理工具了，所有的页面生命周期都是由前端统一去管理的，这时候不需要其他人进行合作。

2，降低沟通成本，除了接口格式外，不需要和后端进行交互了；

3，前后端职责也更为清晰，因为这时候，界限更为清晰了，后端只负责生产数据，它只提供数据就可以了，至于数据怎么消费，以及怎么用，都由前端去做；

4，可以同时使用 React SSR 技术，做到首屏渲染，提高用户体验，除了首屏之外，还可以做异步的加载、SEO 等操作。

5，Nodejs 可提供一些服务，不仅能让我们使用，还可以对外使用，如 RESTful API，这样就不用有求于后端了。

/---------------------------------------------文章摘录结束-------------------------------------------------/

除了号称nodejs界jQuery的express，

另外两个比较不错的

一个是 360 团队的 Thinkjs ，

一个是阿里的 Eggjs