正常运作的复杂系统一定是从一个正常运作的简单系统演变而来的。从头开始设计的复杂系统永远无法正常工作,也无法靠打补丁来正常运作。你必须从一个简单系统起步。——Gall(盖尔)定律
前言
直接放出笔者个人观点:
对于业务驱动的中小型软件公司,一个项目/产品研发团队里就那么一二十号人,甚至两只手都数得过来的,这样的技术团队里,从上到下,就别XX地去琢磨什么引入高大上的微服务技术架构了,把业务场景理解清楚,夯实技术基础,遵从基本的代码规范,代码写得对人友好些,已经足以支撑业务的发展了。
当然以上观点是针对整个技术团队,以及公司发展的角度,作为个人,拿项目当试验田,出去跳槽方便,对此这种笔者也没资格批判,只是希望咱们能够诚实面对自己的内心。
关于微服务的几个问题
对于闹着,喊着要上微服务的技术团队,笔者一直在想几个问题:
-
你们这系统拆出来了多个所谓微服务模块,彼此之间半年难得互相调用一次,这还是是微服务模块吗?这不就是拆分成了几个应用?
-
然后,拆分出了这么多"微服务模块",共用一个数据库,这是在开玩笑呢?
-
接着就是这个部署问题,你们的运维或者售后一定抱怨过部署太麻烦吧;然后你给写了个部署脚本就算是部署简单了? 专业运维岗位这么简单就被顶替了? 模块之间启动时候的依赖关系,某个模块启动失败之后对它有依赖的模块应该怎么处理?以及服务启动之后的预热,验活等等这些,您那部署脚本里是怎么考虑的?
-
还有就是监控基本为零,出问题时候基本就只能脑补调用链路,然后顺着链路挨个服务器翻日志,祈祷问题能够尽早发现,所以为什么很多"微服务系统"最后都被部署在了一台服务器上,一来是因为是甲方提供的机器有限,二来要是分开部署,日志收集又是个大工程,这里我们就先不谈展示的问题;当然了这个时候上面的"拆分微服务为多个应用"就显出威力了,我都没调用过其他"微服务模块",那这问题定位不就简单了?还有就是监控都没有,那预警就更别想了,客户投诉就是俺们的预警。
-
顺着上一条捋,你会发现他们的链路浅得离谱,99%的调用过了网关层就到实际的业务处理层,整个处理逻辑下来不会再与其他组件有任何关联。基本这就是第一条的翻版了。所以这微服务到底微(为)了个什么?
-
当然还有这个开发阶段,夸下的海口是开发方便,只需要启动你所正在开发的业务系统工程就可以了,那实际情况呢?注册中心,缓存,配置中心,网关,MQ等等,好家伙,电脑内存但凡小点,都轮不到你业务模块出场,更不谈万一你这业务模块真的"微服务"起来,对其他业务模块还有依赖,那就更热闹了。中间要是穿插个"依赖于其他业务模块的1.0,2.0版本的差别",这个酸爽,想想都心潮澎湃。
-
读者自行脑补......

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