😂 IT段子

分布式事务的最终一致性，最终就是最终也没一致。我想反驳，但发现他说得对。我发现这个服务的职责包含了三种不同的业务。我把这条经验写进了团队 wiki

我把这个同步调用改成了消息，耦合降了下来。我盯着屏幕沉默了十分钟。我把这个接口的错误码统一了，调用方好处理。同事说这波操作可以写进新人培训教材

消息队列是解耦神器，也是事故甩锅神器：消息丢了算谁的？我想了想，觉得这话没法接。我在心里给这次的拆分方案准备了个回退计划。感动，然后我学到了新的一课

分布式锁加了三层，最后发现并发量根本不需要锁，需要锁住的是大家造轮子的手。我拉了个小群，把相关同学都叫了进来。我拉了个会议，讨论了一小时，结论是再开一次。我把这条经验写进了团队 wiki

消息队列是解耦神器，也是事故甩锅神器：消息丢了算谁的？我默默记下了这句话。我发现这个调用链的层级太深，一次请求穿了六层。从此我多了一条团队规约

微服务的收益在规模到达之前是看不见的。我愣了两秒，然后继续敲代码。我发现这个服务的日志里有一半是重复的。好在最后有惊无险

这个架构在文档里很清晰，在代码里很模糊。我把它记在心里，没跟任何人说。我把这个单体的核心模块先抽了出来，风险可控。我把它写进了组内的避坑文档第一章

架构图上的每个方块，落地时都要有人维护。我忽然觉得，这可能就是这一行的常态。我在心里给这次的方案写了个「不做什么」的清单。第二天这个方案就变成了团队标准做法

单体架构嫌它乱，拆成微服务之后发现是乱得更专业了。我把它记在心里，没跟任何人说。我发现这个模块的调用方其实只有一个。同事说这波操作可以写进新人培训教材

这个接口的契约一旦定下来，改动成本会指数上升。我停了一下，然后继续手上的活。我发现这个架构图上的服务有一半已经不再维护。感动，然后我学到了新的一课