潍坊建设局职称公布网站,dw 个人网站怎么做,衡水需要做网站的公司,维拓设计在北京排名嗨#xff0c;大家好#xff0c;我是飘渺。
最近#xff0c;我和小伙伴一起接手了一个由外包团队开发的微服务项目#xff0c;这个项目采用了当前流行的Spring Cloud Alibaba微服务架构#xff0c;并且是基于一个“大名鼎鼎”的微服务开源脚手架#xff08;附带着模块代…嗨大家好我是飘渺。
最近我和小伙伴一起接手了一个由外包团队开发的微服务项目这个项目采用了当前流行的Spring Cloud Alibaba微服务架构并且是基于一个“大名鼎鼎”的微服务开源脚手架附带着模块代码截图相信很多同学一看就能认出来。然而在这段时间里我受到了来自外包和微服务这双重debuff的折磨。 今天我想和大家分享一下我在这几天中遇到的问题。希望这几个问题能引起大家的共鸣以便在未来的微服务开发中避免再次陷入相似的困境。
1、服务模块拆分不合理
绝大部分网上的微服务开源框架都是基于后台管理进行模块拆分的。然而在实际业务开发中应该以领域建模为基础来划分子服务。
目前的服务拆分方式往往是按照团队或功能来拆分这种不合理的拆分方式导致了服务调用的混乱同时增加了分布式事务的风险。
2、微服务拆分后数据库并没拆分
所有服务都共用同一个数据库这在物理层面无法对数据进行隔离也导致一些团队为了赶进度直接读取其他服务的数据表。
这里不禁要问如果不拆分数据库那拆分微服务还有何意义
3、功能复制不是双倍快乐
在项目中存在一个基础设施模块其中包括文件上传、数据字典、日志等基础功能。然而文件上传功能居然在其他模块中重复实现了一遍。就像这样 4、到处都是无用组件堆彻
在项目的基础模块中自定义了许多公共的Starter并且这些组件在各个微服务中被全都引入。比如第三方登录组件、微信支付组件、不明所以的流程引擎组件、验证码组件等等…… 拜托我们已经有自己的SSO登录不需要微信支付还有自己的流程引擎。那些根本用不到的东西干嘛要引入呢
5、明显的错误没人解决
这个问题是由上面的问题所导致的由于引入了一个根本不需要的消息中间件项目运行时不断出现如下所示的连接异常。 项目开发了这么久出错了这么久居然没有一个人去解决真的让人不得不佩服他们的忍受力。
6、配置文件一团乱麻
你看到服务中这一堆配置文件是不是心里咯噔了一下 或许有人会说没什么问题呀按照不同环境划分不同的配置文件”。可是在微服务架构下已经有了配置中心为什么还要这么做呢这不是画蛇添足吗
7、乱用配置中心
项目一开始就明确要使用Apollo配置中心一个微服务对应一个appidappid一般与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端口。 结语
网络上涌现着众多微服务开源脚手架它们吸引用户的方式是将各种功能一股脑地集成进去。然而它们往往只是告诉你“如何集成”却忽略了“为什么要集成”。
尽管这些开源项目能够在学习微服务方面事半功倍但在实际微服务项目中我们不能盲目照搬而应该根据项目的实际情况来有选择地裁剪或扩展功能。这样我们才能更好地应对项目的需求避免陷入不必要的复杂性从而更加成功地实施微服务架构。
最后这个开源项目你们认识吗
