记一次有点儿复杂的streamsets与自己开发模块集成的过程

最近参与一个项目的开发,leader和产品决定使用开源的streamsets做底层服务和监控页面。除开发产品模块页面外,我还负责streamsets前端的修改和与自己开发模块的集成。

经过调研,streamsets前端使用的技术栈和我们公司常用的技术有些出入,并不太方便直接从代码层面合成一个项目,决定在自己项目中使用iframe嵌入streamsets监控、日志等页面。

最终整个产品架构图如下:

记一次有点儿复杂的streamsets与自己开发模块集成的过程_第1张图片

需要注意的几点内容:

1、产品模块前端通过iframe集成streamsets前端(修改);

2、根据不同的产品场景,streamsets前端的修改需要有两种;

3、公司内部维护人员需要使用streamsets开源前端,所以必须有streamsets前端是单独维护的,和后台代码不在一起,即和后台一起部署的只有一套前端代码(这里是开源前端和服务在一起维护、部署);

4、部署的streamsets服务有单机版和集群版(包括开源前端),单独部署的前端却只有一套环境,每次对修改后的streamsets监控页面调用时都必须调用单独部署的前端和单机版或集群版的服务,并不能一并调用与服务一起部署的前端。

记一次有点儿复杂的streamsets与自己开发模块集成的过程_第2张图片

5、跳转到如上图中集群版任务时,需要访问的服务为各个不同的集群地址,所以会在单机版任务前端跳转到集群版任务之前,在url里添加参数ssHadoopSrc进行区分,对于访问的服务基于参数ssHadoopSrc是否存在,设置interceptors rewrite请求的URL;

6、集群版任务调用的后台服务需要经过proxy服务转发。

本以为集成过程会很简单,没想到过程中遇到各种问题,而且还有产品模块的持续更新,最终使用了如上方式进行集成,特此记录,以后遇到类似情况可以有个参考,并警示自己必须提前了解后续产品规划,全面了解需求,规划比较合理的实现方式。

你可能感兴趣的:(记一次有点儿复杂的streamsets与自己开发模块集成的过程)