小五的个人杂货铺

安装nexus3 以下配置中的<nexus_host>都可以使用主机名.local（mDNS 域名）来代替 docker 123456789101112131415161718192021mkdir -p /usr/local/nexus3chown -R 200 /usr/local/nexus3docker run -d \--privileged=true \--name=nexus3 \-u root \-p 8081:8081 \# 这几个端口给docker私有仓库使用，故在需要使用 Docker 的机器上修改 `/etc/docker/daemon.json`：{"insecure-registries": ["你的服务器IP:8001", "你的服务器IP:8002", "你的服务器IP:8003"]}-p 8001:8001 \-p 8002:8002 \-p 8003:8003 \# 启动容器时加入时间挂载，使用宿主机时间-v /etc/loca...

项目初始化与依赖管理 (Go Modules)这是现代 Go 开发最常用的指令集。 指令 用途 备注 go mod init <name> 初始化一个新的 Go 模块 生成 go.mod 文件 go mod tidy 整理依赖 自动添加缺失的包，移除未引用的包（最常用，每次引入新库都会用） go mod download 下载依赖包到本地缓存 通常 tidy 会自动处理 go mod vendor 将依赖包缓存到项目下的 vendor 目录 某些企业内网环境需要 go mod graph 打印模块依赖图 用于排查复杂的版本冲突 go get <path>@v1.x 下载并添加特定版本的依赖 会更新 go.mod 编写、编译与运行这是代码循环（Code-Build-Run）的核心。 指令 用途 技巧 go run . 直接运行当前目录下的代码 适合临时调试，不会产生二进制文件（本地开发联调） go build 编译代码 默认生成与目录同名的可执行文件（最后容器化部署） go install 编译并将结...

基于(robfig_cron开发一个小工具)包: https://github.com/robfig/cron123go get github.com/robfig/cron/v3@v3.0.0import "github.com/robfig/cron/v3" util123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104package utilimport ( "github.com/pkg/errors" cron "github.com/robfig/cron/v3" "sync")// Crontab crontab managertype ...

背景 /var/opt/gitlab所在磁盘资源不足，现在希望将其无感迁移到**/data/opt/gitlab** 软链接方案停止 GitLab 服务1sudo gitlab-ctl stop 迁移数据到新盘目录12sudo mkdir -p /data/opt/gitlabsudo rsync -av --progress /var/opt/gitlab/ /data/opt/gitlab/ rsync 会保留文件权限和软链接，比 cp 安全。 rasync执行完后，使用diff指令确认下是否一致，如果不一致，则使用rsync继续进行迁移，直至无差异 备份原目录（以防回滚）1sudo mv /var/opt/gitlab /var/opt/gitlab.bak 建立软链接1sudo ln -s /data/opt/gitlab /var/opt/gitlab 权限检查1sudo chown -R git:git /data/opt/gitlab GitLab 默认用户是 git，如果你有改过...

首先，Optional是一个容器，用于放置可能为空的值，它可以合理而优雅的处理null。 不合适的使用方式 直接使用 isPresent() 进行 if 检查 -- isPresent()一般用于流处理的结尾，用于判断是否符合条件。 在方法参数中使用 Optional public void getUser(long uid, Optional<> userType); -- X 直接使用 Optional.get -- 和不做任何空判断一样，十分危险 使用在 POJO 中 -- 给序列化带来麻烦 记录一些API12345678910111213141516171819202122232425262728291. empty()返回一个Optional容器对象，而不是 null。建议常用⭐⭐⭐⭐2. of(T value)创建一个Optional对象，如果 value 是 null，则抛出 NPE。不建议用⭐⭐3. ofNullable(T value)同上，创建一个Optional对象，但 value 为空时返回Optional.empty()...

问题记录 最后的结果Flux、Mono一定要作为方法返回值，因为响应式编程的异常信息保存在这些结果中（而不是在方法调用时抛出），所以这些结果必须作为方法返回值，否则Spring无法知道方法是否报错 常用api记录 如果要操作数据,并返回一个Mono的时候,使用flatMap 一般如果不操作数据,仅数据转换,使用map 订阅者是由Spring框架去完成,我们(开发)写发布者代码 zipWith方法可以组合两个Mono/Flux，并返回新的Mono/Flux类型 take(x)适合取flux中前x个,而当flux就一个元素的适合,可以使用next()将flux转为mono flatMapMany适合将Mono<数组/集合>转换为Flux 当希望合并多个流操作的时候,可以使用Mono.zip/Flux.zip Mono.zip(memberLevelMono, giftCardMono, couponMono).map... zipWith方法会同时请求待合并的两个Mono数据，而zipWhen方法则会阻塞...

webmvc和webflux的一些区别组件 执行过程webmvc webflux 写法(返回一个视图)webmvc webflux(路由式写法),webflux也支持了mvc的注解使得一般项目可以无压力替换为webflux框架 思想webmvc(命令式编程)1假如有一个式子a=b+c，这就意味着a的值是由b和c计算出来的。如果b或者c后续有变化，不会影响到a的值 webflux(响应式编程)123式子a:=b+c，这就意味着a的值是由b和c计算出来的。但如果b或者c的值后续有变化，会影响到a的值--变化传递 例子(3y) 1234567private String createStr() { try { TimeUnit.SECONDS.sleep(5); } catch (InterruptedException e) { } return "some string";} webmvc123456private String get1() &...

通过打开全局 Operator 堆栈追踪 未开启之前 开启之后 这种方法同等与在方法内部输出以下代码1234//打开Hooks.onOperatorDebug();//关闭Hooks.resetOnOperatorDebug();

在使用mvc编程方式下,全局异常拦截可使用如下方式123456789101112131415/** * @author 小五 */@Slf4j@RestControllerAdvice@RequiredArgsConstructorpublic class DefaultExceptionHandlerConfig { @ExceptionHandler(BeHappyException.class) //@ResponseStatus(HttpStatus.INTERNAL_SERVER_ERROR) public ResponseEntity beHappyExceptionHandler(BeHappyException e){ log.error("BeHappy Exception: {}",e.getMsg()); return ResponseEntity.internalServerError().body(e); }} 在使用路由...

gRPC协议在K8S环境下的负载问题参考： https://www.lixueduan.com/posts/grpc/13-loadbalance-on-k8s/ https://www.cyub.vip/2021/11/09/k8s%E7%8E%AF%E5%A2%83%E4%B8%8B%E9%83%A8%E7%BD%B2grpc%E7%9A%84%E5%87%A0%E7%A7%8D%E6%96%B9%E6%A1%88/ 概述系统中多个服务间的调用用的是 gRPC 进行通信，最初没考虑到负载均衡的问题，因为用的是 Kubernetes，想的是直接用 K8s 的 Service 不就可以实现负载均衡吗。 但是真正测试的时候才发现，所有流量都进入到了某一个 Pod，这时才意识到负载均衡可能出现了问题。 因为 gRPC 是基于 HTTP/2 之上的，而 HTTP/2 被设计为一个长期存在的 TCP 连接，所有请求都通过该连接进行多路复用。 这样虽然减少了管理连接的开销，但是在负载均衡上又引出了新的问题。 由于我们无法在连接层面进行均衡，为了做 gRPC 负载...