什麼是微服務?為什麼使用微服務?

在講解SpringCloud之前 我們必須要談論一個重要的內容,到底什麼是微服務,想必大家在網上查詢之後有海量的答案讓人眼花繚亂,所以在這裡我們就先一起探討一下微服務到底是什麼神奇的東西.

可能大多數的java程式猿做的專案都是xxxx管理系統,xxxxCRM系統,這些專案只是針對某一個公司或者部門開發,使用者量也不會很大(我們家樓下的理髮店都有一個管理系統 使用者只有店長和幾個洗髮的韓潮小哥),千篇一律的CRUD逐漸的讓大家覺得甚是無聊,偶爾可能接幾個畢設來貼補家用,我相信所有的程式猿都聽說過微服務,但是不是每一個人都接觸過微服務,即使沒有接觸過利用空閒的時間來學習學習也是不錯的.

話不多說切入正題,單體架構的專案相信大家在學習或者工作的階段都是開發過的,當大家完成了一個單體架構後想必也會有幾分成就感,但是不要讓一時的成就感矇蔽了你的雙眼,要知道單體架構的問題遠比你想象的多.

• 單體架構的幾個重要問題

  複雜度的提升: 你永遠不知道客戶的需求有多麼奇葩,你也永遠不會知道你的上一任會給你留下多少的技術債務,一個類中寫幾千幾萬行程式碼的時候,我們就有一種想kill人的衝動,想重構程式碼又害怕會影響整個專案,只能硬著頭皮繼續往下寫,這是一個惡性迴圈,我們只能祈禱不要做壓死駱駝的最後一根稻草.

  專案部署: 不是所有的團隊都有運維人員,基本上小公司的開發人員不光要開發程式碼還要部署專案,我承認這對程式設計師來說是一件好事,可以學習到更多的東西,但是當代碼量越發龐大,專案的部署就會越來越慢,朋友公司每天只能有一次部署機會,因為部署一次需要5個小時,第一次程式碼沒有寫好那麼只能加班了.

  技術障礙: 隨著現在技術的更新越來越快,很多老闆聽說了一個什麼新的技術好像不錯就想讓自己的員工來嘗試一下,技術選型應該是我們開發人員集體研討的結果,但是若沒有很好的前瞻性,在未來的日子裡想要改造專案那簡直就是噩夢,這時候我們的心聲是重新寫一個吧,肯定比改造要快很多

  問題排查: 高內聚低耦合是我們常說的話,但是原本想遵循這個原則但是程式碼寫著寫著就變了味道,到後來想著只要能完成需求就行了,這個時候面對如此高複雜度的專案排查問題就好比上演了一部偵探破案的懸疑劇.我承認改bug是自我提升的一個方式,但是誰也不想天天改那些詭異的bug.

單體結構雖說有很多的問題,但是對於業務不是很複雜,使用者量沒有過高要求的簡單小專案還是建議使用的,若是龐大複雜的業務邏輯以及海量的使用者群體,那麼微服務可以很好的解決以上問題.

到底什麼是微服務? 通俗的講就是把原來單體結構的專案拆分成一個一個的獨立模組,單獨執行
這就好比是搭積木,每一塊積木是一個模組,各個模組連在一起是整個專案

微服務架構是一種將單應用程式作為一套小型服務開發的方法，每種應用程式都在其自己的程序中執行，並與輕量級機制進行通訊。這些服務是圍繞業務功能構建的，可以通過全自動部署機制進行獨立部署。這些服務的集中化管理已經是最少的，它們可以用不同的程式語言編寫，並使用不同的資料儲存技術。(這句話是我copy的