spring boot中Date时区错乱

由于系统中采用了spring-boot中jar方式（内嵌tomcat容器）运行，发现new Date()获取的时间与当前系统时间间隔了8个小时，初步断定是时区错乱导致。实际上系统的运行环境是在docker中，并且使用apollo作为配置中心。

其实解决它并不复杂，通过添加命令行参数-Duser.timezone=GMT+08就可以解决它。

然后很多时候，我们发现了这样的一个现象：告诉运维，某个xx-app要添加一个xx启动参数（环境变量）或增加个性化配置（也有通过shell读取放置环境变量中）就可以了，这不复杂，行还是不行？一般情况下对方答复都是最好不要这样，为何不行呢？究其原因，要为xx-app修改dockerfile和shell，特殊性处理越多维护成本就越高，后期工程化（流水线）上的麻烦也就接踵而来。

下面分享下，我们是怎样解决这样的问题？

apollo

目前，我司大多系统都采用了apollo来管理各种配置，而上面这种情况，我们也为此添加了这样的配置：

重点关注namespace（JVMOPTS）：它就是为系统环境而生的（如：JAVA_OPTS="-server -Xmx4g"，也就是catalina.sh中配置），spring-boot启动时不会拉取的。

JMXEBILL

export JMXEBILL="-Xms1024m -Xmx1024m -Denv=sit -Duser.timezone=GMT+08 -Dcom.sun.management.jmxremote.port=8099 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false -Djava.rmi.server.hostname=$(ifconfig eth0 | grep -Eo '[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}\.[0-9]{1,3}' | head -1) -Dlog.main.level=INFO -Dlog.other.level=INFO"

java.rmi.server.hostname=(ifconfig eth0 |... 你会发现有shell脚本（实际上这样的场景真不少，比如阿里云的ECS中自建docker但IP不通就需要拉去宿主机的ip）!

dockerfile

通过dockerfile的确可以解决问题，比如像下面这样的：

FROM java:8
VOLUME /tmp
ADD app.jar app.jar
RUN bash -c 'touch /app.jar'
EXPOSE 9001
ENV JAVA_OPTS="\
-server \
-Xmx4g \
-Xms4g \
-Xmn2g \
-XX:SurvivorRatio=8 \
-XX:MetaspaceSize=256m \
-XX:MaxMetaspaceSize=512m \
-XX:+UseParallelGC \
-XX:ParallelGCThreads=4 \
-XX:+UseParallelOldGC \
-XX:+UseAdaptiveSizePolicy \
-XX:+PrintGCDetails \
-XX:+PrintTenuringDistribution \
-XX:+PrintGCTimeStamps \
-XX:+HeapDumpOnOutOfMemoryError \
-XX:HeapDumpPath=/ \
-Xloggc:/gc.log \
-XX:+UseGCLogFileRotation \
-XX:NumberOfGCLogFiles=5 \
-XX:GCLogFileSize=10M"
ENTRYPOINT java ${JAVA_OPTS} -Djava.security.egd=file:/dev/./urandom -jar /app.jar
#-Djava.security.egd解决linux tomcat容器启动比较慢的问题

但我们并未直接采用上面的方式（意味着每个系统都一个这样重复度极高的配置），而通过shell来读取apollo的配置JMXEBILL，主要考虑：

• 工作量要考虑，dockerfile尽可能保持简单，复杂意味着要频繁大量修改，因此要每个dockerfile稳定（不易变化）
• 学习成本低，shell脚本是人人都可以上手，它可以做很多事情：比如假密码替换真密码，读取远程配置，catalina.sh中命令都可以被配置并执行
• 出错率低，shell可能会复杂尽可能模板化，个性化通过配置存储，影响docker build/docker run小，改配置后重启下就可以了

该问题虽然是一个小问题，但作为一个平台型的公司而言，如果维护着成千上万台应用，那就需要系统化的思考，毕竟运维响应慢是不能接受的，通过增加人手来支撑变化确实长久之计。