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

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 简介 云原生技术栈是下一代应用转型的必然选择,它包含了微服务架构,DevOps和容器技术。对于微服务架构来说,应用是“第一公民”,他逐渐蚕食原来底层软件或者硬件的功能,例如服务注册与发现以及负载均衡;而对于容器平台来说,容器是“第一公民”,他提供了容器注册与发现和负载均衡,同时容器技术将应用和外面的世界做了隔离,这样很多应用运行的假设就会失效。

简介

云原生技术栈是下一代应用转型的必然选择,它包含了微服务架构,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.jar
EXPOSE 8080
CMD [ "java", "-jar", "myapp.jar" ]
AI 代码解读

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.5
OSType: linux
Architecture: x86_64
CPUs: 2
Total Memory: 1.952GiB
Name: moby
AI 代码解读

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

MemTotal:        2047048 kB = 2G
MemFree:          609416 kB = 600M
MemAvailable:    1604928 kB = 1.6G
AI 代码解读

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

因此我们找到原因了: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。 
AI 代码解读

-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,看到如下信息:
20171002162320920

图 1 物理机上运行Eureka Client

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

   名称:discovery-client-demo
   IP: 10.8.0.67
   Port: 9090
AI 代码解读

但是我们在容器化场景中,遇到了问题。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 8080
CMD [ "java", "-jar", "discovery-client-demo.jar" ]
AI 代码解读

假设我们现在在本机使用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:latest
docker 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
AI 代码解读

前后两个容器的区别在于,第二个指示应用注册的使用IP,而默认是Hostname。

打开Eureka的Dashboard,我们可以看到如下信息:
2

图 2 容器中运行Eureka Client

调用Eureka的Apps接口,我们可以看到更加详细的信息:
3

图 3 注册应用的详细信息

这个时候我们发现了问题,两个应用注册的信息中,Hostname, IP和端口都使用了容器内部的主机名,IP和端口(如8080)。这就意味着在Port-Mapping的场景下,应用注册到Eureka的时候,注册信息无法被第三方应用使用。

解决这个问题的第一个思路如下:
4

图 4 对Eureka进行扩展

我们对Eureka进行扩展,对所有客户端过来的请求进行拦截,然后从Docker Daemon中拿到正确的外部访问信息来进行替换,从而确保注册到Eureka中的信息是外部能够访问的。

该方案需要做的工作:

• 需要同时对Eureka Client和Server改造,能够在Client上报的信息中加入container ID等信息。
• Eureka服务端需要加入一个过滤器,需要对所有的注册请求进行处理,根据container ID将内部hostname,IP和端口改为外部可以访问的IP和端口。

该方案的挑战:

• 因为只有容器被创建后才有ID,无法在启动参数中指定,因此应用在容器启动的时候,无法拿到容器的ID。

• 对于Eureka Server和Client的改造,无法贡献回社区,因此需要自己维护版本,存在极大的风险。

AWS的EC2 提供了实例元数据和用户数据的API,它可以通过REST API的方式供运行在EC2内部的应用使用。API形式如下:
http://169.254.169.254/latest/meta-data/
其中IP地址是固定的一个IP地址。

因此我们也可以提供一个类似的元数据和用户数据API,供容器内部的应用调用。同时为了减少对应用的侵入,我们可以在应用启动之前执行一个脚本来获取相应的信息,并设置到环境变量中,供应用启动后读取并使用,流程如下:
5

图 5 方案流程

总结
本文总结了使用Java开发的企业级应用在向微服务架构应用转型过程中,在容器化运行过程中遇到的常见问题、原因分析及解决方法。总结下来,由于容器技术的内在特性,我们需要对应用做一些改造,同时相应的工具如JVM也需要对容器有更好的本地支持。

原文链接:http://geek.csdn.net/news/detail/238739

