微服务了个寂寞

正常运作的复杂系统一定是从一个正常运作的简单系统演变而来的。从头开始设计的复杂系统永远无法正常工作，也无法靠打补丁来正常运作。你必须从一个简单系统起步。——Gall(盖尔)定律

前言

直接放出笔者个人观点：

对于业务驱动的中小型软件公司，一个项目/产品研发团队里就那么一二十号人，甚至两只手都数得过来的，这样的技术团队里，从上到下，就别XX地去琢磨什么引入高大上的微服务技术架构了，把业务场景理解清楚，夯实技术基础，遵从基本的代码规范，代码写得对人友好些，已经足以支撑业务的发展了。

当然以上观点是针对整个技术团队，以及公司发展的角度，作为个人，拿项目当试验田，出去跳槽方便，对此这种笔者也没资格批判，只是希望咱们能够诚实面对自己的内心。

关于微服务的几个问题

对于闹着，喊着要上微服务的技术团队，笔者一直在想几个问题：

1. 你们这系统拆出来了多个所谓微服务模块，彼此之间半年难得互相调用一次，这还是是微服务模块吗？这不就是拆分成了几个应用？

2. 然后，拆分出了这么多"微服务模块"，共用一个数据库，这是在开玩笑呢？

3. 接着就是这个部署问题，你们的运维或者售后一定抱怨过部署太麻烦吧；然后你给写了个部署脚本就算是部署简单了？ 专业运维岗位这么简单就被顶替了？ 模块之间启动时候的依赖关系，某个模块启动失败之后对它有依赖的模块应该怎么处理？以及服务启动之后的预热，验活等等这些，您那部署脚本里是怎么考虑的？

4. 还有就是监控基本为零，出问题时候基本就只能脑补调用链路，然后顺着链路挨个服务器翻日志，祈祷问题能够尽早发现，所以为什么很多"微服务系统"最后都被部署在了一台服务器上，一来是因为是甲方提供的机器有限，二来要是分开部署，日志收集又是个大工程，这里我们就先不谈展示的问题；当然了这个时候上面的"拆分微服务为多个应用"就显出威力了，我都没调用过其他"微服务模块"，那这问题定位不就简单了？还有就是监控都没有，那预警就更别想了，客户投诉就是俺们的预警。

5. 顺着上一条捋，你会发现他们的链路浅得离谱，99%的调用过了网关层就到实际的业务处理层，整个处理逻辑下来不会再与其他组件有任何关联。基本这就是第一条的翻版了。所以这微服务到底微（为）了个什么？

6. 当然还有这个开发阶段，夸下的海口是开发方便，只需要启动你所正在开发的业务系统工程就可以了，那实际情况呢？注册中心，缓存，配置中心，网关，MQ等等，好家伙，电脑内存但凡小点，都轮不到你业务模块出场，更不谈万一你这业务模块真的"微服务"起来，对其他业务模块还有依赖，那就更热闹了。中间要是穿插个"依赖于其他业务模块的1.0，2.0版本的差别"，这个酸爽，想想都心潮澎湃。

7. 读者自行脑补......

填坑侠

参考

1. 真的有必要上微服务吗？
2. 戳破微服务的七大谎言 - Uber的微服务依赖关系图让人印象深刻
3. 雄伟巨石” - 单体应用也能做得很好
4. 我在传统行业做了 10 几年的企业应用，从地市级到省级系统，只要是面向内部用户的，就没有一个是单体系统满足不了的。
5. 云原生时代的几个爆论 - 微服务难民
6. 当年一穷二白搞微服务……我太难了
   a. 微服务这套体系本身，把以前单体系统的复杂度转移到了技术基础设施上。
   b. 很多工作其实是需要自动化的。在踏进微服务这个神坑前，一定要考虑清楚：公司有没有合适的基础设施？
7. 你只是做了个比单体还糟糕的分布式单体！