当你引入一个公司内部开源组件时

当你引入一个公司内部开源组件时

当你使用公司内部的”开源“组件时,千万要做好调研工作和心理准备,尤其是当你是第一个接入的勇者!

当你使用公司内部的”开源“组件时,千万要做好调研工作和心理准备,尤其是当你是第一个接入的勇者!

前言

这个月主要的工作是把公司原先的任务调度框架从单体cron服务,改造成分布式任务调度,并且引入可视化的后台管理平台, 并且为后续的同城双活打个基础。

为了实现分布式任务调度,我们到处寻找可用的第三方库,但是Go生态确实没有Java好,Java中一提分布式任务调度肯定是xxl-job了, 可惜Go没有。

但是我们经过调研后,发现公司内部有一套“开源”的框架,给xxl-job写了一个Go的SDK,还贴心的兼容了多地区的特性和管理后台,国际化牛逼。 所以我们最后决定“接入”这套分布式框架,我说的接入,不是接入某个平台,而是搭建一套系统,只是代码是他们的。

看标题就知道我踩了很大的坑。但这篇文章不是想表达内部“开源”库不好,而是要检讨下我前期调研的不足

文档

一般来说,公司内部开源组件的文档不是很丰富,而且实效性不高。 最直接的办法就是找开发的同事,如果他离职了,自求多福吧。

其次,如果公司开源库是基于外界开源库开发的,那么先去github社区把原理搞清后, 再去理解二次开发的特性,这种方式会让你在聊天的时候不会被开发的同事鄙视。

是否需要引入新中间件

当你引入的“开源”组件是一个系统而不是一个工具的时候。组件依赖是你必须要考虑的事情。 比如,当你的服务注册还在使用zk时,别人的组件已经在用etcd做服务注册。

能否使用域名来注册呢?如果可以的话,使用域名又引入了其他问题:

  • 心跳请求走域名肯定没有走ip快,网络会不会超时?需不需要更改默认超时时间?
  • nginx 会不会拦截这种大量且重复的请求。
  • 是否没必要使用域名?使用k8s的svc ip试试?

虽然nginx将其视为没必要,但是对于系统而言,心跳请求却是必须的。

当你像去除一项依赖的时候,难免引入一些开发者都没遇到过的问题,这个时候只能靠你自己的知识深度与脸皮厚度了。

基础架构差异

如果你用的是跨业务线的开源库,那么恭喜你,你们的基础架构很有可能不一样。虽然都是jenkins,k8s那一套, 但是架不住人家是自己维护的jenkinsk8s,什么部署脚本,参数设置,机房网络隔离,全部不适用。

更坑的是,在我们部门部署脚本是开发自己提供的,需要把部署命令写在一个json文件中,再由jenkins提取出来,传递给k8s在容器内执行。 而其他业务线则是在jenkins执行完后,推送给k8s就结束了。这就是我说的基础架构差异,对于没做过运维的同事真的大坑。

比如这次接入的“开源”组件,一共三个代码库,分别是用Java写的调度中心,用Go写的执行器SDK,NodeJS写的管理后台。

部署脚本写的我头皮发麻了,工时伤不起。

网络差异/部署差异

一开始,我打算照抄对方业务线的部署结构,一个管理后台服务+7个地区的线上线下调度服务。但是没想到又漏算了。

由于公司业务特性,在多个地区有多个机房(local机房)。我们业务线一直都是把所有地区的服务都部署在sg的一个机房。

万万没想到,对方的业务线居然是将调度中心和执行器部署在local机房,然后管理后台部署在sg,所以他们的管理后台服务 可以访问线下的调度服务。

而我们业务线的服务都是部署在同一个机房,线上线下网络是隔离的。线上的管理后台服务肯定是无法访问线下的调度服务。

方案评审的时候,大家都没想到这点。还好在开发时候想到这个差异了,不然服务上线的时候就尴尬了。

The End

暂时想到这么多,就写到这吧,还有一些小坑,比如对方的nginx是正向代理,而你部门是反向代理,等等之类。

第一次接入这么大型的“开源”组件,稍微有点吃力,暴露了我的综合能力远远不够。

自己对于平台提供的统一能力麻木了,没想到业务系统下的暗流涌动。感谢公司的基础架构能力缺失和差异, 让我不至于温水煮青蛙。这或许是我司倒逼业务开发进步的一个举措吧,感恩。