嗨,大家好,我是飄渺。
最近,我和小伙伴一起接手了一個由外包團隊開發(fā)的微服務(wù)項目,這個項目采用了當(dāng)前流行的Spring Cloud Alibaba微服務(wù)架構(gòu),并且是基于一個“大名鼎鼎”的微服務(wù)開源腳手架(附帶著模塊代碼截圖,相信很多同學(xué)一看就能認出來)。然而,在這段時間里,我受到了來自"外包"和"微服務(wù)"這雙重debuff的折磨。
今天,我想和大家分享一下我在這幾天中遇到的問題。希望這幾個問題能引起大家的共鳴,以便在未來的微服務(wù)開發(fā)中避免再次陷入相似的困境。
絕大部分網(wǎng)上的微服務(wù)開源框架都是基于后臺管理進行模塊拆分的。然而在實際業(yè)務(wù)開發(fā)中,應(yīng)該以領(lǐng)域建模為基礎(chǔ)來劃分子服務(wù)。
目前的服務(wù)拆分方式往往是按照團隊或功能來拆分,這種不合理的拆分方式導(dǎo)致了服務(wù)調(diào)用的混亂,同時增加了分布式事務(wù)的風(fēng)險。
所有服務(wù)都共用同一個數(shù)據(jù)庫,這在物理層面無法對數(shù)據(jù)進行隔離,也導(dǎo)致一些團隊為了趕進度,直接讀取其他服務(wù)的數(shù)據(jù)表。
這里不禁要問:如果不拆分數(shù)據(jù)庫,那拆分微服務(wù)還有何意義?
在項目中存在一個基礎(chǔ)設(shè)施模塊,其中包括文件上傳、數(shù)據(jù)字典、日志等基礎(chǔ)功能。然而,文件上傳功能居然在其他模塊中重復(fù)實現(xiàn)了一遍。就像這樣:
圖片
在項目的基礎(chǔ)模塊中,自定義了許多公共的Starter,并且這些組件在各個微服務(wù)中被全都引入。比如第三方登錄組件、微信支付組件、不明所以的流程引擎組件、驗證碼組件等等……
圖片
圖片
拜托,我們已經(jīng)有自己的SSO登錄,不需要微信支付,還有自己的流程引擎。那些根本用不到的東西,干嘛要引入呢?
這個問題是由上面的問題所導(dǎo)致的,由于引入了一個根本不需要的消息中間件,項目運行時不斷出現(xiàn)如下所示的連接異常。
圖片
項目開發(fā)了這么久,出錯了這么久,居然沒有一個人去解決,真的讓人不得不佩服他們的忍受力。
你看到服務(wù)中這一堆配置文件,是不是心里咯噔了一下?
圖片
或許有人會說:"沒什么問題呀,按照不同環(huán)境劃分不同的配置文件”。可是在微服務(wù)架構(gòu)下,已經(jīng)有了配置中心,為什么還要這么做呢?這不是畫蛇添足嗎?
項目一開始就明確要使用Apollo配置中心,一個微服務(wù)對應(yīng)一個appid,appid一般與application.name一致。
但實際上,多個服務(wù)卻使用了相同的appid,多個服務(wù)的配置文件還塞在了同一個appid下。
更讓人費解的是,有些微服務(wù)又不使用配置中心。
由于項目有眾多參與的團隊,為了聯(lián)調(diào)代碼,開發(fā)人員在啟動服務(wù)時不得不修改配置文件中Nacos的spring.cloud.nacos.discovery.group
屬性,同時需要啟動所有相關(guān)服務(wù)。
這導(dǎo)致了兩個問題:一是某個用戶提交了自己的配置文件,導(dǎo)致其他人的服務(wù)注冊到了別的group,影響他人的聯(lián)調(diào);二是Nacos注冊中心會存在一大堆不同的Group,查找服務(wù)變得相當(dāng)麻煩。
其實要解決這個問題只需要重寫一下網(wǎng)關(guān)的負載均衡策略,讓流量調(diào)度到指定的服務(wù)即可。據(jù)我所知,他們使用的開源框架應(yīng)該支持這個功能,只是他們不知道怎么使用。
使用的開源腳手架支持Dubbo協(xié)議和OpenFeign調(diào)用,然而在我們的項目中并不會使用Dubbo協(xié)議,微服務(wù)之間只使用OpenFeign進行調(diào)用。然而,在對外提供接口時,卻暴露了一堆支持Dubbo協(xié)議的接口。
項目部署到Kubernetes云環(huán)境,一般來說,服務(wù)部署到云上的內(nèi)部服務(wù)應(yīng)該使用ClusterIP的方式進行部署,只有網(wǎng)關(guān)服務(wù)需要對外訪問,網(wǎng)關(guān)可以通過NodePort或Ingress進行訪問。
這樣做可以避免其他人或服務(wù)繞過網(wǎng)關(guān)直接訪問后端微服務(wù)。
然而,他們的部署方式是所有服務(wù)都開啟了NodePort訪問,然后在云主機上還要部署一套Nginx來反向代理網(wǎng)關(guān)服務(wù)的NodePort端口。
網(wǎng)絡(luò)上涌現(xiàn)著眾多微服務(wù)開源腳手架,它們吸引用戶的方式是將各種功能一股腦地集成進去。然而,它們往往只是告訴你“如何集成”卻忽略了“為什么要集成”。
盡管這些開源項目能夠在學(xué)習(xí)微服務(wù)方面事半功倍,但在實際微服務(wù)項目中,我們不能盲目照搬,而應(yīng)該根據(jù)項目的實際情況來有選擇地裁剪或擴展功能。這樣,我們才能更好地應(yīng)對項目的需求,避免陷入不必要的復(fù)雜性,從而更加成功地實施微服務(wù)架構(gòu)。
最后,這個開源項目你們認識嗎?
本文鏈接:http://www.tebozhan.com/showinfo-26-74663-0.html接手外包團隊開發(fā)的微服務(wù)項目,我感覺我的頭快要裂開了
聲明:本網(wǎng)頁內(nèi)容旨在傳播知識,若有侵權(quán)等問題請及時與本網(wǎng)聯(lián)系,我們將在第一時間刪除處理。郵件:2376512515@qq.com