微服务时代基于Docker容器开发运维趟坑实战36计

Posted 2021-04-21 用友云

微服务时代，大家越来越感受到分而治之带来的好处：不同的模块可以充分的解耦，各团队之间可以专注于自己擅长的核心领域，将业务打磨精专。然而微服务的拆分，也带来了另外一面的复杂度，那就是业务开发联调成本的提高。以前单体应用可以在团队内部搞定了的问题，现在需要依赖于其他团队的服务。如果服务一旦出现问题，由于链路变长，导致排查定位变得比以往困难很多。

本文根据近期大家联调过程中出现的一些问题，做了一些梳理。其内容涉及人力云、协同云、财务云、云平台等多个领域。大家在奋战的过程中相互帮助，在掉坑与爬坑中不断进步。经过不断磨合，研发调试上线过程慢慢顺畅起来。本期梳理出趟坑36计中的8计，后续会不断梳理输出其他部分给大家，一起进步，防止遇到类似问题掉坑翻车。

1

应用访问时出现504错误

发现问题

应用不能正常访问，在浏览器中提示504错误，查看容器内部僵死。

根因分析

应用通过域名不能正确访问，显示504错误，或者是长时间卡住不动。

通过控制台进入到容器里面，通过

curl localhost:8080

命令也不能访问，证明应用自身已死掉。

应用日志没明显异常信息，通过jstack打出堆栈信息，发现大量的logback写日志线程等待。

网上也有同学遇到多线程死锁问题，供参阅：

https://blog.csdn.net/shipengyy/article/details/50184709

解决办法

将应用代码中，logback配置文件里，向console打日志的部分注释掉。

2

应用联调测试环境时好时坏

发现问题

应用联调测试过程中，调用时好时坏，环境一天可用时间难以保证。

根因分析

测试某个功能，一会好用，一会不好用了。此时，某些同学修改了代码，进行了服务的重启。导致重启的过程中，服务调用失败。

由于服务调用链路比较多而且繁杂，只要其中一个环节不可用，就会导致整个功能测试中断，让大家保持步调一致，以提升环境稳定性。

解决办法

约定大家的测试环境更新时间，更新（代码、修改配置、数据库）的时间为12:00-13:00、17:30-18:30。

3

应用已僵死，但状态仍显示健康

发现问题

应用的健康状态显示正常，但应用实际已僵死，不能准确感知应用状态

根因分析

由于默认是基于端口进行健康检查，所以显示的状态是端口存活状态，不能真实的反馈出来应用的健康度。

如果配置了http方式的检查url，可以根据检查mysql、redis、核心服务等方式，确定服务的健康状况。

解决办法

增加http的健康检查url，如：/healthcheck，并编写详细的检查逻辑。

4

微服务调用不通

发现问题

微服务调用时，发现调用接口不通。

根因分析

线上的测试环境，服务调用失败，报网络错误。

一般是本地的服务注册到线上了，或者是停掉的服务，没能及时的从服务注册中心注销掉，导致服务消费方，调用到了坏的服务提供方。

解决办法

将本地IDE中启动的微服务，环境改对，防止线上服务调用到本地笔记本上的情况（或拔掉网线）。

其他情况，也可以联系运维同学，帮大家从后台杀掉野服务或状态不同步的服务。

5

应用重启升级时，异常实例还存在

发现问题

将应用重启或升级时，健康状态为异常容器实例仍然存在。

根因分析

应用升级的过程中，由于线程死锁或等待状态，导致发送了kill信号后，容器不能及时被杀掉。

用户只能等在那，点击销毁实例按钮，也不生效，待优雅退出后，才能完成升级。

导致这个问题的原因主要有两种：

1. 大量请求访问，存在大量积压的线程

2. 应用本身线程死锁，状态异常

解决办法

平台优化调度器，对于不能优雅退出的应用，增加强杀策略。

6

应用管理详情中的日志不显示或有延迟

发现问题

在应用管理详情页面中，点击日志，发现日志不显示，或者显示有延迟现象

根因分析

在应用详情页面中，通过日志页签查看到的日志不是最新的。

由于目前容器服务巨多，日志输出量巨大，日志收集服务器不能及时处理如此多的海量数据，导致收集的日志写入ES时，有延时。

解决办法

通过“应用日志”和“错误日志”按钮查看实时的日志信息，也可以进入到控制台，通过tail命令查看相应的日志文件。

7

应用发布失败，提示无可用资源

发现问题

应用在构建后进行发布操作，结果失败，显示问题为可用资源为0。

根因分析

应用通过流水线构建成功，最终部署的时候，提示失败。查看资源池剩余资源，发现剩余资源确实不足。

解决办法

向资源池中添加新机器，增加可用的计算资源。

8

服务调用超时，一些环节提前关闭

发现问题

服务调用提示超时，链路上某些环节提前关闭了连接。

根因分析

有些服务，导集团数据时大约需要5分钟，由于某些负载均衡的超时时间是30s，导致某个请求结束后，不能正常返回处理结果。

但是，强烈建议将这些长时间处理的任务，改为异步方式，防止同步调用造成的超时等待。

微服务和Docker容器是一个完美的结合，这种模式可以将封装好的服务，不断的运输到运行环境中。结合DevOps的理念，可以通过流水线，多套环境隔离管理等方式，提升研发的效率。

解决办法

将各负载均衡的超时时间调大，SLB、nginx、HaProxy、MLB等，目前调整为 Nginx：600s；MLB：180s。

【用友云平台相关阅读】

用友云平台，赋予工业互联网平台坚实的PaaS支撑

企业数字化、智能化需软硬兼备

专属云计算平台落地，加速企业数字化转型

用友云平台，真正的云原生架构，加速云应用落地

【企业上云实践】国药集团基于用友云平台构建数字化基石

观点|用友云战略升级及云平台技术架构解析

云平台|行政审批不再“跑断腿” 用友领跑云审批技术