單體應用確實有問題！
最近在研究微服務架構，有一點點心得，打算在公眾號上寫幾篇文章和大家慢慢分享下。
這個話題有點大，我會分幾篇文章和大家慢慢說，今天就先來說說傳統的單體應用有哪些弊端，正是因為單體應用存在的弊端，使得我們不得不考慮發展微服務。
人類發展的歷史就是一個社會分工不斷細化的歷史，從這個角度來講，微服務這種將一個複雜的大專案拆分為眾多小專案，然後程式設計師分工合作，共同完成專案，這種協作方式是符合歷史潮流的。
這是我們站在今天的角度來說的，曾經的單體應用也是先進生產力的代表。
但是，隨著網際網路的發展，我們對一個系統的要求越來越高，單體應用已經很難適應當前的開發，因此在回答我們為什麼要使用微服務這個問題之前，我們有必要來聊一聊單體應用目前都面臨哪些問題。
面臨的問題
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 乾貨！
