搬砖小抄

使用RabbitMQ进行消息传输有以下几个地方可能会丢失数据:

• 1: 投递失败，即producer → RabbitMQ的传输过程中发生意外，RabbitMQ没拿到消息。
• 2: RabbitMQ自己把消息弄丢了
• 3: 消费失败，包含RabbitMQ → consumer的传输过程中发生意外，以及consumer在处理消息的时候发生异常。

对于第三点，网上有些文章的观点是只要消费方成功收到消息就是算完成可靠传输

消息传输的过程如下图所示

前几天看见有人在frp提工单问是否可以支持windows服务,正好有解决类似问题的经验，于是给作者提了一个PR，不过作者表示：

1. 类似脚本打算放到专门的仓库中维护
2. 那个专门仓库目前无人维护

那就是没法了，只能记在自己的小本子上了。

效果演示

表现

• 在集群网络中ping另外一个Service，网络不通
• 对另外一个Service进行dns解析，报错

部署一个netshoot服务，测试结果如下:

1
2
3
4
5

bash-5.0# ping my-service
ping: my-service: Try again
bash-5.0# nslookup my-service
;; reply from unexpected source: 10.42.3.60#53, expected 10.43.0.10#53
;; reply from unexpected source: 10.42.3.60#53, expected 10.43.0.10#53

假设因为某种原因，你想对已经部署的java应用进行调试，应该怎么做呢？我假设你的部署环境是这样子的：

• 你的应用跑在kubernetes中
• 你的开发机不没有加入kubernetes集群，换而言之，你的开发机和应用的网络是不通的。
• 你的容器启动命令并没有预留JVM远程调试参数(实际上也不可能在正式环境加这个参数)。

也就是说，虽然我们知道可以利用JVM的远程调试功能来解决这个问题，但是具体实施的时候，还需要解决以下问题：

1. 打通开发机和JAVA应用之间的网络
2. 不能重新打docker镜像,但是需要给JAVA应用的增加远程调试的启动参数

这里先给出解决办法:对于第一个问题，可以通过kubernetes对外暴露服务端口来实现，第二个问题则通过JAVA_TOOL_OPTIONS这个环境变量来解决。

在部署web应用时，常常会遇到跨域的问题，而spring cloud gateway作为一个API网关，本身是支持跨域的。这里暂不讨论应不应该开启跨域，只是总结一下：

• 如何开启跨域
• 解决的实际问题

以下这段配置，放到spring cloud gateway里面，即可开启跨域，放行任何跨域请求

1
2
3
4
5
6
7
8
9
10
11

spring:
  cloud:
    gateway:
      globalcors:
        corsConfigurations:
          '[/**]':
            allowCredentials: true
            exposedHeaders: "Content-Disposition,Content-Type,Cache-Control"
            allowedHeaders: "*"
            allowedOrigins: "*"
            allowedMethods: "*"

不要完全照抄这段代码，搞到你的生产环境里面去，原因请阅读相关文档，先了解跨域资源共享(CORS) 。

公司的某个微服务运行在公司内网的容器网络中，该微服务需要接收某个第三方服务的推送消息。显然，那个第三方服务器无法直接推送消息，需要打通网络

• 在公网部署FRP服务端(FRPS)
• 在K8S集群中部署FRP客户端(FRPC)

预期效果如下

官方对nacos的介绍是：一个更易于构建云原生应用的动态服务发现、配置管理和服务管理平台

目前最新版本是1.2

在开发过程中，有时候需要自己搭建一个nacos服务,官方也提供了相应的部署文档,但最简单的还是使用容器技术。

以下是官方对K3S的介绍

轻量级Kubernetes发行版。易于安装，内存减半，所有二进制文件不到40mb。

适用于：

• 边缘计算-Edge
• 物联网-IoT
• CI
• ARM
• Situations where a PhD in k8s clusterology is infeasible

效果演示

容器时代，不掌学点基本功怎么行？
但是，咱也不是专业运维，所以光学过不行，会忘。得记一笔。
而且，由于一些不可描述的原因，只要是涉及到互联网肯定会有一些坑。

本文以MySQL8以及mysql-connector-java-8.0.18为例，但是其他本版或者其他数据应该也差不多。

在进行数据库开发的时候，和时间打交道就会涉及到时区，一个日期时间字段从应用层 → 数据库客户端 → 数据库服务端 传递过程中会跟以下几个时区打交道：

• JVM 时区(默认取操作系统时区，见后文)
• 数据库客户端设置的时区参数(serverTimezone)，数据库会话的时区
• 数据库服务端的时区(默认取操作系统时区，见后文)

要想在时区问题少踩坑(比如存在库里面的时间多了几个小时)可以这样做：

• 数据库服务端的时区参数time_zone设置一个明确的值，比如+8:00。这个不是必须的，但是建议设置。
• 数据库客户端通过serverTimezone参数设置自己的时区，这一步至关重要，它应该和java.util.TimeZone.getDefaultRef()的输出一致。