3.apollo-apollo踩坑记录

2021 04:28 13:47:56 运维反馈我们有一个系统发布失败。打开日志发现大量的警告异常。

2021-04-28 13:46:21,922 WARN  [localhost-startStop-1] [AbstractConfigRepository.java:26] Sync config failed, will retry. Repository class com.ctrip.framework.apollo.internals.RemoteConfigRepository, reason: Load Apollo Config failed - appId: vem-admin, cluster: default, namespace: application, url: http://10.5.9.8:8080/configs/vem-admin/default/application?ip=10.7.6.10 [Cause: [status code: 404] Could not find config for namespace - appId: vem-admin, cluster: default, namespace: application, please check whether the configs are released in Apollo!]

第一步：从日志排除网络问题

看起来像apollo有关的异常？这个轮子已经对接很久了，不应该有问题的吧！在仔细分析历史的日志也有这个情况。这到底什么原因导致这个异常？质询下公司apollo的负责人，负责人反馈原因是。可能是发布的时候公司的网络异常或者apollo自己有bug！这不是等于没有说么没有网络也不是404啊......  于是乎靠人不是靠自己，自己从现象及源码一点点分析。从图一分析出现404的节点不止一个，排除一切关于网络的问题。

图一：出现404的节点不是一个

第二步：从日志定位到问题源码断点跟踪

首先下载阿波罗源码。在根据日志定位到阿波罗源码访问报错的url：http://121.15.19.81:8080/configs/xxx/default/application?ip=10.12.10 。于是把这个url粘贴的浏览器同样的也是爆404错误。看来问题出现在这个url上面。vem-admin：appId项目的标示，default：默认集群我们没有其他集群就是这个默认的， application：承载项目配置的实例。莫非问题出现在application从来没有发布上面？于是打开apollo管理平台，发现这个实例重来没有发布过（见图3)，就是这个原因导致vem-admin上面有大量的告警日志。于是做个实验重现这个异常，创建一个项目但是不下发application配置于是就重现线上的异常（如图4）

2.图2 apollo爆出异常日志的源码

3.图3 展示application发布历史

图4.apollo出现404源码重现

第三步：其他不规范配置

在检查项目异常的时候还发现其他不规范的配置，比如：apollo.cacheDir这个配置，这个配置是apollo拉取配置文件存放的目录，阿波罗宣称就算阿波罗挂掉也不影响项目业务运行。这个目录apollo做的不是很好，在Window环境默认路径C:\opt\data\，在其他系统包含Linux默认路径/opt/data，但是如果此时在Linux上没有这个目录的权限，他的路径就变成项目路径+/WEB-INF/classes/config-cache，这个路径如果在阿波罗挂掉后,由于其没有配置文件就会导致启动异常！这和阿波罗宣传的不一致。那我们尝试修改阿波罗配置文件？让其生成在一个稳定的目录？这个地方还有坑。

• SpringBoot项目   如果你的项目是SpringBoot或者SpingCloud项目，恭喜你你知需要在yml文件配置项apollo.cacheDir加上配置即可。
• SpringMVC项目 - 默认配置    如果是SpringMVC老项目就蛋疼了，加这个配置是无效的！apollo并不会把apollo.cacheDir参数加载到系统参数里面（见图5）。
• SpringMVC项目 - JVM环境变量  从代码上看apollo支持把配置加载JVM环境变量上面....💦。运维同学肯定不同意这样干。难倒就没有通过改代码的方式修改这个变量吗？
• SpringMVC项目 - Java代码修改  从apollo源码分析只要我们在apollo运行之前把参数加载在System.getProperty上面，apollo不就可以读取到配置了吗？这种想法很美丽但是apollo的源码结构不是通过启动类继承配置类的方式，不好通过spring去加载配置类（如图6）

图5.apollo加载客户端文件路径参数

图6.apollo启动入口

总结：

• 第一点   我们对中间件的功能不熟悉。 例如：application需要发布后在拉取配置信息，不会导致404的报错，我们使用方及中间件负责人都不熟悉。
• 第二点   apollo设计思想在写代码上没有彻底的贯彻。例如：apollo宣传自己挂掉不影响应用使用，前提没有说我们要给默认文件夹创建权限，不然他配置文件就生成在项目底下就达不到这个目标。
• 第三点   apollo代码兼容性差，其配置在springboot和spring构建的项目不同。 例如：1、apollo.cacheDir在spring构建的项目配置文件中无法加载，在springboot构建的项目就可以。 2、apollo配置类没有抽象出来乱七八糟的，导致想通过spring xml方式在启动入口类初始化无法做到。
• 第四点  在Linux创建好/opt/data/给apollo使用，是目前发现的最低成本的方案。