😂 IT段子

架构图上的每个方块，落地时都要有人维护。我在心里点了点头。我把这个模块的职责重新定义了一遍。我把它写进了组内的避坑文档第一章

我把网关的路由规则精简了一遍，清晰多了。我把手上的资料翻出来又读了两遍。我把这个服务的灰度策略配上了，能按用户分批

微服务拆了二十个，一次下单要跨八个服务，链路追踪看着像绕地球一圈。我决定先把手上的事情做完再处理这件事。我发现这个模块的边界和另一个服务重叠了。办公室安静得能听见键盘声

这个服务的边界和另一个服务有明显重叠。我想反驳，但发现他说得对。我默默把服务数量从二十个合并回了七个

高并发三件套：缓存、限流、降级，全用上之后问题变成了三个新问题。我想反驳，但发现他说得对。我把这个服务的超时和重试配好了，级联失败少了。好在最后有惊无险

架构的演进通常是问题驱动而非设计驱动。我盯着屏幕，觉得这才是我的一天。我把这个接口的返回做成了版本兼容的，老调用方不受影响。真香定律准时生效

好的架构是让改动局限在一个地方。我不知道该说什么，就笑了笑。我发现这个调用链的层级太深，一次请求穿了六层。这大概就是程序员的人生吧

CAP 定理背得滚瓜烂熟，选型的时候还是全都要。我发现这个服务的响应时间受下游影响很大。我把它写进了组内的避坑文档第一章

架构的复杂度最终会变成人的复杂度。我在心里给这次的架构决策写了个说明文档。这条经验值直接拉满

CAP 定理背得滚瓜烂熟，选型的时候还是全都要。我愣了两秒，然后继续敲代码。我在心里给这次的架构演进做了个路线图。第二天这个方案就变成了团队标准做法