港真，小团队、小项目上微服务，就像一个小婴儿非要穿他中年发福的老爹的衣服鞋帽。。
彼之饴糖吾之砒霜。。。
微服务出现的背景好像是网飞吧？人家当时都什么体量了。。

从架构和运维的角度来说，微服务的副作用已经很好地消减了，
istio等成熟的mesh技术大幅消减了运维复杂度。

但是，业务层面，服务的拆分解耦并不会因为运维技术的改进而改进，
这个难题，DDD可以一定程度上起到方法论的作用，但是DDD并不适合初创项目和团队。

还有管理和人力成本这个因素，小团队根本就玩不起微服务，这个好像没什么可谈的了。
小baby穿他爹的行头，除了像个小丑，难免还要摔跟头。。

【 在 changtuiniu 的大作中提到: 】
: 一个项目动不动几十个进程，客户方服务器受不了，明确要求进程数不能超过一定数量，要求我们合并服务
: - 来自 水木社区APP v3.4.2
--
FROM 124.202.17.*

规模小的时候，就前后端分离，一个系统两个部署单元
后端再驾个网关，各服务之间直接http调用就好了
做大了再重构

【 在 i00i (烟灰·独孤求胖) 的大作中提到: 】
: 港真，小团队、小项目上微服务，就像一个小婴儿非要穿他中年发福的老爹的衣服鞋帽。。
: 彼之饴糖吾之砒霜。。。
: 微服务出现的背景好像是网飞吧？人家当时都什么体量了。。
: ...................
--
FROM 223.166.140.*

限制单个应用的 CPU 上限，也不是很重要的需求吧？

而且 linux 有 CPU 亲和性的设置

有这种需求的时候再上 docker 或者 k8s 不迟。

【 在 guestking (无) 的大作中提到: 】
: java -jar的话，一般如果去限制单个应用的cpu上限？
--
FROM 110.81.42.*

拆微服务确实是个有技术含量的内容

但是————

这东西只不过是系统发展到一定程度拆解复杂系统而已，所以也没啥高大上的
跟拆函数、拆类、分层架构没啥本质区别，只是原来你在系统里边拆，现在系统规模大到了一定程序，现在要往分布式去拆，把一个功能拆到不同的节点共同运行。如果原来是平面的，现在一下子变成立体的了，进入了一个新的维度。在springCloud解决了服务注册、配置中心这些之后，体量够大的项目组可以通过微服务解决启动时间慢、系统规模太大无法更新、每次更新影响范围不确定、新技术无法引入等问题，对人家有无数好处，当然会使用了。


但是————
如果没有这方面的需要，解决不了底层的通用的技术，非要硬上微服务，会花费大量时间处理复杂度，对项目只有害处而体会不到好处



【 在 i00i (烟灰·独孤求胖) 的大作中提到: 】
: 标  题: Re: 微服务带来了新的问题
: 发信站: 水木社区 (Wed Jul 28 15:34:27 2021), 站内
:
: 港真，小团队、小项目上微服务，就像一个小婴儿非要穿他中年发福的老爹的衣服鞋帽。。
: 彼之饴糖吾之砒霜。。。
: 微服务出现的背景好像是网飞吧？人家当时都什么体量了。。
:
: 从架构和运维的角度来说，微服务的副作用已经很好地消减了，
: istio等成熟的mesh技术大幅消减了运维复杂度。
:
: 但是，业务层面，服务的拆分解耦并不会因为运维技术的改进而改进，
: 这个难题，DDD可以一定程度上起到方法论的作用，但是DDD并不适合初创项目和团队。
:
: 还有管理和人力成本这个因素，小团队根本就玩不起微服务，这个好像没什么可谈的了。
: 小baby穿他爹的行头，除了像个小丑，难免还要摔跟头。。
:
: 【 在 changtuiniu 的大作中提到: 】
: : 一个项目动不动几十个进程，客户方服务器受不了，明确要求进程数不能超过一定数量，要求我们合并服务
: : - 来自 水木社区APP v3.4.2
:
: --
:
: ※ 来源:·水木社区 http://www.mysmth.net·[FROM: 124.202.17.*]
--
FROM 223.104.38.*

svn的子文件夹？  
  
【 在 sixue1999 (宋似雪) 的大作中提到: 】
:  还有比git子模块更难用的开发模式吗
:  【 在 hgoldfish (老鱼) 的大作中提到: 】
:  : 我觉得它的大多数好处都可以用 git 子仓库加上 gradle 脚本获得。  
:  : git 子仓库完全可以代替 jar 包的功能，而且还能随时修改代码，通过测试后自动发布到整个公司所有的项目里面。  
--
FROM 223.104.38.*