写点什么

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

  • 2024-02-21
    福建
  • 本文字数:2188 字

    阅读完需:约 7 分钟

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

最近,我和小伙伴一起接手了一个由外包团队开发的微服务项目,这个项目采用了当前流行的 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 等);采用可视化组件模式可以有效地扩展不同的业务功能,并方便实现各种业务需求,且不会导致系统臃肿,若想使用某个组件,按需引入即可,反之亦然。

结语

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

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

用户头像

还未添加个人签名 2023-06-19 加入

还未添加个人简介

评论

发布
暂无评论
接手外包团队开发的微服务项目,人麻了!_伤感汤姆布利柏_InfoQ写作社区