近年来，由于 JavaScript 在服务端的兴起，使用 Node.js (以下简称 Node) 或 io.js 编写 Web 应用服务的初创团队和产品日益增多。由于 JavaScript 其天生的 Web 通用性设计，导致编写 Node 应用极易上手，开发效率高，但随着 Node 的火热发展，使用 Node 和其相关技术作为技术框架的应用，也存在不少 debug 与性能方面的问题。

Node 由于其 libuv 多线程池模拟异步 IO 的设计，能够很高效的解决单位资源下高并发的业务场景，而为很多程序员所钟爱。但当我们编写完成 Node 应用，将之部署到生产环境后，经常会发现诸如「CPU占用率过高」或「不同应用实例间负载不均衡」之类的性能问题，这些问题有时出在单元模块的编码缺陷，比如某些 IO 的等待触发回调时间过长，或不同服务间的通信导致了较高的 IO 延迟，导致轮询事件堆积，引发性能问题；有时出在调用远程 API 请求的时间过长，或某项操作使用了阻塞主执行线程的技术方案而导致。

这些性能问题，有时可以在单元测试或者压力测试中看出端倪，但更多时候，是随着生产环境服务的外部压力增大后，缓慢呈现出来的一种不确定性状态，加之 Node 应用的架构设计多采用 SOA，不同服务之间的通信状态存在不确定性，使得此种性能问题的排查存在相当的难度。

实时应用性能检测需求的产生，加速了 Applicaiton Performance Management 平台的发展速度，在国外，我们可以使用 New Relic 来进行实时的应用性能检测，查看应用间通信的拓扑图，跟踪和预警不同业务层面的压力情况与负载，从而进行科学的资源调度和弹性服务部署。 将线上业务的性能问题可视化，透明化，尽量在问题发生之前或将要发生时思考解决对策，这也是此类平台不同于一般的实时统计平台的一大特征之一。

在这篇文章中，我们将要通过从 Node 应用的业务逻辑分析、部署 Node APM 探针实战这几个简单的步骤，理解如何对 Node 应用进行性能监测，找出问题，并优化程序的整个过程。

让我们思考一种常用的 Web 应用业务逻辑。在这个 Web 应用中，用户请求某个资源列表，我们的服务通过查询不同的数据库或外部服务，在返回资源的同时记录用户的查询日志，在触发最大查询量之后警告用户，并在一段时间后自然释放 继续正确返回用户所需的资源列表。在这个应用场景中，我们需要对数据库进行简单的读写操作，可能还涉及与其他服务的网络 IO，当然，在这个过程中，我们还需要对用户进行鉴权，可能需要进行哈希运算，并且将用户常用数据，如查询次数与 token 存放在 更高效的内存数据库中，且对此类数据进行持久化操作。在这个案例中，我们不会实现所有业务逻辑的范例，但我们可以理解如何从性能分析角度去思考对于一个通用的 Web 业务，哪些关键点需要关注执行效率，哪些单元需要实时监测 IO 延迟。

更多：http://cnodejs.org/topic/558a80b0c31358754d3aa343

转载请注明：懒人档案室 » 聊聊实时 Node 应用性能监测的实现