- 主题:微服务带来了新的问题
这个规模的集成测试本来就不应该在开发机上单机跑啊……
当年我们拆模块（我怵微服务这个词）一大动机就是单体war启动一次几百秒
开发测试进度无比拖沓
开发机配合mock单测接口就好
【 在 rimer (胖拖拖) 的大作中提到: 】
: 没错，前两天我们组刚合并了一堆服务，主要原因是集成测试已经在开发机上没法跑了，单启动所有服务和数据库就需要24G+的内存。
--
修改:oldwatch FROM 116.233.186.*
FROM 116.233.186.*
那下一个问题就是当初为啥会拆那么多出来？
真就完全不在乎远程调用开销么？
【 在 rimer (胖拖拖) 的大作中提到: 】
: 规模没那么大，合并之后内存用量减了10G不止。而且我们这里没有专用的开发环境...
--
FROM 116.233.186.*
其实我一直觉得微服务的重点应该是你说的那堆”其他“
前面其实就是传统的模块化/分布式
【 在 Mikov (Mikov Chain) 的大作中提到: 】
: 新技术都是为了解决一些旧方案无法解决的问题, "微服务"这个词有点被滥用了.
: 问题就是两点: 1)它解决了什么问题 2)怎样算合理使用
: 对于1), 我自己的感受是
: ...................
--
修改:oldwatch FROM 116.233.186.*
FROM 116.233.186.*
docker有一个很大的优势，单服务管理方便且一致
哪怕一堆实例弄个Portainer或者rancher之类的鼠标点点就好
至少测试环境非常方便
【 在 i00i (烟灰·独孤求胖) 的大作中提到: 】
: +1
: 关于docker，spring boot的天下，java -jar就完事了。。
: 再套一层docker已有叠床架屋之感，服务器上装个jre又不会死。。
: ...................
--
FROM 116.233.186.*
经典java war项目，生产环境上docker优势其实不明显
但是测试环境里docker优势真的大
【 在 i00i (烟灰·独孤求胖) 的大作中提到: 】
: 嗯嗯，我主要就用portainer + docker compose。。
: 满足大多数部署场景了，“一堆”实例主要受益于docker compose。
: 对于springboot来说，有docker确实比没有要方便一点点，这点我是认同的。
: ...................
--
FROM 116.233.186.*