Solr插件的弊端

在前文《Solr Update插件自定义条件索引》中，我介绍了如何通过插件的模式，自定义Solr的Update过程。但是在大半年的使用过程中，发现这种方式存在如下弊端。

1.环境难以维护。CDH没有对Solr插件的管理，而这就导致，我们每次更新插件，都需要挨个服务器去部署，重载core。

2.代码难以开发。Solr插件不支持本地调试，我们每次都要用CDH环境验证插件的逻辑是否生效。

3.上线流程无法保障。由于环境开放给开发人员调试，上线流程中就存在很多风险。

所以以后的项目建议使用SolrJ这样的技术，另起外部项目来实现，即使效率比插件慢，但是易于维护和分享。

当时使用插件的另外一个原因是，我们使用的是 Kafka->flume->morphline sink技术，这项技术里面，morphline sink是直接update到solr的，所以只能在solr插件里面实现后续的自定义条件。

那么同样，我们也应该怀疑morphline sink这项技术的可维护性。

因此，建议大家，如果你的需求是持续迭代的，请千万不要用morphline sink，CDH的这项新功能也是同样的难以debug，一旦你陷进去就会如泥潭深陷。

由于morphline sink是和flume配套的，我们在处理复杂逻辑的时候，建议也不要使用flume。虽然flume功能强大，可靠性高，但是无法方便定位和维护的东西，最好不要选择。我们应该总是选择那些最优解。