为什么我讨厌微服务？

先声明，我就是个写业务代码的，不是什么架构师。但干了十年开发，从SSH单体一路干到Spring Cloud微服务，中间被坑得死去活来。今天想说点大实话：微服务这东西，对大多数中小团队来说就是个坑，而且是那种你跳进去还不好意思说出来的坑。

上个月我们组接手一个遗留系统，说是微服务，结果数了一下，光生产环境就跑了四十多个服务。每个服务都有自己的数据库、自己的Redis、自己的Kafka topic。改一个用户状态的功能，要顺藤摸瓜找七八个服务，联调环境配了三天，结果因为一个服务版本没对齐，整个流程跑不通。那晚我蹲在工位上，外卖凉了也没吃，腰疼得直不起来，盯着链路追踪的调用链，突然觉得自己像个傻逼。

单体惹你了？

很多人一说单体就皱眉，觉得那是上古时代的产物。可我想问：你那个只是把Spring Boot打成一个jar包丢到服务器上跑，业务逻辑全在一个服务里，怎么就丢人了？单体部署简单啊，一个jar包，java -jar就完了，不需要K8s，不需要Service Mesh，不需要那堆有的没的。出了问题，日志日志日志，一个进程里全能看到，断点一打，调试到天亮也不怕。微服务呢？日志分散在十几个Pod里，你翻吧，grep到吐血，有时候连日志都收集不全，只能靠猜。

当然，单体也有单体的恶心地方。代码后期会变成屎山，if嵌套if，全局变量满天飞，改个公共类所有模块都受影响。我承认。但问题在于，大多数项目的体量，根本到不了单体撑不住的地步。一个团队十几个人，两三个微服务就够了，硬拆成十几个，每个人维护两三个服务，互相之间接口对到崩溃。我见过最讽刺的对比：隔壁组用单体，两周上线一个功能；我们组用微服务，同一个功能要排期三周，因为要跨四个服务开会协调。效率呢？

技术债务其实是个债

都说技术债务要还，但很多人忘了，拆微服务本身就是一笔新的债务。你要维护服务注册中心，要搞配置中心，要处理分布式事务，要解决幂等，要设计重试机制……这些本来是框架和基础设施的活，全砸到业务代码里。我们那个项目，光@Transactional就差点出事，因为跨服务调用时本地事务根本管不住，最后只能牺牲一致性，搞了个补偿脚本定时刷数据。你敢信？

我有个朋友在阿里待过，他们确实是靠微服务撑住双十一的。但人家是什么投入？专门的中间件团队，几百人维护基础设施建设。你呢？你公司就三个后端，连个运维都没有，也学人家搞微服务，最后全在加班写部署脚本。我讨厌的不是微服务这个技术，而是那些不问青红皂白就喊着“微服务是趋势”的人。趋势是别人的，你的系统崩溃时，只有你和你的午休时间受损。

身体是诚实的

去年体检，我有甲状腺结节，医生说跟情绪和睡眠有关。我这两年因为线上问题半夜爬起来排查的次数，比之前五年加起来都多。每次报警一响，心脏就突突跳，脑子里第一个反应是“哪个服务又假死了”。好几次都是因为服务间调用超时设置不对，A服务等B服务，B等C，C挂了，然后全部超时，连环雪崩。这种体验，我在单体时代真没怎么遇到过。那时最坏的情况就是服务重启，几百人在线等个几十秒，也就过去了。

所以现在有人问我架构选型，我就一句话：能用单体的绝不上微服务，除非你的团队规模和业务复杂度真到了那个临界点。怎么判断？看看你的服务是不是已经超过五六个，并且每个都有独立的业务团队在维护。如果没有，老老实实单体吧。别为了简历上写“微服务实战经验”而折腾自己。头发本来就不多了。

到最后

我不是说我不学微服务，我学了，也用了，甚至考了个云原生架构师认证。但越是学，越觉得它是个奢侈玩意。技术的本质是解决问题，不是制造问题。如果哪天业务膨胀到单体扛不住，我自然会拆。但在那之前，谁要再让我为了“技术先进性”去拆服务，我就拿这个文章甩他脸上。

眼睛有点干，不写了。希望看到这篇文章的你，如果正在微服务的坑里挣扎，别怀疑自己。有些错是架构的错，不是你的错。

——写于又一个加班的深夜