而且jvm的docker 随便就好几百兆

【 在 guestking 的大作中提到: 】
微服务大家都可以需要，和语言关系不大，主要是和领域模型有关
java最不需要docker，这点倒是部分同意
现在普遍使用
--
FROM 106.47.41.*

如果是这样的话，拆成微服务就很好

【 在 rimer (胖拖拖) 的大作中提到: 】
: 呵呵，这个还真不担心，因为根本没有服务间互相调用的情况，调用链很短：客户端->服务->数据库。每个服务功能单一，可以单独更新吧。这次合并也只是针对测试这一块，生产环境还是多进程，毕竟线上内存不是大问题，未来因为要上k8s有进程数限制这个变化也有用。
--
FROM 180.167.95.*

我们目前是的。实际上不使用密码，配置到只验证 IP 段。

不过改动一下也太容易了，编译脚本里面让布署的人输入一下密码就行了。这种方案的布署都是由脚本控制的，提供的能力并不会比 k8s 图灵不完备的描述文件差。只是有些事情麻烦，有些事情方便，各有优劣。

并不是鼓吹 k8s 没用，说的是对于中小项目，应该寻求 k8s 之外的方案。

【 在 RuralHunter (渔父) 的大作中提到: 】
: 密码什么都放里面？
--
FROM 112.47.122.*

如果只是密码的话，那根本不需要k8s
启动命令里面加参数就好了
或者搞个配置中心，简单点zk之类的就行了

【 在 hgoldfish (老鱼) 的大作中提到: 】
: 我们目前是的。实际上不使用密码，配置到只验证 IP 段。
: 不过改动一下也太容易了，编译脚本里面让布署的人输入一下密码就行了。这种方案的布署都是由脚本控制的，提供的能力并不会比 k8s 图灵不完备的描述文件差。只是有些事情麻烦，有些事情方便，各有优劣。
: 并不是鼓吹 k8s 没用，说的是对于中小项目，应该寻求 k8s 之外的方案。
: ...................
--
FROM 180.167.95.*

+1
DDD

【 在 guestking 的大作中提到: 】
: 我理解的微服务最重要的是要做好领域拆分
: 相当于是在业务维度做高内聚低耦合
: 拆的好，那各个服务之间的职责清晰，功能明确，扩展起来也方面
: ...................
--
FROM 124.202.17.*