如果你们开发团队正在使用php，并考虑迁移到node.js，这篇文章很适合你。本文并不探讨从php移植到node.js的细节，以及node.js的基础知识。而是涵盖：决策制定、着手点的描述、编写 node.js 服务器的深层次注意事项、以及部署策略。
为什么迁移？ 1stdibs 决定从 apache/php 迁移到 node.js+express 有五个理由：
代码更少 全栈式js 开发人员幸福度更高 投入回报率 未来的优化 代码更少 1stdibs基于面向服务体系架构（sao），前端调用后台的java服务。这意味着需要同时维护前端模型，以及服务端php和客户端js模板。试想一下，如果可以摆脱php，就能够统一前端展现与后台模型于一种语言：javascript（同时可以合并一些模板）。从维护的角度来看，这么做代码更简洁，并且没有重复逻辑。
同构javascript万岁!
全栈式js（及其优点） 整个开发栈使用一种语言很简便。对开发者来说，较少的环境切换使他们开心和高效。额外的好处是工具使用更简单。相比之前使用composer和npm两个包管理器，现在只需要一个。尽管composer很出色，由于nbp负责工具和客户端管理，nbp总是必要的。一旦去掉所有的php代码，nbp将成为仅有的包管理器。
开发人员乐意 我们要保证开发人员的技能集得到扩展、职业生涯不断发展，这一点很重要。对于javascript工程师而言，node.js极具吸引力。能够在服务端使用与客户端相同的工具、风格和模式，是非常顺手和高效的。此外，node.js相当流行，在企业级开发上也得到了长足发展。node.js是javascript工程师的必备技能。
投入回报率 我们在招聘优秀的js工程师和培训初级js工程师方面花了大价钱。由于客户端栈很复杂，我们需要高级javascript工程师。我们不再雇用php工程师，仅仅雇用了javascript工程师。我们的观点是，为什么不培养他们在服务端的技能呢？
未来的优化 长远而言，我们打算把两个庞大的应用分割成一系列独立部署的小应用。这很容易通过node.js、express和nbp实现。理论上，php（比如使用slim）可以做同样的事。但我们非但得不到上述好处，还会搞得一团糟：在apache/php上进行操作会更加复杂，基础设施也会变得有些奇怪。
选择框架 那个最终被我们用node.js替换掉的php应用，主要有如下职责：
登录和授权 路由选择和服务端模板引擎（服务html） 引导前端应用 代理服务（为了回避cors） 服务静态资源（js，css，images） 这些就是我们需要替换掉的基本功能。
我们尝试过不少框架，express令人叹为观止（试一下我们评估过的spreadsheet）。任何未基于express 的框架看起来都不靠谱。express通俗易懂，并有良好的文档。另外，可以招聘到正经培训过express的人。
我们添加了一些kraken的核心模块（express-enrouten用于路由选择、lusca负责安全）；此外，i18n-node提供国际化支持，模板引擎使用swig（我们后来放弃了swig。呵呵，开源软件还是有风险的）。
我们考虑过全盘使用kraken，但是从原来的服务端php模板引擎twig切换到swig直截了当，还很快捷。此外，kraken里面的dust和i18n也不讨人喜欢。
编写服务器 选好了框架，下一步该写服务器了。
使用apache+php时，你不需要再写一个服务器。apache本身就是服务器，php是应用。如果使用node.js，服务器和应用是同一个。从apache/php转到php，你需要处理一些之前自然而然使用的功能，这一点很重要。使用apache，你（或者系统管理员）配置服务器，在php应用里完全不用关心apache为你处理的那些事。node.js却以一种不同的方式来工作。
提供静态文件服务 毋庸置疑，提供静态文件服务是apache的核心功能。node.js与此不同，你要在应用中配置静态文件服务。幸运的是这很简单，有良好的文档说明，并且是在express中实现的。
日志 很多基本的apache配置为你提供访问日志和错误日志。使用node.js时，估计你也猜到了，同样需要在应用中配置。所幸很多优秀的开源软件包使之变得很简单。morgan是一个基本的请求日志记录器，它配置简单，允许你把日志写到输出流（标准输出设备或文件）。如果你需要把日志写到数据库，或者有别的（更高级的）日志需求，那就试一下winston吧。
代理 我们有一个基本需求：能够代理传输客户端ajax请求到后台服务。相比于处理cors头，代理所有来自相同域的请求要简单得多。但你要想通过代理使用webpack-dev-server（正如我们所做的），就必须在node.js应用中处理这一问题。http-proxy是一个简单可靠的解决方案。
剩下的工作 除了上面提到的，还有一些列别的工作需要完成。我们从一个mvc应用谈起，该应用基于 codeigniter(ci)框架，为一系列单页应用提供服务。大部分工作就是移植：
ci控制器移植到express路由选择器和中间件（包括登录和认证） twig模板引擎移植到swig（这一步比较琐碎） service层数据访问（以便正常启动客户端单页应用） 上面并未列出codeigniter模型这一关键组件。事实上根本不用重写php模型！太给力了！我们的客户端应用使用backbone模型。当然这要扩展backbone.model.sync，从而使之全局地工作在服务器和客户端。
部署 如果你的app规模较大，不应该一次性全部上线。可以通过渐进式部署的方式逐步上线。我们因此花费了好几周。
渐进式部署的优点：
最小化bug范围 每次在发布一部分路由及功能的同时，其他工程师可以正常进行开发 对正在进行的功能开发和改进影响最小 — 新功能可以继续发布（这可能导致重复的工作） 如果操作得当，可以快速回滚到之前的服务 nginx很不错 该如何逐步上线呢？我们在众多的服务器中挑选了nginx。
+----------+ http | |---> apache/php request---->| nginx | | |---> node.js +----------+
nginx允许你一次只“打开”一个路由（如果发现情况不妙就关掉 — 正如我们多次遇到的），这给了你很大的自由度。我们也发现打开路由的时候不用部署代码，这很有帮助。这在一周一次的发布计划里，为我们提供了一些回旋空间。
不过有一个缺点，你需要确保客户端代码同时接受旧的apache/php服务器和新的node.js服务器提供的服务。这并不可怕，不过你要把旧服务器上未优化的功能移植到新的服务器。屏住呼吸去做吧（记得写一个便利贴去清理你的技术债）。
总结 从头到尾，整个移植工作大概花费了一年。这听起来可能有点荒谬，不过这个时间表包括决策过程（比较匆忙）、基于express写一个满足需求的核心框架、移植所有功能、逐步渐进式上线。此外，请记住，我们始终只有一两个开发者为之工作 — 并且是兼职。
如果你想尝试一下，请慎重考虑。你的团队能否受益？你的整个组织能否受益？如果你来自商业组织，请记住商业需要持续运转。你需要在商业目标和工程目标之间找到良好的平衡。
我们很高兴尝试过。
关于作者：未济
关注c，php，mysql，java，数学，美剧（尤其是权利的游戏）。 个人主页 · 我的文章 · 10 ·