挑战challenge (挑战重重-承接外包团队的微服务名目-头痛不止)

嗨，大家好，我是飘渺。

最近，我和小同伴一同接手了一个由外包团队开发的微服务名目，这个名目驳回了以后盛行的SpringCloudAlibaba微服务架构，并且是基于一个小名鼎鼎的微服务开源脚手架（附带着模块代码截图，置信很多同窗一看就能认出来）。但是，在这段期间里，我遭到了来自”外包”和”微服务”这双重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端口。

结语

网络上涌现着泛滥微服务开源脚手架，它们吸援用户的方式是将各种性能一股脑地集成出来。但是，它们往往只是通知你如何集成却疏忽了为什么要集成。

虽然这些开源名目能够在学习微服务方面事倍功半，但在实践微服务名目中，咱们不能自觉照搬，而应该依据名目标实践状况来有选用地裁剪或裁减性能。这样，咱们才干更好地应答名目标需求，防止堕入不用要的复杂性，从而愈加成功地实施微服务架构。

最后，这个开源名目你们意识吗？