问题 在高并发环境时间段，K8S集群中，前端接口应用被强制重启，其中未有异常日志。 环境 项目采用Spring Cloud微服务架构，全部打包docker镜像。 undertow做Web容器 – undertow版本—— 2.0.28.Final。 使用阿里云K8S容器服务部署。 Spring Boot版本——2.2.1.RELEASE。 原因 直接说原因吧，由于undertow web容器，采用了默认配置，没有手动分配线程数，而导致默认线程数过小，系统响应超时，而集群心跳检测时无法响应，认为应用已经挂掉，则强制重启了应用。 默认情况下，undertow的工作线程是以系统获取的CPU个数为基础分配计算的，当CPU数与2取最大值=io-worker，测试了一下，容器内部获取CPU为1，则 io-worker =2。 而workerThreads= ioThreads * 8 ，实际值则为16，一个实例仅16个线程，明显无法满足需求，导致大量等待请求，最终被强制重启。 undertow官方源码可参考如下： https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/Undertow.java ioThreads = Math.max(Runtime.getRuntime().availableProcessors(), 2); workerThreads = ioThreads * 8; 解决办法 最简单的办法，则是手动配置workerThreads值，这个是比较重要的参数，根据服务器的配置设置相应的值，一般来说最少128以上吧。
Archive for the ‘技术’ Category
K8S集群中高并发应用undertow线程数不足引起的重启
Thursday, July 16th, 2020阿里云ECS Linux 更新内核后无法启动问题
Wednesday, June 3rd, 2020阿里云ECS Linux 更新内核后无法启动，启动时报错 unable to mount root fs on unknow-block。 从虚拟化基础架构上来讲，阿里云肯定是百分百支持这个内核的，因为官方是支持最新centos7.8 以及centos8.x操作系统的，只是从老版本进行升级时，估计有可能有些地方未处理好。 解决办法 经过测试，在阿里云张家口数据中心、北京数据中心，同样100%相同的硬件配置、软件配置也相同的服务器，张家口数据中心随机性的出现该问题。而北京数据中心同样配置的机器从未出现过。 主要原因是由于操作系统打了补丁包，更新了centos官方的kernel，一般来说更新来自官方的补丁包很少会出现无法启动的情况。 联系阿里云客服，客服给出的回复是这是很正常的情况，更新了内核会随机出现无法启动的情况非常正常，新内核会出现未知异常，切换到老内核就行。 最终处理方法 那只能自己处理吧，通过VNC远程连接，切换到老的正常内核，把最新更新的内核删除掉，重新安装最新内核，然后重启就一切恢复正常了。
idea开发 SpringBoot启动报错 程序包org.springframework.boot不存在
Thursday, May 28th, 2020环境 jdk 1.8、jdk11 idea版本为：2020.1、2020.1.1 spring boot 版本为：2.2.x，spring cloud版本为：Hoxton.RELEASE 问题 idea开发 SpringBoot启动报错 程序包org.springframework.boot不存在，而使用maven 命令直接执行时无任何问题，不会报错，仅在idea 中build时出现问题。100%可以保证，引入的pom文件是全的不会有问题，配置也不会有任何问题。 经过测试应该是某种条件下触发，spring boot 版本为2.2.x ,出现问题的idea版本为 2020.1、2020.1.1，但并不是百分百复现，出现问题的一般是升级到这两个版本的idea出现，一旦出现即使重装idea、删除本地maven缓存库、重新import包也都无法解决。 解决办法 经过多次测试、分析，基本可以确定这个问题是idea版本 2020.1、2020.1.1的BUG，将idea版本降级 ideaIU-2019.3.4.exe其他任何地方无需改动，即可解决。 这个BUG问题感觉非常严重，只要升级到这最新版，触发了这个BUG，就没有别的办法了，除非更换之前旧的idea版本方可解决。
国内镜像源在线安装 Elasticsearch最新版
Tuesday, May 26th, 2020国内几大厂商的开源镜像服务用的比较多的一般为阿里云镜像、华为云镜像、清华大学开源软件镜像站 等，其中感觉清华大学开源软件镜像站是国内比较早，一直是比较齐全，质量比较不错的。 本月清华大学开源软件镜像站姊妹站北京外国语大学镜像站https://mirrors.bfsu.edu.cn/ 也正式上线，基本上一个模子下来的，目前由于上线时间较短，用的人少，速度非常不错，把几个主要服务器镜像站修改为这里。清华大学的镜像站由于使用人数较多，在高峰时略有卡顿。 在国内提供Elasticsearch镜像的还是非常少的，其中清华大学开源软件镜像站、北京外国语大学镜像站都是有提供的，点赞一个。 包括老版的2.x版本，新版的5.x – 7.x 版本全系列均有提供。 进行国内源配置 国内镜像源安装速度超级快，可以达到带宽上限。 安装完成后，基本生产环境的配置可以参考 https://www.jiucool.org/elasticsearch-memory/ ，是完全一样的。 该版本elasticsearch 安装时自带jdk,安装目录为：/usr/share/elasticsearch/jdk/bin/java，为最新的jdk14 版本。
Mysql保存时间datetime时，相差13小时的问题
Monday, May 25th, 2020起因 近期一个项目报告，线上服务器时间不对，比正常时间相差了13个小时，同一个数据库不同的应用端写入时间不对。 一般程序相差N个小时的问题，应该说99.99%是时区问题引起的，紧接着我们需要检查各环境的时区配置，当前数据库是使用的阿里云RDS 5.7。 排查 校验服务器时间，结果无误，正常的东八区时间。 校验docker容器内部时间，结果无误，正常的东八区时间。 校验jvm虚拟机时间配置，结果无误，正常的东八区时间。 校验mysql服务器的时间配置，结果无误，是正确的，不过时区项显示的是：CST时区，突然明悟。 CST 时区 名为 CST 的时区是一个很混乱的时区，有四种含义： 美国从“3月11日”至“11月7日”实行夏令时，美国中部时间改为 UTC-05:00，与 UTC+08:00 相差 13 小时。 为什么老的应用程序写入数据是没有问题的，而新应用有问题呢？差别就在于老系统中mysql驱动为老版本，而新系统采用了最新的mysq8.x驱动，新驱动与老驱动的处理方式的差异导致。 解决方法(其中一种即可) 直接将 mysql配置参数中的 system_time_zone修改为 +8:00，default-time-zone = ‘+08:00’ 重启mysql生效。 在java程序mysql连接地址上添加参数 serverTimezone=Asia/Shanghai，重新发布程序即可，由于线上数据库不能轻易重启，我们采用滚动升级方式，无缝升级应用程序解决该问题。
ElasticSearch之集群配置问题：无法构建集群
Tuesday, May 5th, 2020系统环境 Elasticsearch版本：7.6.2，安装方式为：rpm OS版本：CentOS Linux release 8.1.1911 (Core) 上次我们在开发环境中构建集群，方式非常简单Elasticsearch基础之快速搭建开发环境集群（7.6.2），对于生产环境环境中的安装官方推荐为rpm，对于该种方式的注意点简单整理一下。 问题：无法构建集群 目标：两台独立服务器配置集群，当然啦，正式环境中推荐最少要三台。 IP分别为：192.168.50.21、192.168.50.108 两台机器配置文件类似如下： 分别启动成功后，显示如下，”cluster_uuid” : “_na_” 表示各自独立并没有组建集群 查询系统日志显示如下： 通过该日志分析得知，由于我们配置的network.host: 0.0.0.0,而主机上默认安装了docker环境，导致有多个IP，并且172.18.0.1这样的IP跟其他机器是不通的，所以问题点就找到了，在自动进行集群内部交互时，不一定选择本机的哪一个IP，导致集群内部网络不通。 我们需要重新配置network.host为我们指定的服务器IP地址192.168.50.21、192.168.50.108。 注意：修改完配置后，需要清空一下data文件夹才会生效，然后我们重启服务systemctl restart elasticsearch 集群恢复正常。 当然对于一台服务器只有一个IP的情况是不会存在该问题的。