产品化
1. 项目工程化
所谓的工程化，可以理解为项目的组织能力。所谓的工程化，可以理解为项目的组织能力。体现在文件上，就是文件的组织能力。
1.1 目录结构
主要的两类项目为Web应用和模块应用。普通的模块应用遵循CommonJS的模块和包规范。对于Web应用，组织方式各种各样，但是只要遵循单一原则即可。
1.2 构建工具
要想真正能用上源代码，还需要一定的操作，操作包括合并静态文件、压缩文件大小、打包应用、编译模块。每次都手动完成这些操作，效率会比较低下。为了节省资源，使用构建工具完成这些工作。
Node上的构建工具：
-
Makefile
只能在*nix操作系统上有效；
-
Grunt
可以跨平台；
1.3 编码规范
编码规范的实现方式：
- 文档式的约定；(依靠自觉)
- 代码提交时的强制检查；(依靠工具)
1.4 代码审查
代码审查建立在具体的代码提交过程中。
对于使用GitHub或Gitlab开源工具搭建的代码托管平台，可以利用git的分支特点，很好地实现代码审查。
2. 部署流程
代码在完成开发、审查、合并之后进入部署流程。
2.1 部署环境
在实际项目需求中，有两点需要验证，一是功能的正确性，二是与数据相关的检查。
普通测试环境称为stage环境；
预发布环境称为pre-release环境；
实际的生产环境称为product环境；
2.2 部署操作
就普通的实例代码而言，通常直接在命令行执行node file.js以启动应用。
对于长时间执行的服务进程而言，存在两个问题：
- 占住一个命令行窗口；
- 随着窗口的退出会导致打开的进程一并退出；
为了能让进程持续执行，用nohup和&以不挂断进程的方式执行：
$ nohup node app.js &
3. 性能
Node产品的性能与许多因素相关，对于Web应用而言，最直接有效的莫过于动静分离、多进程架构、分布式。
拆分原则：
- 做专一的事
- 让擅长的工具做擅长的事情
- 让模型简化
- 将风险分离
- 缓存
3.1 动静分离
在普通的Web应用中，Node尽管可以通过中间件实现静态文件服务，但是Node处理静态文件的能力不够退出。将图片、脚本、样式表和多媒体等静态文件都引导到专业的静态文件服务器上，让Node只处理动态请求即可。这个过程可以用Nginx或者专业的CDN来处理。
将动态请求和静态请求分离后，服务器可以专注于动态服务方面，专业的CDN会将静态文件与用户尽可能靠近，同时能够有更精确和高效的缓存机制。静态文件请求分离后，对静态请求使用不同的域名或多个域名还能消除掉不必要的Cookie传输和浏览器对下载线程数的限制。
3.2 启用缓存
提升性能的两个途径：
- 提升服务的速度；
- 避免不必要的计算；
前者提升的性能在海量流量面前终有瓶颈，但后者却能够在访问量越大时收益越多。避免不必要的计算，应用场景最多的就是缓存。
Redis和Memcached几乎是Web应用的标准配置。
如果你的产品需要应对巨大的流量，启动缓存并应用好它，是系统性能瓶颈的关键。
3.3 多进程架构
通过多进程架构，不仅可以充分利用多核CPU，更是可以建立机制让Node进程更加健壮，以保障Web应用持续服务。
3.4 读写分离
针对数据库而言，读取的速度远远高于写入的速度。儿某些数据库在写入时为了保证数据一致性，会进行锁表的操作，这同时会影响到读取的速度。某些系统为了提升性能，通常会进行数据库的读写分离，将数据进行主从设计，这样读数据不再受到写入的影响，降低了性能的影响。
4. 日志
在健全的系统中，完善的日志最能够还原问题现场。通过记录日志来定位问题是一种成本较小的方式。
4.1 访问日志
访问日志一般用来记录每个客户端应用的访问。在Web应用中，主要记录HTTP请求中的关键数据。一般的Web服务器都实现了记录访问日志的功能。只要简单的配置即可启用。在用Nginx或Apache进行反向代理时，可以利用这些已有的设施完成访问日志的记录。
4.2 异常日志
异常日志通常用来记录那些意外产生的异常错误。通过日志的记录，开发者可以根据异常信息定位Bug出现的具体位置，以快速修复问题。
异常日志的分级：
- console.log：普通日志
- console.info：普通信息
- console.warn：警告信息
- console.error：错误信息
4.3 日志与数据库
对日志不了解的开发者会选择将日志写入数据库中。数据库比日志文件好的地方在于它是结构化数据，可以直接编写SQL语句进行分析，日志文件则需要再加工之后才能分析。
4.4 分割日志
线上业务可能访问量巨大，产生的日志也可能是大量的，将产生的日志按日期分割是个不错的主意。
5. 监控报警
应用的监控主要分两类：
- 业务逻辑型的监控；
- 硬件型的监控；
监控主要通过定时采样来进行记录。
5.1 监控
监控的主要目的是为了将一些重要指标采样记录下来，一旦这些指标发生较大变化，可以配合报警系统将问题反馈到负责人那。
- 日志监控
- 响应时间
- 进程监控
- 磁盘监控
- 内存监控
- CPU占用监控
- CPU load监控
- I/O负载
- 网络监控
- 应用状态监控
- DNS监控
5.2 报警的实现
- 邮件报警
- 短信或电话报警
5.3 监控系统的稳定性
为了保证应用的稳定性，引入了一个庞大的监控系统，监控系统自身的稳定性对应用也非常重要。
6. 稳定性
为了更好的稳定性，典型的水平扩展方式就是多进程、多机器、对机房。
7.异构共存
站在技术的产品化的角度来看，选择一门新技术应用在生产环境就得考虑与已有的系统或者服务能否异构共存。
