这年头灯光不都是开自动灯光嘛。。从来没有主动切换过远近

打游戏不是对小孩来说最好的方式吗，比起他去外面鬼混或者刷短视频

去海鲜市场找那种退坑的，200 应该能收到。

@dongzhuo777 139 后面+20 升到 159 原先 300M 升到 1000M ，流量加到 60

我的和你一样 139 不过我选了 IPTV 流量比你的少。之前也是有公网 ip ，移机以后没了。之前 V 站上还有老铁有内部办法开，今年五一以后都不行了 早知道当初就花点钱弄个永久的了

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 没做好。
能上微服务架构的业务体量，从业务复杂度和研发人员的数量来说肯定很大，如果用单体，别的不说 出现那种改一行代码打包编译几个小时的都有可能。

双职工家庭 又不想老带娃肯定是这样性价比这样最高啊。不然你老婆辞职当全职妈妈一个月下来家庭收入减少的更多