經過本周部署和測試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 官方提供的報表是否能滿足要求也不好說，增加新的報表也會帶來不可以預測的工作難度和工作量。