微服务应用容器化场景中常见问题总结

简介：云原生技术栈是下一代应用转型的必然选择，它包含了微服务架构，DevOps和容器技术。对于微服务架构来说，应用是“第一公民”，他逐渐蚕食原来底层软件或者硬件的功能，例如服务注册与发现以及负载均衡；而对于容器平台来说，容器是“第一公民”，他提供了容器注册与发现和负载均衡，同时容器技术将应用和外面的世界做了隔离，这样很多应用运行的假设就会失效。那当微服务应用运行在容器中的时候，我们会遇到哪些常见问题？我们又该如何解决呢？

企业应用在向微服务架构转型的过程中，微服务如何划分是最基本的问题。我们可以通过业务架构的梳理来理解业务，并同时使用领域设计的方法进行微服务的设计。其次，我们需要做系统设计，系统设计会更关注性能、可用性、可扩展性和安全性等；当然，我们还需要做接口设计，定义微服务之间的契约。

Java在企业中被广泛应用，当前，选择Spring Cloud作为微服务开发框架成为一个广泛的趋势。微服务架构的复杂性需要容器技术来支撑，应用需要容器化，并使用CaaS平台来支撑微服务系统的运行。

本文探讨的主题是来自于企业级Java应用在容器化过程中遇到的基础问题（与计算和网络相关），希望以小见大探讨微服务转型过程中遇到的挑战。

容器内存限制问题

让我们来看一次事故，情况如下：当一个Java应用在容器中执行的时候，某些情况下会容器会莫名其妙退出。

1.Dockfile如下：

FROM airdock/oracle-jdk:latest
MAINTAINER Grissom Wang <grissom.wang@daocloud.io>
ENV TIME_ZONE Asia/Shanghai
RUN echo "$TIME_ZONE" > /etc/timezone
WORKDIR /app
RUN apt-get update
COPY myapp.jar /app/ myapp.jarEXPOSE 8080CMD [ "java", "-jar", "myapp.jar" ]

2.运行命令

docker run –it –m=100M –memory-swap=100M grissom/myapp:latest

3.日志分析

执行docker logs container_id，出现了java.lang.OutOfMemoryError。

4.问题初步分析

因为我们在执行容器的时候，对内存做了限制，同时在Java启动参数重，没有对内存使用做限制，是不是这个原因导致了容器被干掉呢？

当我们执行没有任何参数设置（如上面的myapp）的 Java 应用程序时，JVM 会自动调整几个参数，以便在执行环境中具有最佳性能，但是在使用过程中我们逐步发现，如果让 JVM ergonomics (即JVM人体工程学，用于自动选择和行为调整)对垃圾收集器、堆大小和运行编译器使用默认设置值，运行在容器中的 Java 进程会与我们的预期表现严重不符（除了上诉的问题）。

首先我们来做一个实验：

1.在我本机（Mac）上执行docker info命令

Server Version: 17.06.0-ce
Kernel Version: 4.9.31-moby
Operating System: Alpine Linux v3.5OSType: linuxArchitecture: x86_64CPUs: 2Total Memory: 1.952GiBName: moby

2.执行docker run -it -m=100M –memory-swap=100M debian cat /proc/meminfo

MemTotal:        2047048 kB = 2GMemFree:          609416 kB = 600MMemAvailable:    1604928 kB = 1.6G

虽然我们启动容器的时候，指定了容器的内存限制，但是从容器内部看到的内存信息和主机上的内存信息几乎一致。

因此我们找到原因了：docker switches（-m，-memory和-memory-swap）在进程超过限制的情况下，会指示 Linux 内核杀死该进程。但 JVM 是完全不知道限制，因此会很有可能超出限制。在进程超过限制的时候，容器进程就被杀掉了！

解决问题的一种思路就是使用JVM参数来限制内存的使用，这个需要根据JVM内存参数的定义来做巧妙的设置，但是幸运的是从Java SE 8u131和JDK 9开始，Java SE开始支持Docker CPU和内存限制。

具体实现逻辑如下：如果-XX：ParalllelGCThreads或-XX：CICompilerCount未指定为命令行选项，则JVM将Docker CPU限制应用于JVM在系统上看到的CPU数。然后JVM将调整GC线程和JIT编译器线程的数量，就像它在裸机系统上运行一样，其CPU数量设置为Docker CPU限制。如果-XX：ParallelGCThreads或-XX：CICompilerCount指定为JVM命令行选项，并且指定了Docker CPU限制，则JVM将使用-XX：ParallelGCThreads和-XX：CICompilerCount值。

对于Docker内存限制、最大Java堆的设置还有一些工作要做。要在没有通过-Xmx设置最大Java堆的情况下告知JVM要注意Docker内存限制，需要两个JVM命令行选项：

-XX：+ UnlockExperimentalVMOptions-XX：+ UseCGroupMemoryLimitForHeap。

-XX：+ UnlockExperimentalVMOptions是必需的，因为在将来版本中，Docker内存限制的透明标识是目标。当使用这两个JVM命令行选项，并且未指定-Xmx时，JVM将查看Linux cgroup配置，这是Docker容器用于设置内存限制的方式，以透明地指定最大Java堆大小。 Docker容器也使用Cgroups配置来执行CPU限制。

服务注册与发现

在微服务的场景中，运行的微服务实例将会达到成百上千个，同时微服务实例存在失效，并在其他机器上启动以保证服务可用性的场景，因此用IP作为微服务访问的地址会存在需要经常更新的需求。

服务注册与发现就应用而生，当微服务启动的时候，它会将自己的访问Endpoint信息注册到注册中心，以便当别的服务需要调用的时候，能够从注册中心获得正确的Endpoint。

如果用Java技术栈开发微服务应用，Spring Cloud（https://spring.io/）将会是大家首选的微服务开发框架。Spring Cloud Service Discovery就提供了这样的能力，它底层可以使用Eureka（Netflix），ZooKeeper，ETCD。这里我们以使用Spring Cloud Eureka为例（使用Spring Cloud Eureka的文档可以参考http://cloud.spring.io/spring-cloud-static/spring-cloud-netflix/1.3.1.RELEASE/）。

在本机运行如下命令：

java -jar target/discovery-client-demo-0.0.1-SNAPSHOT.jar

该应用会将自己的信息注册到本地Eureka。我们可以通过打开Eureka的Dashboard，看到如下信息：

图 1 物理机上运行Eureka Client

我们可以看到应用的如下信息：

•   名称：discovery-client-demo•   IP: 10.8.0.67•   Port: 9090

但是我们在容器化场景中，遇到了问题。Dockerfile如下：

FROM airdock/oracle-jdk:latest
MAINTAINER Grissom Wang <grissom.wang@daocloud.io>ENV TIME_ZONE Asia/Shanghai
RUN echo "$TIME_ZONE" > /etc/timezone
WORKDIR /app
RUN apt-get update
COPY target/discovery-client-demo-0.0.1-SNAPSHOT.jar /app/discovery-client-demo.jar
EXPOSE 8080CMD [ "java", "-jar", "discovery-client-demo.jar" ]

假设我们现在在本机使用Docker run命令执行容器化discovery-client-demo，命令行如下：

docker run -d --name discovery-client-demo1 -e eureka.client.serviceUrl.defaultZone=http://10.8.0.67:8761/eureka/ -e spring.application.name=grissom  -p 8080:8080 discovery-client-demo:latestdocker run -d --name discovery-client-demo2 -e eureka.instance.prefer-ip-address=true –e eureka.client.serviceUrl.defaultZone=http://10.8.0.67:8761/eureka/ -e spring.application.name=grissom2  -p 8081:8080 discovery-client-demo:latest