笔者最近忙得没有时间写文章，是因为正在忙着改造一个项目。白天效率百分百，连摸鱼的时间都没有，一天 8 个小时下来，头昏脑胀，有时候晚上还要加个大班。

正是因为这几天痛苦的经历，才有了文章标题的教训，小项目还是别用微服务了，谁用谁难受啊。

这倒不是说搞微服务不好，主要是当项目较小、人手不多的情况下，搞微服务的开发、部署成本太大，一个人同时改几个微服务模块，模块之间还有调用关系，很容易搞得人心力交瘁。本来应该几个小时能搞好的东西，在微服务的加持下，各服务间来回一调用，弄个两三天一点不成问题啊。

微服务的好处有很多，从前几年开始，微服务便大行其道，加上容器化技术的流行。使得项目到了无微服务不欢的程度，不论大厂还是小厂，不论是互联网产品还是私有化项目，都要搞个微服务架构出来。

架构图一通天花乱坠，领导拍手称赞，甲方觉得牛掰。开发团队也是自信满满，能通过项目实践新的技术方案，技术栈又丰满了不少，何乐而不为呢。

我刚开始接触微服务的时候，也似把它当做银弹。一个系统，上来给它拆吧拆吧，变成几个服务，瞬间解耦了，每个服务还能抽离出来，给其他系统用。无非就是服务间调用麻烦一点儿嘛，但是 RPC 框架这么多，又封装的很简单，也就不算啥事儿了。

那时候我自己业余时间做的小产品不仅要前后端分离，还要搞俩微服务出来，这痴迷程度可见一斑。正因为大多数技术人都有这样的痴迷，才会有那么多不该拆分的服务被拆分出来，搞成微服务项目。

微服务的好处肯定是有的，而且还不少，要不然也不至于这么流行。

微服务将应用程序分解为小的服务单元，每个服务都专注于特定的业务功能。每个微服务都独立开发、独立部署、独立运行。一个服务可以有多个实例，就算某个服务的全部实例都挂掉了，也不会影响其他服务的功能。

比如一个电商系统，订单服务和通知服务独立部署运行，就算通知服务都挂了，那也不影响用户下单，只不过无法及时收到短信、应用内通知而已。

正因为每个服务独立运行，所以微服务允许每个服务使用适合其需求的开发语言和技术栈。一个服务可以用 C++开发，另一个服务用 Go 开发，其他服务用 Java 开发，也是完全没有问题的，只要处理好服务间调用就可以了。

每个微服务可以由一个小团队负责开发和维护，这种自治性可以提高团队的生产力和创造力。

微服务的独立部署允许快速交付新功能和更新，减少了发布的风险和延迟。

这样一看，好处还真的不少呢。但是，千好万好，也抵不过人手不足这一条。只要人不够，上面提到的好处马上就会变成弊端。

首先说说团队自治。一个人管2、3个模块，确实是自治了，自己治自己。当你一个人负责两个或更多模块的时候，你就能深刻的体会到。

当你同时修改这几个模块的时候，你要在本地将这几个服务启动、调试，如果公司不人道，给你配了台垃圾电脑，那连项目都别想痛痛快快的启动。

而且除了这几个服务外，如果没有公用的开发环境，你还要在本地跑着配置中心、注册中心、网关，痛苦加倍。

这时候你会在心里想，为什么要整个微服务，怎么这么想不开。

还有就是工期紧的项目。本来光搞业务就已经很紧张了，结果老板还要催着、赶着，那这种情况下建议还是不要微服务了。

工期紧可能有几种情况。

这种项目大多数以业务为主，对架构和性能要求往往没那么高，完全可以单体解决。如果采用微服务的话， 开发周期加长了不说，后期的维护成本会很大，尤其是不熟悉项目的人做后期维护。

这种情况下， 商业模式能跑通才是关键。也就是说，产品能不能活下来，还是个问题，有待验证。所以前期没必要再技术上过分投入，怎么快怎么来，怎么简单怎么来。如果产品真的能活下去，那将来再进行改造的话，也不是什么难事。毕竟活下来了，说明能赚钱了。有钱就有人、就有改造的资本了。

在和朋友聊要不要用微服务的时候，有个朋友说，遇到网络、部署环境有限制的甲方，能用单体就用单体吧。他说曾经给某个部门做项目，项目是在自身产品功能上做一些定制化改造，微服务框架，有6、7个服务。

结果甲方那边网络完全是内网环境，系统有指定的国产系统，机器开的每一个端口都要报备、说明，部署有指定的部署平台，连 RPC 调用都有特殊的要求。

每次上线要在外部网络打包，然后用物理设备拷到内网，7、8个包，每一个包走一次部署流程，然后服务间调用是否成功也只能部署完之后才能测试。

本来1天能做完的事儿，3、4天都弄不完，每天都薅头发。

作为程序员，追求技术进步那是必须的，所以说，微服务是我们每一个开发者都必须掌握的。但是，微服务也不是银弹，不能任何项目都无脑使用。

当你有一天可以决定一个项目是用单体还是采用微服务框架时，不能一味的只从技术角度出发，要各方权衡，看有没有必要使用微服务框架。

水能载舟，亦能覆舟。微服务也是一样，合适的场景下如鲲鹏展翅，不合适的时候那就是洪水猛兽呀。