微服务改造：踩过的坑！

在技术团队里，我亲身经历了

从一个 2~3 人初创阶段的团队到百人规模技术团队的演变

也见证了技术栈和系统架构从传统到现代的变迁

从最初使用的JSP，到如今前后端分离+SpringCloud的微服务架构

我们的技术、架构和运维模式经历了翻天覆地的变化。复盘一下自己走过的路，尤其是微服务拆分过程中所踩过的那些坑，背过的锅。。。

这里来复盘一下，传统项目改造成微服务架构时，系统拆分所踩过的坑。

微服务拆分的坑

• 每个微服务建独立的数据库呢，还是可以共用？

一般来说每个微服务创建自己独立的数据库，但如果微服务拆分过细就会存在数据库也过细。造成大量的沟通与开发成本。

• 原本一个很小的功能一条 SQL 设定，现在让我调用 3~4 个接口来实现？

某个功能开发到一半，发现表里没数据，然后就想着创建视图来完成。开发人员不理解为什么以前一条 sql 能解决的问题，现在要我调用 3~4 个接口才能实现，并且性能和效率差的不是一星半点。现在开发时间又紧还让我找别人要接口，人家任务也都排的满满的。这时很多开发者就会悄悄的用自己的方法来实现比如用视图，存储过程。如果项目组又没有架构师那就是研发经理没发现基本上就是这么干了。

• 调这么多服务太麻烦了，自己开小灶悄悄实现？

当任务紧时，很多开发者发现调这么多服务太麻烦了，自己开小灶悄悄实现。如果没有代码审查环节，基本上出来的微服务就是乱七八糟的代码了。

• 不知道哪个微服务该负责特定的业务逻辑，职责划分模糊。

这个问题和上一个有点类似，上面可能是开发者主动开小灶。这个问题大多数是开发者无意识的行为，因为他认为这个功能就是自己的。当然这主要是沟通和负责划分的问题。

• 一个小需求的改动可能涉及多个微服务的协调，沟通成本极高。

开发过程中快开发完，发现需要改动。有的是需求问题、有的是理解问题还有的可能是设计上的问题。这时需要调整，这也是软件开发必然会出问题的事情。以前一条线都是自己的调整很简单，但现在涉及多个微服务的协调，沟通成本就极高了。

• 不同微服务的开发进度不一致，影响整体项目上线时间。

服务拆分后就会存在协同开发，不同功能不同团队或人员负责。此时就会出现进度不一致，功能优先等级也不一致的问题。当然也有解决办法比如先定义好接口通过伪代码或接口平台实现伪接口。

• 微服务的日志分散在各个地方，排查问题变得困难。

刚刚开发时大家都是开几个窗口看日志，每次找问题以前 IDE 直接链过去了，现在还得找接口路径，找到微服务再去查。另外一个问题就是 IDE 项目启动过多电脑跟不上了。当然解决方案就是加内存换固态盘，日志搭建 ELK 等等方式。

这的确在改变原本团队的开发习惯，不过坚持下来后会发现微服务之间拆分与解耦在以后业务量变大后、应对变化需求能力、运维及交付成本方面都会带来很多的好处。

但前期服务拆的太细这种问题会被放大，所以前期项目还是不要拆分的太细。

其实回头看这些问题都已经有很有成熟的解决文案，只不过第一次改造项目时经验不足，所以会暴露出各种问题出来，走了不少弯路。比如每个微服务建独立的数据库？成熟的方案就是每个微服务创建自己独立的数据库，跨库数据通过接口来完成。但真正实施过程中会发现每个成员接收程度、开发时间不足、单个功能需要找多人调用接口、原本的开发习惯等等因素，就会出现各种各样的问题。所以文章更多的不是微服务的方案而是一些经验，让初次改造项目的管理者、开发者避开一些坑。

我是栈江湖，如果你喜欢此文章，不要忘记关注+点赞哦！你的支持是我创作的动力。如果你有任何意见或建议，欢迎在下方留言。若转载，请注明文章来源。