背景背景如上一篇文章《request.getRequestDispatcher().forward()的妙用以及DispatcherType 对Filter配置的影响》,项目要将服务从虚拟机从迁入docker中，方便自动化部署以及弹性扩容等。闭坑一-应用看到的ip及port是docker的内部ip、端口，外部无法访问应用看到的是docker内部ip及端口，这个是宿主机虚拟出来的，对外部不可见；如果

背景我们应用如上图所示，Nignx做负债均衡，微服务间使用feign进行调用。为了方便鉴权Filter配置拦截的url以及nginx配置对外暴露的url，我们为所有服务设计了统一的url规范类型用途v1/xx给前端用的urlv5/xx内部接口，服务间调用因此所有服务都未配置server.servlet.context-path那么问题来了，现在我们要把服务从虚拟机迁移到docker中。使用公司的d

背景微服务模式下，一次请求可能会经过多个服务。如果没有日志链将单次请求的日志串起来，定位问题时很容易陷入海量的日志中，无法快速定位问题。sleuth是spring cloud中日志链（调用链解决方案），引入该依赖后，日志中会自动添加（traceid，spanid）。当获取到traceid后，可以在kibana或者其他日志收集系统中，精确定位到本次的所有日志。sleuth基本原理很简单，就是在入口生

背景接手了一个系统，该使用了HAProxy + Sentinel +redis方案，该方案在redis发生主从切换后，因为应用层启用了连接池，老连接连的仍然是redis的“老主节点”。当应用层获取到这些老连接进行写操作的时候，会抛出异常。org.springframework.data.redis.RedisSystemException: Error in execution; nested e

背景最近连续解决两起连接泄漏的问题，期间阅读了大量开源源码，发现开源软件中设计的连接池，用的也都是一些常规手段，本文为大家揭开这层神秘的面纱。概述大多数应用中应该都是用的TCP协议，TCP连接在建立阶段会经过3次握手，销毁阶段会经过4次握手。标准网络是分7层的，每一层都有各自的协议头，应用层拿到的有效数据，在整个报文中占比没这么大。TCP握手阶段的报文，对应用层来讲都是额外的负担。所以很多客户端都

项目组最近准备将Redis由哨兵模式组网切换到集群组网，切换后应用访问redis时报错，“Pipeline is currently not supported for JedisClusterConnection.”。初步定为Jedis在集群模式下不支持pipeline。org.springframework.data.redis.connection.jedis.JedisClusterCon

项目组准备将自建的redis切到公司云平台的redis服务；自建的redis用的是哨兵模式，而云平台的提供的redis服务用的是集群模式。切换前先分析redis用到了那些功能，redis集群模式下是否兼容。分析代码时发现，用到了RedisMessageListenerContainer，该类用于监听redis发出的消息(redis的发布订阅功能)。我们使用到了redis键过期通知的特性，来实现超时

我司有一套开源使用规范，衰退期的软件或版本需要升级到GA版本。我们ES服务端是6.8.x的，根据ES官方推荐版本，springdataelasticsearch使用的是3.2.x，配套的springboot版本为2.2.x.我们当前使用的版本已经比较老了，我们需要将springboot升级到2.6.x，并将springdataelasticsearch升级到4.3.x。..............