dongzhuo777

18 公里。开车上班不是更合适吗。。。。。。

看起来好像游戏里面的背包整理。就是有空格的自动合并然后能塞满。。好像很多游戏里面的都有这个功能。
这种肯定有成熟的算法，问 gpt 吧。

@adgad2 但是需要上微服务的项目复杂度本身就很高，有些项目系统都有几十个 要做集成不用微服务用单体 压根打包都做不到

@sujin190 我司这也这样乱过一阵子，后面复盘出现的很大一部分原因是 组织架构的调整，微服务的架构设计如果只是根据业务来划分，没有按照公司实际的物理组织架构去划分 后期一定会出现这种灾难的。

@DOLLOR 有一个最大的天坑，
Double x = null;
List<Double> list = new ArrayList<>();
.....
list.add(x);
....
然后 后面操作 list 的适合就 GG 了。我可以打包票 90%的人写代码都不会去校验这个 null

java 的 array 也是可以塞任意对象的啊，只不过加上泛型在编译校验了，底层还是可以随便你塞什么的。。
这种就是语言灵活性，有些语言是适合自己写不适合大规模团队协作的。
比如 C/C++的指针满天飞，换个人来都不知道在干嘛

推特谷歌那种是大公司钱多了没地方花，专门招人来当人才储备，或者抢竞争对手的人才。之前老美利息低，资金来源便宜，钱多了没地方花，就雇人每天在那上课培训。前段时间加息，资金贵了 裁的就是这批储备用的人员 当然对业务没多大影响。国内下一次扩展应该是要等经济周期回来才有机会了

@ilvsxk 日志的问题我不认同，你换成单体难道就好了吗，微服务换成单体。那拆分的服务单体里面肯定是一个独立的模块，否则那就是这个微服务的拆分不合理，甚至这个模块是独立的团队去维护，对于调用方来说就是一个黑盒。
假如是单体线上出问题没日志，那单体 排查起来一样抓瞎。和微服务没关系。
要是十人以内的研发团队可以搞定的业务量那微服务的拆分确实没意义。但事实上上微服务的都是几百号研发团队的情况

个人对微服务比较恶心的点是：
1.后期规模起来的服务之间的循环调用 A→B→C→D→A 。
2.API 会存在大量冗余重复的不好管理，针对老接口改动不知道调用方有多少，为了不影响，所幸新加一个 V2 的接口 重新实现一套逻辑。以此后面可能有样学样就有 v3 v4 v5 版本。
3.大量的 DTO 的内部转换，大量一模一样的 javaBean 加个字段可能要改十几个类
4.比正常单体吃内存，毕竟部署多了 重复的 bean 、框架的开销。

需要上微服务的业务系统，那业务范围肯定是光到没边的。这种如果某个员工能把上下游所有业务链路吃透的，早就可以转型业务顾问了。
而且就你描述的问题有一个包没升级这种低级问题，就是本质上是版本管理和发布的问题，和微服务有毛关系，devops 没做好。
能上微服务架构的业务体量，从业务复杂度和研发人员的数量来说肯定很大，如果用单体，别的不说 出现那种改一行代码打包编译几个小时的都有可能。