我有一个基于微服务的项目。每个微服务都是一个Spring Boot(v.2.0.0-RC2)应用程序。我还有一个基于Spring Cloud(Finchley)的发现,配置和网关微服务。整个系统使用Docker Compose部署在测试机上。
我意识到一个微服务在短时间内收到前端应用程序的多个后续请求后冻结。此后,它不再响应其他请求,并且我从网关收到读取超时。当直接调用此微服务而绕过网关时,也会发生同样的情况。
我有一个spring boot admin实例,我意识到微服务每5分钟就会脱机并再次联机。尽管如此,日志中没有发生任何有趣的事情。没有观察到内存问题。
下一步:仅当我同时从docker启动所有系统时,才会出现此问题。重新启动此单个微服务时,无法再进行复制。
最后一个:微服务的整个容器似乎被冻结了。当我在其上执行“ docker stop”时,终端挂起,但在另一个终端中检查容器状态后,该容器显示为“已退出”。当我在容器上执行“ dockerattach”时,发生了一件非常奇怪的事情。终端也挂断了电话,当我退出终端时,出现问题的微服务开始正常工作,并成功接受了传入请求。
有人可以帮助我解决这个奇怪的问题吗?我真的没有更多的想法了,我该怎么解决。
预先感谢您提供任何线索。
编辑
docker-compose.yml
version: '3.4'
services:
config-service:
image: im/config-service
container_name: config-service
environment:
- SPRING_PROFILES_ACTIVE=native
volumes:
- ~/production-logs:/logs
discovery-service:
image: im/discovery-service
container_name: discovery-service
environment:
- SPRING_PROFILES_ACTIVE=production
volumes:
- ~/production-logs:/logs
gateway-service:
image: im/gateway-service
container_name: gateway-service
ports:
- "8080:8080"
depends_on:
- config-service
- discovery-service
environment:
- SPRING_PROFILES_ACTIVE=production
volumes:
- ~/production-logs:/logs
car-service_db:
image: postgres:9.5
container_name: car-service_db
environment:
- POSTGRES_DB=car
- POSTGRES_USER=user
- POSTGRES_PASSWORD=pass
car-service:
image: im/car-service
container_name: car-service
depends_on:
- config-service
- discovery-service
- car-service_db
environment:
- SPRING_PROFILES_ACTIVE=production
- CAR_SERVICE_DB_URL=jdbc:postgresql://car-service_db:5432/car
- CAR_SERVICE_DB_USER=user
- CAR_SERVICE_DB_PASSWORD=pass
volumes:
- ~/production-logs:/logs
汽车服务的Dockerfile
FROM openjdk:8-jdk-alpine
VOLUME /tmp
EXPOSE 9005
ARG JAR_FILE
ADD ${JAR_FILE} app.jar
ENV JAVA_OPTS="-agentlib:jdwp=transport=dt_socket,address=8001,server=y,suspend=n"
ENTRYPOINT ["sh", "-c", "java $JAVA_OPTS -Djava.security.egd=file:/dev/./urandom -jar /app.jar"]
用于启动的命令
docker-compose up
测试机: Ubuntu Server 16.04 LTS
答案 0 :(得分:1)
已解决
原因是日志记录方面。我意识到有很多线程在等待:
sun.misc.Unsafe.park(Unsafe.java:-2) native
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:836)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:870)
java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1199)
java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:209)
java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:285)
ch.qos.logback.core.OutputStreamAppender.writeBytes(OutputStreamAppender.java:197)
ch.qos.logback.core.OutputStreamAppender.subAppend(OutputStreamAppender.java:231)
ch.qos.logback.core.OutputStreamAppender.append(OutputStreamAppender.java:102)
ch.qos.logback.core.UnsynchronizedAppenderBase.doAppend(UnsynchronizedAppenderBase.java:84)
ch.qos.logback.core.spi.AppenderAttachableImpl.appendLoopOnAppenders(AppenderAttachableImpl.java:51)
ch.qos.logback.classic.Logger.appendLoopOnAppenders(Logger.java:270)
ch.qos.logback.classic.Logger.callAppenders(Logger.java:257)
ch.qos.logback.classic.Logger.buildLoggingEventAndAppend(Logger.java:421)
ch.qos.logback.classic.Logger.filterAndLog_2(Logger.java:414)
ch.qos.logback.classic.Logger.debug(Logger.java:490)