谈谈应用微服务过程中我们踩过的坑

背景

笔者刚刚加入一家公司,技术小组情况如下:

  • 8名后端开发,普遍对微服务的技术不了解,但对尝试微服务有极高的热情
  • 对服务治理、分布式、DEVOPS都没什么概念
  • 大家已经在原来架构师的带领下把项目拆分成了18个“微服务”
  • 数据库没有进行拆分,仍然是单库
  • 技术小组没有进行拆分,有了问题大家一起上
  • 笔者的主要职责:对当前项目的架构进行梳理和重新设计,确保平台的稳定性

微服务实施过程中的一些坑

准备不足

开发团队准备不足

对于这样一个团队,在实施微服务过程中,应该是先有一些微服务相关的技术培训或分享,并且分步骤、分阶段进行实施的这样一个过程。

运维团队准备不足

在当时的一个情况下,运维人员数量、能力等方面也是严重滞后,并不能很好的跟开发团队形成配合。
更何况,实施微服务以后,由于服务的数量会变得越来越多,发布的次数也会变得非常多,对运维工作也提出了更大的挑战。
实际上,当时在团队中有一名开发人员几乎已经成了全职的运维人员。

拆分力度过细

从划分服务数量看,18个“微服务”确实数量上有些大了。
拆分过细,导致没有从合理的微服务划分中获得足够多的好处,它只是看起来变成了一个个的服务,但是数据库还是耦合在一起,以前可能在一个系统里写完代码,发布上线就可以了,现在每次业务变更都需要改好多个服务,而且微服务之间需要去处理容错。

总结

微服务不是银弹,不是所有的公司、团队、项目都适合用微服务。
微服务是一个架构风格,你还得为自己的架构决策负责,要根据自己的实际情况去检测考虑,这不光是一个技术和工具的问题,因为技术跟工具已经不是门槛了,更多的是我们对业务的理解,以及设计问题。
实际上,笔者经过综合考虑,决定废弃掉原有的“微服务”架构设计,暂时采用传统的“单体架构”设计,取得了很好的效果。

坚持原创技术分享,您的支持将鼓励我继续创作!