彩虹马的博客

在公司的编程马拉松中前端项目部署在NG的镜像中，其中有个需求是通过浏览器访问时，若请求是前端资源则返回前端页面，如果请求的是后端接口则返回后端响应。如：浏览器访问 http://abc.com/apis/name 时，有可能是前端页面路径，也有可能为后端接口路径。通过NG的条件判断可以实现此需求。 正则匹配 符号 描述 = 字符串比较相等 != 字符串比较不相等 ~ 符合指定正则表达式时返回true（匹配时区分大小写） ~* 符合指定正则表达式时返回true（匹配时不区分大小写） !~ 不符合指定正则表达式时返回true（匹配时区分大小写） !~* 不符合指定正则表达式时返回true（匹配时不区分大小写） NG中的表达式和大多数语言一样 1234567if (<condition1>) { # do something1} if (<condition2>) { # do something2 # return;} 不支持多条件表达式 不支持嵌套 不支持else ...

生产环境网关模块偶发的OutOfDirectMemoryError错误排查起来困难且曲折，2021-02-05号也出现过此问题，起初以为是JVM堆内存过小(当时是2g)导致，后调整到8g(2月5号调整)。但是经过上次调整后5月7号又出现此问题，于是猜测可能是由于网关模块存在内存泄露导致。 症状报错详情网关模块偶现OutOfDirectMemoryError错误，两次问题出现相隔大概3个月。两次发生的时机都是正在大批量接收数据(大约500w)，TPS 60左右，网关服务波动不大，完全能抗住，按理不应该出现此错误。 详细报错信息如下： 123456789101112131415161718192021222021-05-06 13:44:18|WARN |[reactor-http-epoll-5]|[AbstractChannelHandlerContext.java : 311]|An exception 'io.netty.util.internal.OutOfDirectMemoryError: failed to allocate 16384 byte(s) of di ...

Spring通过ApplicationContextAware反射调用服Bean方法，ApplicationContextAware常用方法封装。 1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465666768697071727374757677@Configurationpublic class SpringReflectUtils implements ApplicationContextAware { /** * Spring容器 spring应用上下文对象 */ private static ApplicationContext applicationContext; @Override public void setApplicationContext(ApplicationContext applicationContext) thro ...

症状Nginx刚启动后日志记录正常，一段时间后，Nginx会把已产生的日志压缩为.gz文件。但是一旦压缩后，就不再记录新日志到新生成的access.log文件，但日志文件存在，里面却没有任何日志。旧的日志压缩后没有问题，自从压缩后，新的文件再也不记录新日志了(发现Nginx会很消耗内存，估计日志都存在内存里，不写文件了)。 我们的Nginx部署在k8s中，查看Nginx的配置没有发现任何问题 123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869#user nobody;worker_processes 4;error_log /app/openresty/nginx/logs/error.log error;pid /app/openresty/nginx/logs/nginx.pid;#error_log logs/error.log;#error_lo ...

Loki是受Prometheus启发由Grafana Labs团队开源的水平可扩展，高度可用的多租户日志聚合系统。它的设计具有很高的成本效益，并且易于操作。使用标签来作为索引，而不是对全文进行检索，也就是说，通过这些标签既可以查询日志的内容也可以查询到监控的数据签，极大地降低了日志索引的存储。 简介只要在应用程序服务器上安装Promtail来收集日志然后发送给Loki存储，就可以在Grafana UI界面通过添加Loki为数据源进行日志查询(如果Loki服务器性能不够，可以部署多个Loki进行存储及查询）。作为一个日志系统不光只有查询分析日志的能力，还能对日志进行监控和报警。 Loki是主服务器，负责存储日志和处理查询 。 Promtail是客户端代理，负责收集日志并将其发送给Loki。 Grafana用于UI展示。 Loki架构 Promtail收集并将日志发送给Loki的Distributor组件； Distributor会对接收到的日志流进行正确性校验，并将验证后的日志分批并行发送到Ingester； Ingester接受日志流并构建数据块，压缩后存放到所连接的存储后 ...

引言Grafana是一款可视化工具，有着非常漂亮的图表和布局展示，功能齐全的度量仪表盘和图形编辑器，大多使用在时序数据的监控方面。同时提供监控告警功能。 简介Grafana是一个跨平台的开源的度量分析和可视化工具，可以通过将采集的数据查询然后可视化的展示，并及时通知。它主要有以下特点： 1、展示方式：快速灵活的客户端图表，面板插件有许多不同方式的可视化指标和日志，官方库中具有丰富的仪表盘插件，比如热图、折线图、图表等多种展示方式； 2、通知提醒：以可视方式定义最重要指标的警报规则，Grafana将不断计算并发送通知，在数据达到阈值时通过Slack、PagerDuty等获得通知； 3、混合展示：在同一图表中混合使用不同的数据源，可以基于每个查询指定数据源，甚至自定义数据源；支持白天和夜间模式； 4、注释：使用来自不同数据源的丰富事件注释图表，将鼠标悬停在事件上会显示完整的事件元数据和标记； 5、过滤器：Ad-hoc过滤器允许动态创建新的键/值过滤器，这些过滤器会自动应用于使用该数据源的所有查询。 准备工作安装包grafana下载地址：https://grafana.com/grafana ...

在开发中，比较常用的项目构建工具有Maven、Gradle，自动构建工具可以帮助我们管理项目的外部依赖包、项目编译、打包等。而依赖包冲突又是一个不得不面对的问题，所以了解依赖包的关系传递和构建工具对冲突包的版本选择就很重要了，本文主要介绍下Maven依赖冲突的解决方法。 在Maven中，同一个groupId和artifactId只能使用一个版本。 直接依赖若相同类型但版本不同的依赖存在于同一个pom文件，靠后引用的Jar的版本会覆盖前面的版本，最终会引入最后一个声明的依赖。 12345678910111213<dependencies> <dependency> <groupId>com.github.ben-manes.caffeine</groupId> <artifactId>caffeine</artifactId> <version>3.0.2</version> </dependency> <dep ...

引言Caffeine是一个高性能、高命中率、低内存占用的的本地缓存。它是Guava的加强版，Caffeine使用Window TinyLfu (最近最少频率使用)算法，提供了近乎最佳的命中率。 Caffeine VS Guava CacheSpring5中将放弃Guava Cache作为默认的缓存机制，而改用Caffeine作为本地缓存组件，Spring作出如此大的改变不是没有原因的。在Caffeine的Benchmarks给出了亮眼的数据，对比其他的缓存组件，Caffeine的读写性能都很优异。 Caffeine的使用Caffeine和Guava Cache的api有很多相似之处，熟悉Guava Cache的话上手Caffeine就很简单了。 引入Maven坐标12345<dependency> <groupId>com.github.ben-manes.caffeine</groupId> <artifactId>caffeine</artifactId> <version>${la ...