1. 程式人生 > >天天吹微服務,單體應用有啥不好?

天天吹微服務,單體應用有啥不好?

單體應用確實有問題!

最近在研究微服務架構,有一點點心得,打算在公眾號上寫幾篇文章和大家慢慢分享下。

這個話題有點大,我會分幾篇文章和大家慢慢說,今天就先來說說傳統的單體應用有哪些弊端,正是因為單體應用存在的弊端,使得我們不得不考慮發展微服務。

人類發展的歷史就是一個社會分工不斷細化的歷史,從這個角度來講,微服務這種將一個複雜的大專案拆分為眾多小專案,然後程式設計師分工合作,共同完成專案,這種協作方式是符合歷史潮流的。

這是我們站在今天的角度來說的,曾經的單體應用也是先進生產力的代表。

但是,隨著網際網路的發展,我們對一個系統的要求越來越高,單體應用已經很難適應當前的開發,因此在回答我們為什麼要使用微服務這個問題之前,我們有必要來聊一聊單體應用目前都面臨哪些問題。

面臨的問題

1.專案過度複雜

你要建立一個簡單的使用者管理系統,二話不說,直接建立 Maven 專案然後開幹就完事了,這沒問題,因為這很簡單。

但是你要說想搞一個淘寶網站,或者你想搞一個用友 U8 系統,那你恐怕就得先慢慢設計系統架構了。單體應用,由於就是一個專案,所有的功能都是寫在一個專案中,不可避免的出現專案過度複雜的情況。而且這種複雜情況會不斷惡化。

有的小夥伴可能有這樣的經驗,剛入職了一家公司,新接手了一個專案,上面催的很急,讓你趕快修復幾個 bug ,專案複雜,光是實體類的包就有好幾個 bean、model、pojo 等,一個專案被很多人經手之後,到你手裡,早已經一團亂麻,你小心翼翼儘量不碰觸到已有的功能,終於修完了幾個 bug,搞了倆禮拜,你覺得這個專案太坑爹了,不想幹了,於是接盤俠從你手裡接到了一個複雜度又上升了一步的專案。

就這樣,一個原本簡簡單單的單體專案,在變複雜的路上一去不復返。

2.開發速度緩慢

單體應用開發速度緩慢,因為單體應用複雜了之後,專案變得異常臃腫而且龐大,每一次編譯構建、執行以及測試,都需要花費大量時間,而且如果測試有問題,又得從頭來一遍,注意,這裡的每一次從頭編譯構建等都是整個專案的從頭編譯構建。

即使你可能只要修改某一個引數,你也得把上面整個流程走一遍,相當於每一次的修改都是牽一髮而動全身的操作。

速度沒法快。

3.不易擴充套件

專案中不同模組對計算機的效能要求不一樣,例如使用 Redis 來儲存了大量的熱點資料,那麼我們希望伺服器的記憶體非常大,另外有一個模組涉及到了圖片處理,我們又希望伺服器的 CPU 非常強,如果是單體應用部署的話,那麼這些條件伺服器都要滿足。

4.技術棧不易擴充套件

單體應用還有一個劣勢就是技術棧不易擴充套件,一旦你選定了某一個技術棧來開發專案,以後很難在技術棧上做切換。有的公司還會自己搞一套系統,這種在當時看起來好像都沒有啥問題,可是經過幾年之後,回頭再看,已經很過時了,很 low 了,當初設計系統的人可能已經離職了,剛入職的新手也不敢動這個老古董,只能在這個老古董上面忍痛開發。

有的時候,有一個服務需要處理高併發,你很想用 Go 語言來做,可是做不到,沒法引入其他語言。

這些都是單體應用的劣勢,如果有微服務,上面這些問題都將得到解決。

曾經的優勢

當然,事物都是有兩面性的,單體應用也有它自己的優勢,例如:

  • 開發簡單,一個 IDE 就可以快速構建出一個單體應用
  • 測試簡單
  • 部署簡單,Tomcat 安裝好之後,應用扔上去就行了
  • 叢集化部署也很容易,多個 Tomcat + 一個 Nginx 分分鐘就搭建好叢集環境了

這麼多優勢,還是難掩劣勢。

不過大家在做專案的時候,還是要結合實際情況來選擇,不能因為微服務厲害,所有專案都是微服務,如果你僅僅只想做一個使用者的增刪改查,那麼很明顯,建立一個簡單的單體應用是最合適的。

好了,本文主要和大家分享了傳統單體應用存在的一些問題,正是因為這些問題,我們需要引入微服務,下篇文章,我們就來看看微服務有哪些優勢。

參考資料:

[1] Chris Richardson.微服務架構設計模式[M].北京:機械工業出版社,2019.

關注公眾號【江南一點雨】,專注於 Spring Boot+微服務以及前後端分離等全棧技術,定期視訊教程分享,關注後回覆 Java ,領取鬆哥為你精心準備的 Java 乾貨!