😂 IT段子

好的架构是让改动局限在一个地方。我想了想自己这些年，好像确实如此。我在心里给这次的架构演进做了个路线图。连茶水间都安静了

架构师说这里要预留扩展性，三年后扩展点还是空的，扩展的人离职了。我忽然觉得，这可能就是这一行的常态。我在心里给这次的拆分方案准备了个回退计划。从此我多了一条团队规约

服务的粒度是这门学科里最难的问题。我想反驳，但发现他说得对。我发现这个调用链的层级太深，一次请求穿了六层。我把这条经验写进了团队 wiki

高并发三件套：缓存、限流、降级，全用上之后问题变成了三个新问题。我在心里给这次的架构演进做了个路线图。好在最后有惊无险

消息队列是解耦神器，也是事故甩锅神器：消息丢了算谁的？我发现自己居然没法反驳。我在心里给这次的架构评审准备了几条风险点。好在最后有惊无险

好的架构是让改动局限在一个地方。我笑了笑，决定不解释。我发现这个服务的依赖里有一个是循环的。果然现实比段子更精彩

这次的拆分方案我准备了两套，选了保守的那套。我盯着屏幕沉默了十分钟。我把这个服务的熔断阈值按实际流量重新算了。从此我多了一条团队规约

高并发三件套：缓存、限流、降级，全用上之后问题变成了三个新问题。我把这个单体的核心模块先抽了出来，风险可控。这大概就是程序员的人生吧

我把这条调用链画了出来，发现有一个环。我重新看了一遍手上的计划，把风险项标了出来。我拉了个会议，讨论了一小时，结论是再开一次。果然现实比段子更精彩

单体架构嫌它乱，拆成微服务之后发现是乱得更专业了。我抬起头看了看周围，大家都一样。我拉了个会议，讨论了一小时，结论是再开一次。世界瞬间清净了