公众号「古时的风筝」，专注于后端技术，尤其是 Java 及周边生态。
个人博客：www.moonkite.cn
大家好，我是风筝
最近忙的没有时间写文章，是因为正在忙着改造一个项目。白天效率百分百，连摸鱼的时间都没有，一天 8 个小时下来，头昏脑胀，有时候晚上还要加个大班。
正是因为这几天痛苦的经历，才有了文章标题的教训，小项目还是别用微服务了，谁用谁难受啊。
这倒不是说搞微服务不好，主要是当项目较小、人手不多的情况下，搞微服务的开发、部署成本太大，一个人同时改几个微服务模块，模块之间还有调用关系，很容易搞的人心力交瘁。本来应该几个小时能搞好的东西，在微服务的加持下，各服务间来回一调用，弄个两三天一点不成问题啊。
微服务的好处有很多，从前几年开始，微服务便大行其道，加上容器化技术的流行。使得项目到了无微服务不欢的程度，不论大厂还是小厂，不论是互联网产品还是私有化项目，都要搞个微服务架构出来。
架构图一通天花乱坠，领导拍手称赞，甲方觉得牛掰。开发团队也是自信满满，能通过项目实践新的技术方案，技术栈又丰满了不少，何乐而不为呢。
我刚开始接触微服务的时候，也似把它当做银弹。一个系统，上来给它拆吧拆吧，变成几个服务，瞬间解耦了，每个服务还能抽离出来，给其他系统用。无非就是服务间调用麻烦一点儿嘛，但是 RPC 框架这么多，又封装的很简单，也就不算啥事儿了。
那时候我自己业余时间做的小产品不仅要前后端分离，还要搞俩微服务出来，这痴迷程度可见一斑。正因为大多数技术人都有这样的痴迷，才会有那么多不该拆分的服务被拆分出来，搞成微服务项目。
微服务的好处
微服务的好处肯定是有的，而且还不少，要不然也不至于这么流行。
模块化和高可用性
微服务将应用程序分解为小的服务单元，每个服务都专注于特定的业务功能。每个微服务都独立开发、独立部署、独立运行。一个服务可以有多个实例，就算某个服务的全部实例都挂掉了，也不会影响其他服务的功能。
比如一个电商系统，订单服务和通知服务独立部署运行，就算通知服务都挂了，那也不影响用户下单，只不过无法及时收到短信、应用内通知而已。
异构设计
正因为每个服务独立运行，所以微服务允许每个服务使用适合其需求的开发语言和技术栈。一个服务可以用 C++开发，另一个服务用 Go 开发，其他服务用 Java 开发，也是完全没有问题的，只要处理好服务间调用就可以了。
团队自治
每个微服务可以由一个小团队负责开发和维护，这种自治性可以提高团队的生产力和创造力。
更快的交付和上线时间
微服务的独立部署允许快速交付新功能和更新，减少了发布的风险和延迟。
这样一看，好处还真的不少呢。但是，千好万好，也抵不过人手不足这一条。只要人不够，上面提到的好处马上就会变成弊端。
人手不够，就不要微服务了
首先说说团队自治。一个人管2、3个模块，确实是自治了，自己治自己。当你一个人负责两个或更多模块的时候，你就能深刻的体会到。
当你同时修改这几个模块的时候，你要在本地将这几个服务启动、调试，如果公司不人道，给你配了台垃圾电脑，那连项目都别想痛痛快快的启动。
而且除了这几个服务外，如果没有公用的开发环境，你还要在本地跑着配置中心、注册中心、网关，痛苦加倍。
这时候你会在心里想，为什么要整个微服务，怎么这么想不开。
工期太紧，就不要微服务了
还有就是工期紧的项目。本来光搞业务就已经很紧张了，结果老板还要催着、赶着，那这种情况下建议还是不要微服务了。
工期紧可能有几种情况。
作为乙方，给甲方的私有化项目
这种项目大多数以业务为主，对架构和性能要求往往没那么高，完全可以单体解决。如果采用微服务的话， 开发周期加长了不说，后期的维护成本会很大，尤其是不熟悉项目的人做后期维护。
着急上线验证市场的产品
这种情况下， 商业模式能跑通才是关键。也就是说，产品能不能活下来，还是个问题，有待验证。所以前期没必要再技术上过分投入，怎么快怎么来，怎么简单怎么来。如果产品真的能活下去，那将来再进行改造的话，也不是什么难事。毕竟活下来了，说明能赚钱了。有钱就有人、就有改造的资本了。
网络、部署环境有限制，就不要微服务了
在和朋友聊要不要用微服务的时候，有个朋友说，给国企或者ZF做的项目，能用单体就用单体吧。他说曾经给某个ZF部门做项目，项目是在自身产品功能上做一些定制化改造，微服务框架，有6、7个服务。
结果甲方那边网络完全是内网环境，系统有指定的国产系统，机器开的每一个端口都要报备、说明，部署有指定的部署平台，连 RPC 调用都有特殊的要求。
每次上线要在外部网络打包，然后用物理设备拷到内网，7、8个包，每一个包走一次部署流程，然后服务间调用是否成功也只能部署完之后才能测试。
本来1天能做完的事儿，3、4天都弄不完，每天都薅头发。
总结
作为程序员，追求技术进步那是必须的，所以说，微服务是我们每一个开发者都必须掌握的。但是，微服务也不是银弹，不能任何项目都无脑的使用。
当你有一天可以决定一个项目是用单体还是采用微服务框架时，不能一味的只从技术角度出发，要各方权衡，看有没有必要使用微服务框架。
水能载舟，亦能覆舟。微服务也是一样，合适的场景下如鲲鹏展翅，不合适的时候那就是洪水猛兽呀。
推荐阅读
我的第一个 Chrome 插件上线了，欢迎试用！
前端同事最讨厌的后端行为，看看你中了没有
边写代码边叨咕的同事，人家可能在运用小黄鸭调试法
