返回顶部但凡接手过几年或者十几年前老项目的开发人员应该都有过在一个庞大单体应用中开发新需求，修复BUG的经历。对于这样的项目，重构，是每一个开发人员的梦想，由于过去代码审查的不严格，功能模块负责人的转手再转手再转手，让祖传的‘屎山’堆得越来越高。近些年，微服务的火热也确实很抢眼，所体现出来的优势也非常明显，掌握微服务成了每一个开发人员的必备技能。
那微服务又适合不适合当前你手上的项目呢？
就当前小账本这样的微微微型小蚊子，哪里还用得着微服务这样的牛刀啊！不过也可以小试一下微服务嘛，在此之前，也得仔细斟酌一下单体应用与微服务的差异。
自己现在的工作内容就是在一个生命周期近十年的庞大单体应用上，项目由原来的EJB重构到SpringMVC就一直持续至今没再有过大动作，冗杂了JSP页面, 各类MVC结构，对外暴露给手机端和前端的API，改一个单词都要调试一个小时，开发新需求就得满篇的翻查，将可能影响降到最低，这时候就在想，要是整体结构是微服务那该多好啊，在特定的服务上去添加特定的功能，可大环境又不允许有再次的微服务重构，因此，悲剧总是一次一次的上演，后期开发过程中花的时候是真的长。
但随着项目的老化，在不能带来收益的时候，就寿终正寝了，哪儿还用去微服务化啊，新起的项目，如果能预判到可能的走向，直接微服务起步，那也是很有先见之明的，但如果什么都不明朗，个人认为，还是单体应用起步，后期在合适的时间点上，重构到微服务上。而那些压根就很小的项目，微服务化仅仅为了显得高大上吗，不见得吧，是为了增加工作量而已。
之前面试过一家企业，很小，仅有十二个人，实际的开发人员可能就一半吧，在面试间里，一直在聊团队使用的微服务(貌似也刚起步)，而公司的业务却仅仅是一个会议布展的系统，并发上万的可能性都不大，在这种情况下使用微服务，我想，员工应该会经常加班吧。
微服务有很多优势：
- 单个服务易于开发维护;
- 伸缩性好，对扩展，维护， 复用友好;
- 自组织，选择性强;
- 重构顾虑小;
但这些优势都会在应用体量大到一定的规模之后才能体现出来，在网上可以很轻易的找到类似下面的这一张图(侵删):
因此，对于小规模的工程，采用微服务不是自讨苦吃吗？