储存javascrip脚本的文件。server.js是一个服务器js文件，作用是储存javascrip脚本的文件。文件属于文件的一种，与普通文件载体不同，文件是以计算机硬盘为载体存储在计算机上的信息集合。

首先，需要安装nodejs，这个可以去官网下载，目前我本地安装的v0.12版本。

安装完成后可以通过命令行测试安装是否成功，输入：node -v，应该会显示当前安装node版本号。

本文中用到的模块，都是nodejs核心模块，不需要从外部下载，如果有需要，可以使用以下命令安装：npm install xxx。

开始

下一步，新建js文件，可以命名为server.js，代码如下：

var http = require('http')

var url = require('url')

var path = require('path')

var fs = require('fs')

var dir, arg = process.argv[2] || ''// 命令行第三个参数，用来接收目录，可为空，相对当前server.js文件的目录名称

// 比如使用命令 node server debug，意思就是debug文件夹与server.js文件同级

// 且你想以debug文件夹启动web服务

http.createServer(function (req, res) {

var pathname = __dirname + url.parse(req.url).pathname

[linux运维] 1、下载最新node.js二进制源码安装包(29MB),V8.2.1更新于2017年7月20日 

wget -c https://nodejs.org/dist/v8.2.1//node-v8.2.1.tar.gz

wget是一个Linux下载文件的工具，centos自带。

wget -c 是断点续传下载方式,后面的URL就是提供下载文件的地址

默认获取的文件地址在/root目录下,命令pwd显示当前目录.

  2、安装必要的编译软件 吖米yum install gcc gcc-c++ yum = Yellow dog Updater, Modified。改良黄狗更新器,centos自带智能包管理器。 中途询问,输入y：在线下载安装 d：只下载不安装 N：不下载不安装

Is this ok [y/d/N] :y

  3、解压源码tar -zxvf node-v8.2.1.tar.gz当前目录/root/就会多一个node-v8.2.1的文件夹-z:透过gzip的支持进行压缩/解压缩：此时文件名最好为*.tar.gz-x：解压缩的功能-v:在压缩/解压缩的过程中，将正在处理文件名显示出来

f filename:-f后面要立刻接被处理的文件名.

  4、编译node源码包 1)进入到node源码包解压目录 cd node-v8.2.1指定NodeJS安装位置./configure --prefix=/usr/local/node 不指定prefix，则可执行文件默认放在/usr /local/bin，库文件默认放在/usr/local/lib，配置文件默认放在/usr/local/etc。其它的资源文件放在/usr /local/share。你要卸载这个程序，要么在原来的make目录下用一次make uninstall（前提是make文件指定过uninstall）,要么去上述目录里面把相关的文件一个个手工删掉。 执行安装文件，足足等了40多分钟

make && make install

  4、添加环境变量  > 创建并打开新文件 不存在node.sh文件 [root@localhost node-v8.1.3]# vim /etc/profile.d/node.sh > 输入node安装位置的bin目录所在位置 export PATH=$PATH:/usr/local/node/binESC 输入:wq 提示: 命令输入错了vim-bash: rt: command not found-bash: vim: command not found[解决]i. 那么如何安装 vim 呢?输入rpm -qa|grep vim 命令, 如果 vim 已经正确安装,会返回下面的三行代码:root@server1 [~]# rpm -qa|grep vimvim-enhanced-7.0.109-7.el5vim-minimal-7.0.109-7.el5vim-common-7.0.109-7.el5 如果少了其中的某一条,比如 vim-enhanced 的,就用命令 yum -y install vim-enhanced 来安装:yum -y install vim-enhanced 如果上面的三条一条都没有返回, 可以直接用 yum -y install vim* 命令yum -y install vim*  使用su root source /etc/profile.d/node.sh =. /etc/profile.d/node.sh [不间断运行nodejs服务]https://yq.aliyun.com/ziliao/3411 npm install forever -g forever start app.js

在软件开发领域，前端工程师曾经是一个比较纠结的职业。在Web技术真正发展起来之前的相当长一段时间里，由于技术门槛很低，前端工程师行业一直是鱼

龙混杂的状态。其中很多号称是Web开发者的人实际上并没有什么专业的前端技能，有些工作就是被当做简单的力气活由美术设计师顺便做做而已。当时很多人甚

至并不认为有朝一日会有这么一群人用HTML、CSS和JavaScript这三门技术谋生——他们想，这怎么可能呢——这些技术看起来都是如此简单，随

随便便混在一起用就哦了，把做这些活看成一种正儿八经的职业简直是笑话。

随着技术发展，人们对前端工作的看法开始改变了，一些人从美工页面仔真正转变为专业的前端工程师。JavaScript，这门很多工程师曾经把它当做

玩具而不屑一顾的脚本语言悄然演变成推动互联网发展的核心驱动力。伴随着越来越多的浏览器的出现使得用HTML和CSS兼容各种浏览器变得越来越难，于是

能实现兼容各种浏览器的页面成为了前端工程师的金字招牌，前端职业开始变得炙手可热。

两个独立的UI层

即使Ajax这种技术风靡全球之后，前端工程师的主要工作曾经也仅局限于浏览器窗口之内。HTML、CSS和JavaScript是前端工程师必须要

掌握的三种核心技术，前端同后端的唯一交集仅仅是前端需要确保后端的数据能够以正确合适的格式输出到浏览器上。在某种意义上来说，Web开发有两个UI

层，一个是在浏览器里面我们最终看到的，另一个在server端，负责生成和拼接页面。因为传统前端基本上没有办法自主决定server端如何处理数据拼

接生成页面，因为数据如何组织，往往是会受到后端工程师所选择的技术框架的影响的，而后端不理解前端的一些需求，所以他们选择的时候也就很少会从前端方便

的角度进行考虑。

在上面这张图的结构里，浏览器里的UI层是完全归前端工程师管的。服务器端的UI层则是前后端都关心的部分，剩下的部分是服务端的底层，诸如数据处

理、缓存、权限控制和其他核心模块，这些是归后端管的。我们还是回过头来看我们所关心的server端UI层吧，这一层所做的事情通常是拼页面模板以及处

理具体的业务交互逻辑。

所以，传统的前后端分工是由前端负责浏览器，而其他浏览器之外的东东统统归由后端负责。前后端的交集server的UI层也是由后端来主导的。这是目前最主流的一种前后端分工方式。

让Node.js来改变这一切

Node.js一发布，立刻在前端工程师中引起了轩然大波，前端工程师们几乎立刻对这一项技术表露出了相当大的热情和期待。上一次一种技术能被整个前

端界如此关注那还是在几年之前，那时候Ajax这个概念刚刚被提出来。让JavaScript跑在server端，这个想法简直太棒了。这下我们不用再去

学那些什么PHP啦、Ruby啦、Java啦、Scala啦或者其他什么对前端来说奇怪的语言，也可以轻松地将我们的领域扩展到server端，多么美好

的前景!

我从来不是一个PHP的爱好者，但是我在Yahoo工作的时候，我不得不使用PHP。为了这份工作，我得忍受花费许多额外的时间去修复由于PHP的傻

逼特性导致的坑。对于一直使用Java作为服务端语言的我来说，对PHP实在是很难适应。我相信，也一直坚持认为一种静态类型的语言更加适合用来构建你的

业务逻辑的核心部分。因此，虽然我很喜欢JavaScript，但我也不会用它来做所有的事情，比如我绝对不会只用JavaScript来实现一个完整的

购物车系统。

对于我来说，Node.js不是一个解决一切问题的银弹，我不会用它来取代server端所有别的语言模块。事实上，Node.js可以做到其他后端

语言所能做到的几乎所有的事情，但是我不会这么做。我所认为的比较合适的做法是用Node.js来解决server端UI层的问题，这样我就可以将这一层

从后端的其他部分剥离出来。

现在越来越多的公司倾向于采用面向服务(service-oriented)的架构，由后端提供给前端RESTful的接口，这么做是为了更好的做前

后端的依赖分离。如果所有的关键业务逻辑都封装成REST调用，就意味着在上层只需要考虑如何用这些REST接口构建具体的应用。那些后端程序员们根本不

操心具体数据是如何从一个页面传递到另一个页面的，他们也不用管用户数据更新是通过Ajax异步获取的还是通过刷新页面，当然他们更不关心的是你究竟在用

jQuery还是YUI——这与他们根本毫无关系嘛。后端程序员真正应该关心的难道不应该是数据如何存储、如何容错以及如何保证安全性吗?

现在我们看看Node.js带来的好处吧，当后端程序员提供了REST服务之后，现在我们前端程序员可以使用Node.js来处理server端的

UI层啦，我们可以将通过REST调用拿到的数据随心所欲地进行处理，不管是渲染模板还是直接提供给Ajax，现在我们仅仅用JavaScript一种语

言就可以轻松实现这些。至于后端程序员，他们只需要保证数据的正确性，无论他们使用任何一种语言来封装REST调用，都不会对前端造成影响，这样前后端的

职责不就被更好地划分了吗?这样分工之后前端的领域就从浏览器小框框里面扩展到了server的UI层，而这一层本来对于后端来说是一件他们做起来不轻松

的零碎活儿。

不!这太耸人听闻了!

前端工程师想接手server的UI层是不那么容易被后端工程师们理解和接受的，因为这部分工作本来属于后端工程师的职责。尤其是现在还有很多后端工

程师认为JavaScript是一种极简单的“玩具语言”，他们将会想如此重要的服务端工作怎么能交给这群看起来不太靠谱的人用如此“不严肃”的语言来

玩?在我的经验里，这种观念上的冲突是前后端工程师们在是否引入Node.js这一问题上的最大分歧。Server端UI层是前后端的中间地带，而之前通

常后端程序员们对这个地带比较有主导权，所以一旦你进入这个本来属于后端主导的领域，争议自然是不可避免的。

实际上放弃传统的角色立场，将server的UI层分给前端，在大型Web架构下是很有意义的。不这么做的话，有时候前端想要从后端要到正确的数据，

还不得不关心后端究竟是用什么语言实现的。过去的分工中，那些原本属于核心业务底层考虑的东西会被暴露给server的UI层，而这些问题往往会不小心影

响到前端。前端本来不需要关注这些问题，因为前后端所关心的方面根本完全不一样嘛。如果你理解单一职能、责任分离和模块化，你就会理解我所说的，甚至会觉

得以前不把server的UI层分给前端实在是很笨。

只可惜，之前Node.js这样的东东不存在，所以当时没有前端合适的技术让前端工程师们自己搞定server的UI层。于是后端的同学们用PHP的

人就顺手把UI用PHP的模板实现了，同样的用Java的后端同学也自然而然地用JSP搞定这个问题。这不是前端的同学不愿意去做Server的UI，而

是因为在之前，没有一种我们熟悉的技术让我们能够搞定这些事情，但是现在不一样了，我们有Node.js了。

结论

我很喜欢Node.js，我喜欢由这项技术给前端界带来的更大的发展潜力。我并不认为整个后端完全用Node.js来实现会是一个很好的方案，尽管

Node.js完全可以做到这一切。我认为目前Node.js最大的价值是能让前端完全把控整个UI层，不论是浏览器的还是Server端的，做到这一

点，我们工作的效率能得到很大的提升。我们前端更擅长于决定数据以何种方式呈现能带给用户更好的体验，而后端则更加了解如何处理数据。在这种新的分工方式

下，后端只需要提供合适的数据操作接口，前端自己就能构建漂亮的、有效率的、可用性高的接口，从而实现用户所喜欢的各种交互。

使用Node.js来搞定server的UI层也将后端工程师从他们不擅长的领域解放了出来。于是我们得到了一个Web开发的灵丹妙药：前后端之间只

需要通过数据来交互，这种模型使得两方相互独立，各自都能够快速并且长久开发，而只要保证数据接口不变，前后端彼此之间就不会造成任何影响。

---