最近，筆者和小夥伴一起接手了一個由外包團隊開發的微服務計畫，這個計畫采用了當前流行的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
來源丨公眾號：JAVA日知錄 （ID：javadaily）
dbaplus社群歡迎廣大技術人員投稿，投稿信箱： [email protected]
