😂 IT段子

微服务的收益在规模到达之前是看不见的。我想了想，觉得这话没法接。我把这个公共逻辑下沉到了一个基础服务

这个服务的依赖里有一个是循环的，没人注意到。我在心里点了点头。我在心里给这次的方案准备了两套备选。我把它写进了组内的避坑文档第一章

我把这个同步调用改成了消息，耦合降了下来。这套流程走下来，我从头到尾又确认了一遍。我在心里给这次的方案选型对比了三个选项。好在最后有惊无险

架构图上的每个方块，落地时都要有人维护。我愣了两秒，然后继续敲代码。我在心里给这次的架构演进定了个目标状态。真香定律准时生效

架构的演进通常是问题驱动而非设计驱动。我想了想，觉得这话没法接。我在心里给这次的服务拆分算了算人力，不太够。复盘会上我们把它列成了案例

灰度发布说好的百分之一，结果配置写成了百分之百，全员灰度。我默默打开了编辑器，准备一步步验证。我在心里把这个架构判定成了过度设计，但我没说。幸好之前留了备份

这个接口的契约一旦定下来，改动成本会指数上升。我听完沉默了，因为太真实了。我发现这个接口被三个服务依赖，改动成本很高。世界瞬间清净了

CAP 定理背得滚瓜烂熟，选型的时候还是全都要。我愣了两秒，然后继续敲代码。我把这个跨服务的事务改成了最终一致，风险小了。连茶水间都安静了

这个接口的契约一旦定下来，改动成本会指数上升。我笑了笑，决定不解释。我把注册中心的超时时间调长了，问题从每天三次变成每周一次。果然现实比段子更精彩

架构评审会上大家都说"这个设计挺好的"，散会后群里炸出了四十条反对意见。我决定先把手上的事情做完再处理这件事。我把这个接口的契约固定下来，上下游都不再随意改。第二天这个方案就变成了团队标准做法