@citydog #8 要个屁，只要 bing.cn 的网站内容不蹭必应搜索，那么微软只能花钱买，官司不是谁公司大谁就能赢。

@petelin #35 果真是找 block

@lihua 得了吧，微软中国跟微软是俩公司，加上必应在微软的整体战略中比重不高，所以在国内 SEO 高手的环视下，墙内必应就是个卵蛋。墙内必应哪怕有一点用，微软也不会用百度当 Edge 的默认搜索引擎。墙内搜索，主力还得是墙外的谷歌，必应、搜狗，或者以前都没听过名字的，可以辅助。

你搞错了，12 月 15 日只是导火索，不是原因。

非事业单位，婚礼当天请同事，怎么想怎么傻。婚礼后的独立酒局，请同时=收份子钱。

@lcdxiangzi #39 请举出事实。

再纠正你一点错误：CAP 是分布式系统的理论，当你讨论到 CAP 的时候，已经是分布式系统了。下面摘自维基百科：

在理论计算机科学中，CAP 定理（ CAP theorem ），又被称作布鲁尔定理（ Brewer's theorem ），它指出对于一个分布式计算系统来说，不可能同时满足以下三点：[1][2]

一致性（ Consistency ） （等同于所有节点访问同一份最新的数据副本）
可用性（ Availability ）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）
分区容错性（ Partition tolerance ）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在 C 和 A 之间做出选择[3]。）

根据定理，分布式系统只能满足三项中的两项而不可能满足全部三项[4]。理解 CAP 理论的最简单方式是想象两个节点分处分区两侧。允许至少一个节点更新状态会导致数据不一致，即丧失了 C 性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了 A 性质。除非两个节点可以互相通信，才能既保证 C 又保证 A，这又会导致丧失 P 性质。

@petelin #18 你自己发的贴子，那么多回复你压根没看是吧。月 3 万年终 12 万的之前、以后、三年内使用年终优惠的，老子都给你算出来了，你还在这里说疯话。

@lcdxiangzi #33 给你说个最简单的例子，从 A 银行转账到 B 银行，你准备做一个怎样的“单体”系统能让 A 银行和 B 银行都接受。
事务性这个就更扯淡了，就一个最简单的行内取钱操作，就涉及到个人账户、支行账户、总行账户等多方面的数据，想要原子提交，你准备让用户等多久。

@lcdxiangzi 这应该跟 P2P 无关，金融行业都一样。金融行业对高可靠性和低延迟性的要求都很高，就像前几天 PDD 那种情况，在金融行业要是出现了，不跑路就得进去。金融行业的应用，常规 CRUD 架构再怎么改都是撑不起来的，读写分离、事件源这种架构都要上，它们天生就是分布式架构，所以搞成微服务一点难度都没有。

难道在代码的权威性上，以及有可能出现的哪种语言的代码更牛逼上，讨论不比现在更激烈？

要想真正的关掉，是需要在服务器保留每个用户的配置、并且在广告推送里面应用配置的。因为广告量太大，这在开发和服务器损耗上都是不小的成本。直接在手机端隐藏，简单多了，只接受不显示的推送，消耗的电量可以忽略不计的，而且屠夫照顾肥羊，意思一下就行了，照顾太好不是 S13 吗。

当然还有另一种可能，只在手机端隐藏的话，那么不管手机怎么设置，广告的发送量是不变的。在中国这种靠量不靠质的广告体系下，也就意味着手机怎么设置，都不影响 ADUI 的广告收入。

“谁改的功能啊，我真想抽他，敲回车可以，点查询按钮不行”，改东西改一半，谁遇见了都炸毛，不管是后端还是什么。然而公司也确实不行：两个后端貌似都是主管；你的领导被顶嘴后直接换人处理（这是大忌）

工作失误，最多开除，或者让员工分期赔偿，坐牢是不可能的，当然若不是失误而是主观，那就另说了。
大部分情况下不但不要赔偿，甚至会送上特别安慰，因为导致开发团队集体离心的风险太大了。但要是开发团队只是牛马，那就另说了。

Java 有一个很有意思的名词，企业级应用，以前的 Java EE，现在的 Jakarta EE。如果只是打算做个网站或者业务只有 CRUD，那么用微服务确实自讨苦吃。基本上，主程人数在 10 人以下，或者技术团队 50 人以下，微服务学习一下就行了，别真用。