嗨，大家好，我是飄渺。

最近，我和小伙伴一起接手了一個(gè)由外包團(tuán)隊(duì)開發(fā)的微服務(wù)項(xiàng)目，這個(gè)項(xiàng)目采用了當(dāng)前流行的Spring Cloud Alibaba微服務(wù)架構(gòu)，并且是基于一個(gè)“大名鼎鼎”的微服務(wù)開源腳手架（附帶著模塊代碼截圖，相信很多同學(xué)一看就能認(rèn)出來）。然而，在這段時(shí)間里，我受到了來自"外包"和"微服務(wù)"這雙重debuff的折磨。

今天，我想和大家分享一下我在這幾天中遇到的問題。希望這幾個(gè)問題能引起大家的共鳴，以便在未來的微服務(wù)開發(fā)中避免再次陷入相似的困境。

1、服務(wù)模塊拆分不合理

絕大部分網(wǎng)上的微服務(wù)開源框架都是基于后臺(tái)管理進(jìn)行模塊拆分的。然而在實(shí)際業(yè)務(wù)開發(fā)中，應(yīng)該以領(lǐng)域建模為基礎(chǔ)來劃分子服務(wù)。

目前的服務(wù)拆分方式往往是按照?qǐng)F(tuán)隊(duì)或功能來拆分，這種不合理的拆分方式導(dǎo)致了服務(wù)調(diào)用的混亂，同時(shí)增加了分布式事務(wù)的風(fēng)險(xiǎn)。

2、微服務(wù)拆分后數(shù)據(jù)庫并沒拆分

所有服務(wù)都共用同一個(gè)數(shù)據(jù)庫，這在物理層面無法對(duì)數(shù)據(jù)進(jìn)行隔離，也導(dǎo)致一些團(tuán)隊(duì)為了趕進(jìn)度，直接讀取其他服務(wù)的數(shù)據(jù)表。

這里不禁要問：如果不拆分?jǐn)?shù)據(jù)庫，那拆分微服務(wù)還有何意義？

3、功能復(fù)制，不是雙倍快樂

在項(xiàng)目中存在一個(gè)基礎(chǔ)設(shè)施模塊，其中包括文件上傳、數(shù)據(jù)字典、日志等基礎(chǔ)功能。然而，文件上傳功能居然在其他模塊中重復(fù)實(shí)現(xiàn)了一遍。就像這樣：

圖片

4、到處都是無用組件堆徹

在項(xiàng)目的基礎(chǔ)模塊中，自定義了許多公共的Starter，并且這些組件在各個(gè)微服務(wù)中被全都引入。比如第三方登錄組件、微信支付組件、不明所以的流程引擎組件、驗(yàn)證碼組件等等……

圖片

圖片

拜托，我們已經(jīng)有自己的SSO登錄，不需要微信支付，還有自己的流程引擎。那些根本用不到的東西，干嘛要引入呢？

5、明顯的錯(cuò)誤沒人解決

這個(gè)問題是由上面的問題所導(dǎo)致的，由于引入了一個(gè)根本不需要的消息中間件，項(xiàng)目運(yùn)行時(shí)不斷出現(xiàn)如下所示的連接異常。

圖片

項(xiàng)目開發(fā)了這么久，出錯(cuò)了這么久，居然沒有一個(gè)人去解決，真的讓人不得不佩服他們的忍受力。

6、配置文件一團(tuán)亂麻

你看到服務(wù)中這一堆配置文件，是不是心里咯噔了一下？

圖片

或許有人會(huì)說："沒什么問題呀，按照不同環(huán)境劃分不同的配置文件”?？墒窃谖⒎?wù)架構(gòu)下，已經(jīng)有了配置中心，為什么還要這么做呢？這不是畫蛇添足嗎？

7、亂用配置中心

項(xiàng)目一開始就明確要使用Apollo配置中心，一個(gè)微服務(wù)對(duì)應(yīng)一個(gè)appid，appid一般與application.name一致。

但實(shí)際上，多個(gè)服務(wù)卻使用了相同的appid，多個(gè)服務(wù)的配置文件還塞在了同一個(gè)appid下。

更讓人費(fèi)解的是，有些微服務(wù)又不使用配置中心。

8、Nacos注冊(cè)中心混亂

由于項(xiàng)目有眾多參與的團(tuán)隊(duì)，為了聯(lián)調(diào)代碼，開發(fā)人員在啟動(dòng)服務(wù)時(shí)不得不修改配置文件中Nacos的spring.cloud.nacos.discovery.group屬性，同時(shí)需要啟動(dòng)所有相關(guān)服務(wù)。

這導(dǎo)致了兩個(gè)問題：一是某個(gè)用戶提交了自己的配置文件，導(dǎo)致其他人的服務(wù)注冊(cè)到了別的group，影響他人的聯(lián)調(diào)；二是Nacos注冊(cè)中心會(huì)存在一大堆不同的Group，查找服務(wù)變得相當(dāng)麻煩。

其實(shí)要解決這個(gè)問題只需要重寫一下網(wǎng)關(guān)的負(fù)載均衡策略，讓流量調(diào)度到指定的服務(wù)即可。據(jù)我所知，他們使用的開源框架應(yīng)該支持這個(gè)功能，只是他們不知道怎么使用。

9、接口協(xié)議混亂

使用的開源腳手架支持Dubbo協(xié)議和OpenFeign調(diào)用，然而在我們的項(xiàng)目中并不會(huì)使用Dubbo協(xié)議，微服務(wù)之間只使用OpenFeign進(jìn)行調(diào)用。然而，在對(duì)外提供接口時(shí)，卻暴露了一堆支持Dubbo協(xié)議的接口。

10、部署方式混亂

項(xiàng)目部署到Kubernetes云環(huán)境，一般來說，服務(wù)部署到云上的內(nèi)部服務(wù)應(yīng)該使用ClusterIP的方式進(jìn)行部署，只有網(wǎng)關(guān)服務(wù)需要對(duì)外訪問，網(wǎng)關(guān)可以通過NodePort或Ingress進(jìn)行訪問。

這樣做可以避免其他人或服務(wù)繞過網(wǎng)關(guān)直接訪問后端微服務(wù)。

然而，他們的部署方式是所有服務(wù)都開啟了NodePort訪問，然后在云主機(jī)上還要部署一套Nginx來反向代理網(wǎng)關(guān)服務(wù)的NodePort端口。

結(jié)語

網(wǎng)絡(luò)上涌現(xiàn)著眾多微服務(wù)開源腳手架，它們吸引用戶的方式是將各種功能一股腦地集成進(jìn)去。然而，它們往往只是告訴你“如何集成”卻忽略了“為什么要集成”。

盡管這些開源項(xiàng)目能夠在學(xué)習(xí)微服務(wù)方面事半功倍，但在實(shí)際微服務(wù)項(xiàng)目中，我們不能盲目照搬，而應(yīng)該根據(jù)項(xiàng)目的實(shí)際情況來有選擇地裁剪或擴(kuò)展功能。這樣，我們才能更好地應(yīng)對(duì)項(xiàng)目的需求，避免陷入不必要的復(fù)雜性，從而更加成功地實(shí)施微服務(wù)架構(gòu)。

最后，這個(gè)開源項(xiàng)目你們認(rèn)識(shí)嗎？