很久很久之前我聽說了SOA，我不知道這是幹嘛的；很久之前我聽說了微服務架構，我又不知道這是幹嘛的。我就一直在問我自己現在的項目架構很落伍麼，我怎麼感覺它還是能滿足我的需求的呢；新的架構能解決我的什麼痛點，他們提到的現有的架構的缺點我沒有感覺到，他們提到的新框架的優點我也不以爲然。想了好久之後，我突然明悟：我的項目不適合這個架構。
先說結論：微服務結構爲大型項目（幾十個人、幾十萬行代碼）或多技術架構而生
微服務架構：微服務架構是一種架構模式，它提倡將單一應用程序劃分成一組小的服務，服務之間互相協調、互相配合，爲用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間採用輕量級的通信機制互相溝通（通常是基於HTTP協議的RESTful
API）。每個服務都圍繞着具體業務進行構建，並且能夠被獨立的部署到生產環境、類生產環境等。另外，應當儘量避免統一的、集中式的服務管理機制，對具體的一個服務而言，應根據業務上下文，選擇合適的語言、工具對其進行構建 （馬丁
-福勒）
優點：1）易於維護：拆分成小的服務之後，業務變得純粹，新功能開發、缺陷定位修復較簡單。
2）縮短交付週期短：不會因其他的業務或需求而影響本服務的交付。
3）新人培養週期短：新人來後，第一時間瞭解和參與項目是很重要的，而一個較小的服務則在代碼或業務邏輯上都易於理解和部署。
4）技術選型靈活：我們現有的一種主流語言可以解決絕大部分的需求，但是並不是百分百；現在日益湧現的新技術也證明了他們的價值，在一箇舊有項目上應用新技術，應用的大小就成了關鍵所在。
微服務結構的優點都來自於服務的拆分，那麼另一方面，拆分的缺點也是微服務的缺點：
缺點：1）運營麻煩：體驗過維護很多個項目的人都瞭解部署很多個應用的麻煩
2）基礎共用性：項目的簡單與否在於是否有紮實的基礎。分成很多個應用之後，基礎的共用便是一個很大的問題。
3）拆分依據：即使滿足上面的條件，拆分仍然是一個很大的難點，只懂理論是無法解決現實中遇到的各種各樣的拆分問題的。不合理的拆分會讓上面的優點都變成缺點。
爲什麼我的項目不適合微服務結構：
1）技術單一：我的項目屬於偏業務型系統，技術比較單一（正在積極採用新的、更合適的技術）
2）項目較小：一個業務線項目的日常維護和開發人員不到五個，可想項目有多簡單
所以，對於我這種簡單的項目，微服務架構是沒有什麼用武之地的。
所以，再說一遍，微服務結構有用，但是是爲大型項目（幾十個人、幾十萬行代碼）或多技術架構而生