- 主题:微服务带来了新的问题
微服务大家都可以需要，和语言关系不大，主要是和领域模型有关
java最不需要docker，这点倒是部分同意
现在普遍使用docker的情况下，java原先run anywhere的意义就没那么大了
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 核心都是复用。为什么说关系不大？
: 运维方面，解决方案也有很多。docker 也只是一种方式。其实 java 社区是最不应该用微服务的。要用也是 python 社区用才对。
--
FROM 180.167.95.*
因为不是复用
我觉得微服务主要的作用在于用一种物理限制（比如http协议）
来规范模块之间的接口
强迫程序员必须用规范的，可描述的，明确的接口沟通
不给人留下模棱两可和约定俗成的空间
也不给你挖门盗洞的机会
至于模块是否真的被复用了，不一定
即使只有一个模块调用了，也可以用微服务
【 在 hgoldfish (老鱼) 的大作中提到: 】
: 核心都是复用。为什么说关系不大？
--
FROM 43.243.12.*
这个没怎么用过
好奇问一下，和我直接dependency其他jar，有什么优势吗
【 在 hgoldfish (老鱼) 的大作中提到: 】
: git 子仓库就能复用啊。
--
FROM 180.167.95.*
我理解的微服务最重要的是要做好领域拆分
相当于是在业务维度做高内聚低耦合
拆的好，那各个服务之间的职责清晰，功能明确，扩展起来也方面
拆的不好，你要改个功能，都不知道要去什么地方改
【 在 sixue1999 (宋似雪) 的大作中提到: 】
: 因为不是复用
: 我觉得微服务主要的作用在于用一种物理限制（比如http协议）
: 来规范模块之间的接口
: ...................
--
FROM 180.167.95.*
外包项目瞎用啥微服务，业务复杂到那个程度了吗，团队大到那个程度了吗，真要到了那个程度，还不自己建团队来搞，那纯属把自己的饭碗放别人头顶。
【 在 changtuiniu (此id已换人) 的大作中提到: 】
: 一个项目动不动几十个进程，客户方服务器受不了，明确要求进程数不能超过一定数量，要求我们合并服务
: - 来自 水木社区APP v3.4.2
--
FROM 221.220.225.*
docker又不会减少你的进程数量，反而会增加
【 在 licy (上网不便, msg收不到) 的大作中提到: 】
: docker啊
--
FROM 221.220.225.*
很多公司的业务没有大到需要用微服务的地步。
还有公司的业务也不容易拆解成微服务。
这些公司如果是为了微服务而微服务，那估计下场就很惨了。。
【 在 guestking (无) 的大作中提到: 】
: 我理解的微服务最重要的是要做好领域拆分
: 相当于是在业务维度做高内聚低耦合
: 拆的好，那各个服务之间的职责清晰，功能明确，扩展起来也方面
: ...................
--
FROM 223.104.96.*
怎么不是复用啊。。微服务当然能让交付更方便，但那是 docker 的功劳，不是微服务的本质特征。
一个完整的项目拆成多个微服务，就算 docker 再方便，仍然是稍微不方便布署的吧。k8s 的 yaml 都写好几份呢。唯一能解释的就是微服务同时也具备 jar 包的功能，用于复用代码——这个项目用的，下个项目可以继续用。
说到复用，jar 也可以做到。无非是微服务的复用故意多加了 http 的限制，从随意的复用变成了不随意的复用。
说是不随意，其实还是随意得很。确实都是 http restful，但 json 里面的内容乱七八糟。于是很多人就改成了 grpc，然而这不是跟直接函数调用差不多了。又开始乱七八糟起来了。
【 在 sixue1999 (宋似雪) 的大作中提到: 】
: 因为不是复用
: 我觉得微服务主要的作用在于用一种物理限制（比如http协议）
: 来规范模块之间的接口
: ...................
--
FROM 110.81.42.*
微服务和docker完全两个方向，正交的
docker可以说我扔一个给你就完，微服务怎么可能呢，一堆依赖在那里呢，微服务往极端了说，其实是交付给自己，如果还是烟囱模型，指望扔一个image给运维，开发就下班撸串去了，十有八九都是做梦。
【 在 guestking (无) 的大作中提到: 】
: 其实微服务和git关系不大
: 我的观点是，微服务，或者说是docker，最大的作用是改变了交付方式
: 现在越来越少听到诸如“在我这里是好的啊”这类的话了
: ...................
--
FROM 221.220.225.*
那你说的这件事情，跟拆 jar 包是不是一样的呢？我们以前拆 jar 包的时候也要做到职责清晰，功能明确，扩展方便啊。
甚至拆类的时候，我们都得考虑这个问题。
【 在 guestking (无) 的大作中提到: 】
: 我理解的微服务最重要的是要做好领域拆分
: 相当于是在业务维度做高内聚低耦合
: 拆的好，那各个服务之间的职责清晰，功能明确，扩展起来也方面
: ...................
--
FROM 110.81.42.*