最近，笔者和小伙伴一起接手了一个由外包团队开发的微服务项目，这个项目采用了当前流行的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端口。
结语
网络上涌现着众多微服务开源脚手架，它们吸引用户的方式是将各种功能一股脑地集成进去。然而，它们往往只是告诉你“如何集成”却忽略了“为什么要集成”。
尽管这些开源项目能够在学习微服务方面事半功倍，但在实际微服务项目中，我们不能盲目照搬，而应该根据项目的实际情况来有选择地裁剪或扩展功能。这样，我们才能更好地应对项目的需求，避免陷入不必要的复杂性，从而更加成功地实施微服务架构。
作者丨飘渺Jam
