其实之前也是一直在纠结于要不要入手软路由，所以一直在折腾硬路由。 之前用过企业级华为、华三，对于企业级路由器来说最大的优点在于稳定，带机量来说也是非常稳没有问题，但是企业级路由器带动的最大带宽来说可谓非常小，要想使用企业级路由器带动500M以上的带宽价格非常惊人，至少得2000+以上吧，目前的预算对于家用来说顶多就1000多，不得已舍弃这个方案了。 当然同时也入手了华为家用路由器，这个倒是可以带得动，但是感觉跟企业路由器来比较稳定性还是差了不少。 纠结再三，入手一台工控机软路由，入手的不包括内存以及硬盘，内存之前有存货、硬盘也有多余的SSD，直接装上。 硬件的基本配置信息如下，CPU 为J4205 试用了一下，下载、上网还是非常稳的，预测峰值可以达到带宽接近1000M左右。
Gitlab-ce 13.4.x版本谨慎升级
系统环境： 操作系统：centos6.10 安装方式：yum 公司一台老服务器，采用yum方式每次自动升级gitlab-ce版本，从未出现过问题，但是对于最新发布的13.4.x不断出现问题，首先由13.3.6 升级至13.4.0版本时，出现所有记录都在无法拉取更新，无法提交的错误BUG。 而后升级13.4.1时，可以进行代码更新，但无法push的诡异问题。 对于13.4.x版本还需谨慎升级，即使要升级测试，升级前一定做好备份再升级测试，否则连数据都无法找回了。
RHEL7.X 切换Centos源
有些客户很奇怪的思维，提供个操作系统非要用rhel版本的，又不想花钱，然后又要进行等保检测，一检测好几百个高危漏洞。 这不又有客户提供了RHEL7.X版本系统，安装个软件异常费劲，将其转换为centos源吧，这样安装软件还方便些。 一、首先卸载原来的yum 二、安装新yum安装包 打开国内华为源： https://repo.huaweicloud.com/centos/7/os/x86_64/Packages/ 找到对应的版本文件下载 安装下载的文件 下载华为源 然后将CentOS-Base.repo 中的 $releasever 替换为7，因为系统不识别该变量，准备更新 关闭红帽的注册订阅提示 在/etc/yum/pluginconf.d/subscription-manager.conf文件下 设置：enabled=0
spring boot内嵌undertow配置一定要优化
问题 接上篇文章 K8S集群中高并发应用undertow线程数不足引起的重启，产生的原因则是使用的undertow的系统默认配置，undertow线程数不足引起的问题。 建议 undertow默认配置情况下，官方默认配置的是 CPU核数*8，比如8核CPU，实际工作线程数也就8*8=64，这个配置对于高并发场景来看，一台8核CPU的机器一般内存都会32G或以上，即使跑满64线程，占用的资源远远无法充分利用该机器的性能。 当然啦，官方也是建议工作线程数的配置，取决于你机器的负载情况，其实也就是跟你的具体业务有关，我们现在的业务场景，64线程跑满的情况，CPU利用率仅仅百分之十几、CPU内存远远没利用完，再有请求过来，undertow则直接阻塞队列中，无法正常处理，资源浪费严重，还导致了服务中断的情况。 因此，从实际情况来看，一定不要采用undertow的官方默认配置。像我们线上业务来看，每个API接口业务耗时大多数在10ms以内，少部分耗时30-50ms时间，单接口耗用资源不大。 修改undertow配置 worker-threads=256，单节点可以承载256的并发任务，剩下的就是根据实际业务情况动态扩展节点数量即可。 io-threads：IO线程数, 它主要执行非阻塞的任务，它们会负责多个连接，默认设置每个CPU核心一个线程，不可设置过大，否则启动项目会报错：打开文件数过多。 worker-threads：阻塞任务线程池，当执行类似servlet请求阻塞IO操作，undertow会从这个线程池中取得线程。它的值取决于系统线程执行任务的阻塞系数，默认值是 io-threads*8，这里我们手动指定相应的值。 server: port: 1112 undertow: io-threads: 8 worker-threads: 256
K8S集群中高并发应用undertow线程数不足引起的重启
问题 在高并发环境时间段，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以上吧。
阿里云ECS Linux 更新内核后无法启动问题
阿里云ECS Linux 更新内核后无法启动，启动时报错 unable to mount root fs on unknow-block。 从虚拟化基础架构上来讲，阿里云肯定是百分百支持这个内核的，因为官方是支持最新centos7.8 以及centos8.x操作系统的，只是从老版本进行升级时，估计有可能有些地方未处理好。 解决办法 经过测试，在阿里云张家口数据中心、北京数据中心，同样100%相同的硬件配置、软件配置也相同的服务器，张家口数据中心随机性的出现该问题。而北京数据中心同样配置的机器从未出现过。 主要原因是由于操作系统打了补丁包，更新了centos官方的kernel，一般来说更新来自官方的补丁包很少会出现无法启动的情况。 联系阿里云客服，客服给出的回复是这是很正常的情况，更新了内核会随机出现无法启动的情况非常正常，新内核会出现未知异常，切换到老内核就行。 最终处理方法 那只能自己处理吧，通过VNC远程连接，切换到老的正常内核，把最新更新的内核删除掉，重新安装最新内核，然后重启就一切恢复正常了。