litchinn

litchinn

V2EX 第 459059 号会员,加入于 2019-12-13 14:55:45 +08:00
nginx 反向代理 504 的问题
NGINX  •  litchinn  •  154 天前  •  最后回复来自 julyclyde
9
一个密码存储格式的问题
Java  •  litchinn  •  234 天前  •  最后回复来自 litchinn
7
求助类似 Node-RED 的画布拖拽组件的工具
程序员  •  litchinn  •  2022-05-07 19:37:06 PM  •  最后回复来自 taowen
5
不知道大家有没有过很焦虑的时期?
程序员  •  litchinn  •  2021-12-19 22:43:26 PM  •  最后回复来自 litor
62
看到个好玩的, habitica
分享发现  •  litchinn  •  2021-12-02 11:04:25 AM  •  最后回复来自 AnnaXia
3
一个关于访问 k8s 内部服务的问题
Kubernetes  •  litchinn  •  2021-12-01 09:24:28 AM  •  最后回复来自 gollwang
7
关于 nginx 配置 http2 的 server push 的疑问
HTTP  •  litchinn  •  2021-02-26 14:43:57 PM
litchinn 最近回复了
5 天前
回复了 xzour 创建的主题 程序员 内部系统如何优雅的管理各种第三方接口
事件驱动+路由,但是不清楚你的不顺畅点在于调用还是太多了导致混乱,如果是调用的话感觉没啥办法,调用第三方始终存在着一些网络,服务可用性等因素的影响

1. vue 项目是可以直接打包进 springboot 包里的,这样直接启动 springboot 就能访问页面,就和前后端不分离是一样的。再配合 graalvm native image 打包成原生镜像可以直接启动。
但是你项目引入的第三方包 graalvm native image 打包也许会有坑,也可以选择 exe4j 等工具打包 exe 直接启动。
2. 不用 java ,纯 js 应该也可以串口通讯。直接 electron 打包。这个我了解不多
本来是推自己的 mapstructplus 的,变成讨论 mapstruct 的了,哈哈
mapstruct 本身是通过编译期生成 getset 方法来实现转换的,就和 lombok 生成 getset 方法一样,因此这两者同时使用还需要额外配置
因为是 getset ,所以 mapstruct 的性能要优于 BeanUtils.copyProperties ,通常认为偶尔使用且数据量小的情况可以直接使用 BeanUtils.copyProperties ,否则使用 mapstruct 或者自己写 getset 比较好
关于深度拷贝,mapstruct 是支持的,也是需要额外的配置,不复杂
mapstruct 还提供 SPI

回到楼主这,楼主说 plus 对 mapstruct 做了增强,也就是连本来需要自己写的 Mapper 也通过 mapstruct-plus-processor 生成了。感觉楼主介绍的时候得强调下你做了哪些增强,本来是啥样,之后是啥样,例如楼上问到的深拷贝等,在你这里应该如何使用。

最后想问下,这个 @AutoMapper 支持多个 target 吗,如果我 User 想转成多种 UserVO 要怎么使用呢?
现在我写 sql 和分析 sql 的活都交给 gpt 了,感觉能省不少头发
91 天前
回复了 dyv9 创建的主题 程序员 请教商品价格排序的性能问题
从业务入手,看能不能提前制定折扣计划,比如 1 号之前配置 1-3 号的折扣,这样有充足的时间去计算折后价。
如果非要实时调整,那除了变动后计算,通过分组并发建结果表等常规方式计算没啥办法,你肯定不能每次查询再去计算的
94 天前
回复了 vfx666 创建的主题 问与答 真有人花钱买 ssl 证书?
有免费的支持 *.xx.com 的证书吗,有的话告诉我一下
114 天前
回复了 gsy20050126 创建的主题 程序员 何时才能逃离写 bug 怪圈
写 bug 才是常态,你要做的是发现问题,定位问题,解决问题,发现问题靠测试,定位问题靠调试,解决问题靠尝试,这其实适用于大多数工程行业
1. mapstruct 转换,如果请求量大到影响业务,应该专门优化,一般来说这是少数接口
2. 分批次
3. 我这是拿到数据后再合并,具体方案得看业务
存储选什么呢,万一碰上一次停电直接头皮发麻
看了你上面说的这些,你用 k8s 的唯一原因是觉得它部署方便
1. 我并不觉得 k8s 部署方便,写个 helm chart 的时间肯定比写个脚本多(除非你更擅长写 chart 而不是 shell 脚本),只能说他看起来更规范
2. k8s 显然比直接部署更占用资源,它的优势在于自动扩缩容,但是你说你想固定节点且单节点。限制服务器资源 docker 一样可以
3. 管理集中或许这个算一点小优势,你用 k8s 会很自觉的把 yaml 或 chart 文件搞个仓库放好,并且有统一的入口去查看日志之类的,但是写个脚本也是一样的,易于维护则不一定,出现问题,你还要额外考虑 k8s 上的问题,而且出问题的概率比这些基础应用本身要大

综上对于你目前的情况而言你列出的优点都不算优点或者优势不明显
我是说 datart 的 logo 和我之前看 davinci 的怎么这么像,原来真的是“续作”
https://github.com/edp963/davinci/issues/2297#issuecomment-1118674817
关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   我们的愿景   ·   实用小工具   ·   2815 人在线   最高记录 6543   ·     Select Language
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.5 · 22ms · UTC 13:25 · PVG 21:25 · LAX 06:25 · JFK 09:25
Developed with CodeLauncher
♥ Do have faith in what you're doing.