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