每个人都在宣传“微服务”有多好,例如易于扩展,松散耦合,简单服务,独立开发,易于维护,轻量级等等。尽管这些优点也是事实,但“微服务”仍然存在许多问题,特别是对于刚起步的团队而言。应用微服务后,趟坑真的可以趟到你崩溃。下面就普及一些常见的问题来给大家打个预防针:
不是所有项目都适用微服务
一些项目规模相对较小,或者是项目才刚刚开始,只有三四个人负责开发和维护。那么在这个时期不建议立即使用微服务架构。在这种情况下,从事微服务不仅是“杀鸡用牛刀”,而且不必要地增加了项目的复杂性。本身一个单体结构就可以搞定的事情没必要拆分N个多个节点,并且人员不足。支持这么多节点的开发和维护完全是自找苦吃。相反,在项目成熟且规模较大之后,将原始结构缓慢分解为微服务才是正确的方法。
不要拆分过多过细的服务
即使项目经过评估后适合拆为微服务架构,但也不要过度拆解。有的团队喜欢将项目拆成很细很细的颗粒,最后把项目搞的特别复杂,整个团队都陷进去了。
拆分服务的颗粒度应该根据业务发展和团队现状综合去考虑。这里可以参考一个很火的理论「康威定律」。什么样的团队,就产生什么样的架构,微服务拆分的颗粒度是需要和团队结构相匹配的。当你着手拆微服务的时候,得先评估一下团队人员和素质,一般在开发期,2-3个人开发一个服务是合理的,在维护期,1个人维护2-3个服务也是合理的。
如果拆分过细,开发人员跟不上,会严重降低大家的工作效率。并且过细的服务,会导致一个请求的调用链条很长,不仅会影响请求的响应时间,也会对线上问题排查带来增加难度。
没有DevOps就不要急于微服务
一个稳定的微服务架构,是需要持续集成、自动化部署、自动化测试、健全的监控体系来保障的。如果团队还不具备DevOps,这些基础的建设都没有做好,一上来就搞微服务的话,就会导致实施过程中问题百出,微服务的优势不能发挥。