- 主题:微服务带来了新的问题
拆的太散的确是不好
【 在 changtuiniu (此id已换人) 的大作中提到: 】
: 一个项目动不动几十个进程,客户方服务器受不了,明确要求进程数不能超过一定数量,要求我们合并服务
: - 来自 水木社区APP v3.4.2
--
FROM 180.167.95.*
其实微服务和git关系不大
我的观点是,微服务,或者说是docker,最大的作用是改变了交付方式
现在越来越少听到诸如“在我这里是好的啊”这类的话了
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 微服务是为了解决什么问题呢?
: 1. 首先是复用代码和业务。类似于 jar 包,但是又比 jar 包更独立
: 同样的 git 子仓库,也是实现复用的一种办法。确实不包含运维规则,但是很方便参与修改代码。
: ...................
--
FROM 180.167.95.*
git不是为了复用啊
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 核心都是复用。为什么说关系不大?
--
FROM 180.167.95.*
微服务大家都可以需要,和语言关系不大,主要是和领域模型有关
java最不需要docker,这点倒是部分同意
现在普遍使用docker的情况下,java原先run anywhere的意义就没那么大了
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 核心都是复用。为什么说关系不大?
: 运维方面,解决方案也有很多。docker 也只是一种方式。其实 java 社区是最不应该用微服务的。要用也是 python 社区用才对。
--
FROM 180.167.95.*
这个没怎么用过
好奇问一下,和我直接dependency其他jar,有什么优势吗
【 在 hgoldfish (老鱼) 的大作中提到: 】
: git 子仓库就能复用啊。
--
FROM 180.167.95.*
我理解的微服务最重要的是要做好领域拆分
相当于是在业务维度做高内聚低耦合
拆的好,那各个服务之间的职责清晰,功能明确,扩展起来也方面
拆的不好,你要改个功能,都不知道要去什么地方改
【 在 sixue1999 (宋似雪) 的大作中提到: 】
: 因为不是复用
: 我觉得微服务主要的作用在于用一种物理限制(比如http协议)
: 来规范模块之间的接口
: ...................
--
FROM 180.167.95.*
是的,所以我说这是业务层面的高内聚低耦合
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 那你说的这件事情,跟拆 jar 包是不是一样的呢?我们以前拆 jar 包的时候也要做到职责清晰,功能明确,扩展方便啊。
: 甚至拆类的时候,我们都得考虑这个问题。
--
FROM 180.167.95.*
这些对你代码复用也没什么用啊
【 在 hgoldfish (老鱼) 的大作中提到: 】
: jar 里面只有 .class 文件和 manifest.
: 而 git 子仓库,里面有各种运维脚本,gradle 脚本,里面包含 k8s pod 描述也是可以的,很灵活。
--
FROM 180.167.95.*
我倒是很奇怪这个客户,都一千万的标了,还用得着省这点服务器的钱吗
【 在 sayinger (言者) 的大作中提到: 】
: 所以这种项目完全没有微服务的必要,客户的要求蛮合理的,开发运维资源节省下来多做几个功能他不香吗
--
FROM 180.167.95.*
和微服务关系不大
看上去比直接依赖jar包麻烦
还得自己编译
【 在 PaoloMaldini (solo con te) 的大作中提到: 】
: 那不是比微服务麻烦多了
--
FROM 180.167.95.*