接手外包团队开发的微服务项目，人麻了！

网络上涌现着众多微服务开源脚手架，它们吸引用户的方式是将各种功能一股脑地集成进去。然而，它们往往只是告诉你“如何集成”却忽略了“为什么要集成”。

最近，我和小伙伴一起接手了一个由外包团队开发的微服务项目，这个项目采用了当前流行的 Spring Cloud Alibaba 微服务架构，并且是基于一个“大名鼎鼎”的微服务开源脚手架（附带着模块代码截图，相信很多同学一看就能认出来）。然而，在这段时间里，我受到了来自"外包"和"微服务"这双重 debuff 的折磨。

今天，我想和大家分享一下我在这几天中遇到的问题。希望这几个问题能引起大家的共鸣，以便在未来的微服务开发中避免再次陷入相似的困境。

1、服务模块拆分不合理

绝大部分网上的微服务开源框架都是基于后台管理进行模块拆分的。然而在实际业务开发中，应该以领域建模为基础来划分子服务。

目前的服务拆分方式往往是按照团队或功能来拆分，这种不合理的拆分方式导致了服务调用的混乱，同时增加了分布式事务的风险。

2、微服务拆分后数据库并没拆分

所有服务都共用同一个数据库，这在物理层面无法对数据进行隔离，也导致一些团队为了赶进度，直接读取其他服务的数据表。

这里不禁要问：如果不拆分数据库，那拆分微服务还有何意义？

3、功能复制，不是双倍快乐

在项目中存在一个基础设施模块，其中包括文件上传、数据字典、日志等基础功能。然而，文件上传功能居然在其他模块中重复实现了一遍。就像这样：

4、到处都是无用组件堆彻

在项目的基础模块中，自定义了许多公共的 Starter，并且这些组件在各个微服务中被全都引入。比如第三方登录组件、微信支付组件、不明所以的流程引擎组件、验证码组件等等……

拜托，我们已经有自己的 SSO 登录，不需要微信支付，还有自己的流程引擎。那些根本用不到的东西，干嘛要引入呢？

5、明显的错误没人解决

这个问题是由上面的问题所导致的，由于引入了一个根本不需要的消息中间件，项目运行时不断出现如下所示的连接异常。

项目开发了这么久，出错了这么久，居然没有一个人去解决，真的让人不得不佩服他们的忍受力。

6、配置文件一团乱麻

你看到服务中这一堆配置文件，是不是心里咯噔了一下？

或许有人会说："没什么问题呀，按照不同环境划分不同的配置文件”。可是在微服务架构下，已经有了配置中心，为什么还要这么做呢？这不是画蛇添足吗？

7、乱用配置中心

项目一开始就明确要使用 Apollo 配置中心，一个微服务对应一个 appid，appid 一般与 application.name 一致。

但实际上，多个服务却使用了相同的 appid，多个服务的配置文件还塞在了同一个 appid 下。

更让人费解的是，有些微服务又不使用配置中心。

8、Nacos 注册中心混乱

由于项目有众多参与的团队，为了联调代码，开发人员在启动服务时不得不修改配置文件中 Nacos 的 spring.cloud.nacos.discovery.group 属性，同时需要启动所有相关服务。

这导致了两个问题：一是某个用户提交了自己的配置文件，导致其他人的服务注册到了别的 group，影响他人的联调；二是 Nacos 注册中心会存在一大堆不同的 Group，查找服务变得相当麻烦。

其实要解决这个问题只需要重写一下网关的负载均衡策略，让流量调度到指定的服务即可。据我所知，他们使用的开源框架应该支持这个功能，只是他们不知道怎么使用。

9、接口协议混乱

使用的开源脚手架支持 Dubbo 协议和 OpenFeign 调用，然而在我们的项目中并不会使用 Dubbo 协议，微服务之间只使用 OpenFeign 进行调用。然而，在对外提供接口时，却暴露了一堆支持 Dubbo 协议的接口。

10、部署方式混乱

项目部署到 Kubernetes 云环境，一般来说，服务部署到云上的内部服务应该使用 ClusterIP 的方式进行部署，只有网关服务需要对外访问，网关可以通过 NodePort 或 Ingress 进行访问。

这样做可以避免其他人或服务绕过网关直接访问后端微服务。

然而，他们的部署方式是所有服务都开启了 NodePort 访问，然后在云主机上还要部署一套 Nginx 来反向代理网关服务的 NodePort 端口。

看新闻的过程中，发现越来越多的巨头公司融入低代码生态建设，低代码“朋友圈”正在不断壮大。

各大互联网厂商已经完成或开始启动低代码搭建，开发人才变得紧缺。多家互联网公司也发布了低代码开发工程师的岗位，开启了抢人大战。

有企业透露，用低代码开发平台开发过自己的 ERP、供应链、财务、OA、人力资源和项目管理的全系统应用。这种庞大的系统工程如果用传统开发方式，一般需要至少 10 人工作 1 年以上，而现在只需要 2 个人用 6-8 个月就能完成。同时，低代码也能解决软件应用过多、过乱和数据孤岛的问题。

JNPF快速开发是一个 Vue3 搭建的低代码数据可视化开发平台，将图表或页面元素封装为基础组件，无需编写代码即可完成业务需求。

JNPF 前端采用的是 Vue、Element-UI…；后端采用 Java（.net）、Springboot…；使用门槛低，支持分布式、k8s 集群部署，适用于开发复杂的业务管理系统（ERP、MES 等）；采用可视化组件模式可以有效地扩展不同的业务功能，并方便实现各种业务需求，且不会导致系统臃肿，若想使用某个组件，按需引入即可，反之亦然。

结语

网络上涌现着众多微服务开源脚手架，它们吸引用户的方式是将各种功能一股脑地集成进去。然而，它们往往只是告诉你“如何集成”却忽略了“为什么要集成”。

尽管这些开源项目能够在学习微服务方面事半功倍，但在实际微服务项目中，我们不能盲目照搬，而应该根据项目的实际情况来有选择地裁剪或扩展功能。这样，我们才能更好地应对项目的需求，避免陷入不必要的复杂性，从而更加成功地实施微服务架构。