目录
打赏
0
0
0
0
8
分享
相关文章
微服务——SpringBoot使用归纳——Spring Boot事务配置管理——常见问题总结
本文总结了Spring Boot中使用事务的常见问题,虽然通过`@Transactional`注解可以轻松实现事务管理,但在实际项目中仍有许多潜在坑点。文章详细分析了三个典型问题:1) 异常未被捕获导致事务未回滚,需明确指定`rollbackFor`属性;2) 异常被try-catch“吃掉”,应避免在事务方法中直接处理异常;3) 事务范围与锁范围不一致引发并发问题,建议调整锁策略以覆盖事务范围。这些问题看似简单,但一旦发生,排查难度较大,因此开发时需格外留意。最后,文章提供了课程源代码下载地址,供读者实践参考。
95 0
|
25天前
|
如何对应用代码进行优化以提高在Docker容器中的性能?
如何对应用代码进行优化以提高在Docker容器中的性能?
154 1
|
25天前
|
如何对迁移到Docker容器中的应用进行性能优化?
如何对迁移到Docker容器中的应用进行性能优化?
168 58
126. [HarmonyOS NEXT 实战案例二:SideBarContainer] 侧边栏容器实战:电商应用商品筛选侧边栏 进阶篇
在基础篇中,我们已经实现了电商应用商品筛选侧边栏的基本布局和功能。在本篇教程中,我们将深入探讨如何通过状态管理和数据绑定,实现更加复杂的交互功能,提升用户体验。
61 2
126. [HarmonyOS NEXT 实战案例二:SideBarContainer] 侧边栏容器实战:电商应用商品筛选侧边栏 进阶篇
|
2月前
|
125.[HarmonyOS NEXT 实战案例二:SideBarContainer] 侧边栏容器实战:电商应用商品筛选侧边栏 基础篇
在现代电商应用中,商品筛选功能是提升用户购物体验的关键元素。HarmonyOS NEXT提供的`SideBarContainer`组件非常适合实现这类功能,它可以创建一个可显示和隐藏的侧边栏,用于放置各种筛选条件,帮助用户快速找到心仪的商品。
64 1
125.[HarmonyOS NEXT 实战案例二:SideBarContainer] 侧边栏容器实战:电商应用商品筛选侧边栏 基础篇
|
2月前
|
124.[HarmonyOS NEXT 实战案例一:SideBarContainer] 侧边栏容器实战:新闻阅读应用侧边栏布局 进阶篇
在基础篇中,我们学习了如何使用HarmonyOS NEXT的`SideBarContainer`组件创建新闻阅读应用的基本侧边栏布局。本篇教程将深入探讨如何为新闻阅读应用添加更多交互功能和状态管理,提升用户体验。
72 1
124.[HarmonyOS NEXT 实战案例一:SideBarContainer] 侧边栏容器实战:新闻阅读应用侧边栏布局 进阶篇
123. [HarmonyOS NEXT 实战案例一:SideBarContainer] 侧边栏容器实战:新闻阅读应用侧边栏布局 基础篇
在现代移动应用和平板应用中,侧边栏导航已经成为一种常见且实用的UI设计模式。HarmonyOS NEXT提供了专门的`SideBarContainer`组件来实现这一功能,它能够轻松创建可显示和隐藏的侧边栏布局,非常适合新闻阅读、电子商务、文件管理等应用场景。
72 3
123. [HarmonyOS NEXT 实战案例一:SideBarContainer] 侧边栏容器实战:新闻阅读应用侧边栏布局 基础篇
云原生时代的应用架构演进:从微服务到 Serverless 的阿里云实践
云原生技术正重塑企业数字化转型路径。阿里云作为亚太领先云服务商,提供完整云原生产品矩阵:容器服务ACK优化启动速度与镜像分发效率;MSE微服务引擎保障高可用性;ASM服务网格降低资源消耗;函数计算FC突破冷启动瓶颈;SAE重新定义PaaS边界;PolarDB数据库实现存储计算分离;DataWorks简化数据湖构建;Flink实时计算助力风控系统。这些技术已在多行业落地,推动效率提升与商业模式创新,助力企业在数字化浪潮中占据先机。
273 12
微服务——MongoDB的应用场景
随着Web2.0时代的到来,传统关系型数据库(如MySQL)在高并发读写、海量数据存储及高可扩展性需求方面逐渐力不从心。而MongoDB凭借其灵活的文档结构和高效性能,在社交、游戏、物流、物联网和视频直播等场景中表现出色。这些场景通常具有数据量大、写入频繁且对事务要求不高的特点。选择MongoDB适合以下情况:应用无需复杂事务与join支持、需求不确定需快速迭代、需处理高QPS读写或超大规模数据存储、追求高可用性和快速水平扩展能力。相比MySQL,MongoDB能以更低的学习、开发和运维成本满足现代应用需求。
138 0
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
111 0
ACK 容器监控存储全面更新:让您的应用运行更稳定、更透明
下一篇
BFE 初探
AI助理

你好,我是AI助理

可以解答问题、推荐解决方案等

登录插画

登录以查看您的控制台资源

管理云资源
状态一览
快捷访问