Java微服务常见问题_java架构师指南：微服务在运用中可能会出现哪些问题

每个人都在宣传“微服务”有多好，例如易于扩展，松散耦合，简单服务，独立开发，易于维护，轻量级等等。尽管这些优点也是事实，但“微服务”仍然存在许多问题，特别是对于刚起步的团队而言。应用微服务后，趟坑真的可以趟到你崩溃。下面就普及一些常见的问题来给大家打个预防针：

不是所有项目都适用微服务

一些项目规模相对较小，或者是项目才刚刚开始，只有三四个人负责开发和维护。那么在这个时期不建议立即使用微服务架构。在这种情况下，从事微服务不仅是“杀鸡用牛刀”，而且不必要地增加了项目的复杂性。本身一个单体结构就可以搞定的事情没必要拆分N个多个节点，并且人员不足。支持这么多节点的开发和维护完全是自找苦吃。相反，在项目成熟且规模较大之后，将原始结构缓慢分解为微服务才是正确的方法。

不要拆分过多过细的服务

即使项目经过评估后适合拆为微服务架构，但也不要过度拆解。有的团队喜欢将项目拆成很细很细的颗粒，最后把项目搞的特别复杂，整个团队都陷进去了。

拆分服务的颗粒度应该根据业务发展和团队现状综合去考虑。这里可以参考一个很火的理论「康威定律」。什么样的团队，就产生什么样的架构，微服务拆分的颗粒度是需要和团队结构相匹配的。当你着手拆微服务的时候，得先评估一下团队人员和素质，一般在开发期，2-3个人开发一个服务是合理的，在维护期，1个人维护2-3个服务也是合理的。

如果拆分过细，开发人员跟不上，会严重降低大家的工作效率。并且过细的服务，会导致一个请求的调用链条很长，不仅会影响请求的响应时间，也会对线上问题排查带来增加难度。

没有DevOps就不要急于微服务

一个稳定的微服务架构，是需要持续集成、自动化部署、自动化测试、健全的监控体系来保障的。如果团队还不具备DevOps，这些基础的建设都没有做好，一上来就搞微服务的话，就会导致实施过程中问题百出，微服务的优势不能发挥。