我是怎么爬坑的

引言

今天不聊技术，只聊人生。分享一下我在使用Spring Cloud Config过程中遇到的坑，以及是如何解决的，这其中，主要看解决方法和思路，技术只占一小部分。一家之言, 仅供参考.

正文

在某个特别适合敲代码的深夜，我使用SpringCloud Config(以下简称Config)搭配SpringCloud Bus(以下简称Bus)实现动态刷新配置. 使用的SpringCloud版本是Finchley.M2，M2就是里程碑版本，非正式版.

第一个坑

要实现配置动态刷新, 修改配置后, Bus会发送消息到MQ, 我发现这一步就走不通. 于是

1. 网上搜索问题(用google), 发现有人遇到同样的问题, 可惜的是, 也没有得到解决. 搜索的时候留意SpringCloud的版本.

2. 怀疑是不是我用的姿势不对, 新版本有变化? 查阅官方文档，我的用法没问题.

3. 立马向官方提了issue

老外的效率很高, 第二天就把这个bug fix了, 如果我要立马用的话, 必须用Finchley.BUILD-SNAPSHOT版本, 这里顺便提一下, SNAPSHOT版本是可覆盖的版本, 今天看到的Finchley.BUILD-SNAPSHOT和明天看到的Finchley.BUILD-SNAPSHOT很可能是不一样的.

第二个坑

Bus的坑算是已经填好了, 但让我意识到, 里程碑版本应该很多坑等着我.....但, 自己选择的路, 跪着也要走完......
在测试git的WebHooks时, 发现Gitee的推送无效, Github是没问题的. 于是

1. 不用太费力搜索了, 简单搜一下就行, 因为老外用Gitee肯定少, 把Conifg和Gitee放一起用的人肯定更少.
2. 到目前为止, 还不知道是Gitee的问题还是Config的问题(有人要说了, Config既然支持Github那肯定不是它的问题, 其实未必!)

所以只能自己先去看源码了, 看看到底是什么问题, 一说到看源码, 很多人可能就要头疼了, 因为源码很多, 不知道从哪下手, 如果你能这么想, 说明你还挺聪明的, 至少第一想法不是把源码全部阅读完. 从哪下手呢?

1. 填在WebHooks的地址是 /monitor, Config里有个模块是spring-cloud-config-monitor, 显然应该从这下手
2. 如果当初没找到这么明显的特征, 那我会在Config搜索“github”关键字

打开源码一看, 原来Config只对以下git服务做了适配

如果git服务不在3者内, Conifg还有个通配的

遗憾的是, Gitee的WebHooks Request里并没有path字段, 所以也没有触发Config. 我还对比了Gitee和Github的WebHooks推送的字段区别, 发现Gitee并没有以下的字段 added, removed等

问题已经找到, 怎么解决?

1. 给Gitee反馈, 希望加上added, removed等字段. 目前已经修改上线.
2. 给Config反馈, 希望支持Gitee, 见issue, 结果老外让我自己来写, 提pr

好吧, 说干就干, 提了一个pr, 提个pr也不容易啊

spring团队对代码要求严格

单测什么的就不说了, 这是必须的, 让我以外的是, 连import的顺序也有要求, 比如, 必须

import java.util.Collection;

import org.springframework.core.Ordered;

下面这种写法是不允许的

import org.springframework.core.Ordered;

import java.util.Collection;

为此他们提供了一份代码格式化的插件.
代码修改的同时, 文档也要相应的修改.
这次pr整整20多天才merged进去, 代码会在Config 2.0.0.M8里面.

后记

有的人或者团队, 遇到此类问题, 可能会fork一份源码, 这样自己改掉立马就可以使用. 这让我想起一段话, 大意如下:

• 普通人卖自己的时间, 如果你1小时能赚100元, 那你24小时不休息最多能赚2400元.
• 聪明人复制自己的时间, 比如写一本书花了1年的时间, 10个人来买和10000人来买, 作者都是花了1年的时间, 但收益却天壤之别.
• 更聪明的人会买别人的时间, 你的老板不就是花钱买你的时间嘛.