经过本周部署和测试pinpoint监控平台的工作，我对这套开源系统有了更进一步的认识。
初次见到pinpoint这套系统时，我被它各方面优秀的特征所折服：无需对项目代码进行任何改动就可以部署探针、追踪数据细粒化到方法调用级别、功能强大的用户界面和告警系统，再加上开课啦事业部的使用背书。对我们来说可以说是一套完美的解决方案。
但是，经过对它的仔细研究和实际落地测试后发现。现实往往没有想象的那么美好，pinpoint这套监控系统，还是有一些短板的。就拿它和Spring Cloud Sleuth + Zipkin这套解决方案做对比：
|
对比点 |
Zipkin（Z） |
Pinpoint（P） |
说明 |
|
技术性 |
√ |
Z依赖于spring框架的API支持，监控内容有限 P采用字节码注入，监控程度更深，范围更广 |
|
|
接入成本 |
√ |
Z需要对应用改造，加入配置和依赖框架 P只需要在服务器打下探针，上层业务不需要动 |
|
|
扩展性 |
√ |
Z使用http和json这种轻量级协议，比起P使用探针和Thrift传输协议。更易于扩展和集成第三方接口 |
|
|
兼容性 |
√ |
Z对spring cloud的支持更好。Z是大公司（Twitter）出品，社区活跃度也更高，插件也更多 |
|
|
产品 |
√ |
从产品角度讲，P无论是从UI界面，还是功能点上都更好，是款更成熟的产品 |
|
|
性能 |
√ |
由于监控策略的不同，Z更加支持自定义采样策略，而P更倾向于全量采集。因此，虽然P的系统设计对性能优化的更好，但是对服务器的压力，还是P更高 |
总结
从短期目标来看，Pinpoint 确实具有压倒性的优势：无需对项目代码进行任何改动就可以部署探针、追踪数据细粒化到方法调用级别、功能强大的用户界面以及几乎比较全面的 Java 框架支持。但是长远来看，学习 Pinpoint 的开发接口，以及未来为不同的框架实现接口的成本都还是个未知数。相反，掌握 Zipkin 就相对容易，而且 Zipkin 的社区更加强大，更有可能在未来开发出更多的接口。在最坏的情况下，我们也可以自己通过 AOP 的方式添加适合于我们自己的监控代码，而并不需要引入太多的新技术和新概念。而且在未来业务发生变化的时候，Pinpoint 官方提供的报表是否能满足要求也不好说，增加新的报表也会带来不可以预测的工作难度和工作量。