springcloud微服務架構搭建（微服務是什麼）

2023-10-04 04:35:58

一個系統會劃分前端與後端，前端是用戶看到的，可操作的可視化界面。後端是用戶看不到的，負責處理業務邏輯，數據存儲的。

在系統發展的早期，我們一般都是以單體模式出現。

單體模式優點：

隨著需求越來越多，功能越來越複雜，單體模式的弊端就會暴露出來了。

單體模式缺點：

由於單體模式長遠來看明顯弊大於利，所以程式設計師就開始思考如何有規劃的寫代碼。

MVC全名是Model View Controller，是模型(model)－視圖(view)－控制器(controller)的縮寫，一種軟體設計典範，用一種業務邏輯、數據、界面顯示分離的方法組織代碼。

MVC是從代碼意義的層面出發，將代碼分為了負責調度用的Controller控制器、負責業務邏輯和資料庫處理的Model模型、負責最終數據呈現的View視圖三部分。

相對於最開始的「一鍋粥」的混沌狀態，現在代碼間有了一些邊界，程式設計師分工、代碼定位也更清晰了。

MVC解決了代碼內部管理的不少問題，但是從整個系統的視角來看，依然是一個單體。隨著業務規模越來越大，某幾個功能的流量可能佔用了伺服器絕大部分資源，於是就產生了兩個問題：

聰明的程式設計師就想到，把關鍵的業務邏輯和主系統剝離開來，形成獨立的模塊，這樣關鍵邏輯就能單獨運作，不受系統其它邏輯故障的影響。當該模塊用戶量多的時候，還可以把模塊多複製幾份同時運行，這樣其中一個模塊不幸掛了，那麼其他模塊還能接替他繼續運作。

把多個模塊放在同一臺服務上，並沒有解決伺服器處理能力極限的問題，於是就找老闆要為這臺伺服器升級配置，結果一出價格，嚇得老闆直哆嗦。

配置提高一點，價格就高了很多，花同樣的錢能買好幾臺原來配置一樣的機器。如果改成買多幾臺機器，然後想辦法讓這些機器處理能力能疊在一起，性能還可以遠超升級的配置。

於是就有了分布式的誕生，多買幾臺幾臺伺服器，讓他們同時工作。伺服器還可以選擇部署在全國不同的地方，實現了用戶的就近區域訪問，讓不同地區用戶都能享受最佳的訪問速度。

分布式的架構看似幫程式設計師們解決了很多的問題，但是新的問題又隨之而來：

微服務的到來，就為這些問題打開了新思路

微服務架構是一種架構模式，它提倡將單一應用程式劃分成一組小的服務，服務之間互相協調、互相配合，為用戶提供最終價值。每個服務運行在其獨立的進程中，服務與服務間採用輕量級的通信機制互相協作（通常是基於HTTP協議的RESTful API）。每個服務都圍繞著具體業務進行構建，並且能夠被獨立的部署到生產環境、類生產環境等。

微服務中有幾個關鍵啟：

馬爾文·康威1967提出的：「設計系統的架構受制於產生這些設計的組織的溝通結構。」通俗的來講：產品必然是其（人員）組織溝通結構的縮影。

微服務其實是對模塊化和分布式的一種升級。

首先，後端增加了統一的「門面」——網關。

有了網關之後，前端就不需要知道眾多的服務他們分布在哪裡，只需要請求網關，由網關將需求傳遞到相應的服務中。網關還能自動幫前端找到最快且穩定的服務節點，讓前端體驗更勝一籌。

諸多的服務分散在不同的地方，為了將這些服務組織管理起來，知道他們用途、狀態信息，避免後續發展成一共有多少個服務都無法統計，就誕生了服務池的「管理機構」。所有服務都必須在管理機構內註冊登記、及時上報自身情況。

稍微複雜點的功能，都需要多個服務互相配合才能完成的。

單體模式時代，由於只有一套系統，程式設計師順藤摸瓜就能找到bug出在哪。現在存在多個獨立的服務，程式設計師必須每個服務逐一排查故障，這就讓找bug根源問題變得非常困難，於是就需要一套故障追蹤機制，記錄前端請求在後端實現的全鏈路，以便發現問題出在哪。

為了讓程式設計師可以更好將系統架構向微服務遷移，於是就衍生出了微服務的代碼框架，其中比較出名的方案有SpringCloud、Dubbo兩家，我們來簡單看看他們他們的官方示例圖。

從SpringCloud的架構中不難看出微服務的相對於原有的分布式架構的新特徵：

微服務不是某種新技術，更像是技術架構的一種新思想，一種正在不斷迭代的、用業務的思想解決技術問題的思路。業務驅動下產生的微服務，無疑讓寫代碼這件事變得更具挑戰性，但卻讓程序更能直接表達其價值，能讓企業的業務更好、更快的發展。

當我們討論產品方案時，都不能脫離業務，業務是需求最重要的根源，那到底什麼是業務呢？

從詞語定義來說，業務是指某個行業或者某個職務所做的事情，就叫做「業務」，其參與者是人，未來也可能是電腦、機器（AI、自動化），其目的滿足行業、職務的服務對象的需要。

業務方在工作過程中，為了實現更高的產能、獲得更高的回報，就會想辦法去優化整個業務流程，這就產生了「需求」。只要業務想發展、在發展，需求就會源源不斷的產生。

產品經理接觸的需求來源，外部是業務的服務對象：用戶；內部則是業務的執行方：老闆、運營、商務、財務、法務、供應商等。業務方將需求告知產品經理，產品經理經過調研論證，將需求轉換為產品方案，輸出可以滿足業務需求的產品需求文檔、原型。

然後，產品將功能的需求提給研發人員，研發最終將這些功能得以實現，於是系統誕生了。業務方使用系統，不斷發展擴大，產生更多的新需求，於是以此往復，形成業務-產品-研發的需求鏈條閉環。

在這個鏈條閉環裡，業務形態、流程決定了系統最終的形態，而系統形態則推動業務的發展。產品是連接業務與系統的紐帶，技術並不是在瞎逛，而是根據產品的需求去研發系統，技術研發出來的系統會最終決定業務未來的走向。

服務是技術讓代碼更適應業務發展的產物，是業務驅動下的產物。

微服務的概念需要程式設計師更了解業務的板塊劃分和發展方向，代碼要隨著業務的不斷成熟，按照業務結構進行模塊化、服務化，才能方便業務的發展壯大，這就要求程式設計師要「懂點產品」。

如果程式設計師一味的按照純粹的技術方案或者自己拍腦袋定的方向做，那隨著業務的迭代發展，很容易出現「這個需求做不了」的問題，因為代碼被技術方案禁錮住了，無法適應業務的發展，如果要解決，可能就要重構，時間、人力成本將居高不下。

業務驅動的過程，不是一個「理想」、「理性」的過程，代碼講究的是邏輯，是要「不出bug」、「跑得起來」，但是業務的發展是用戶、市場需求不斷積累的一個過程，很多需求可能是很主觀的，甚至有時候是「靈光一閃而過」的。需求存在不確定性，這就讓程式設計師犯難了，那到底要不要按照這個方向做呢？萬一做了用不上要推倒重來怎麼辦？

這時候就體現出了產品經理與技術人員的協調作用，以及對現有業務架構的劃分、對新需求的判斷和歸類，這將直接影響微服務的架構模塊。

也就是說在微服務架構下，業務人員不只要懂業務，還要懂點技術；技術人員不只要懂技術，還要懂點業務。

百度複製過來的藍圖，僅參考

產品藍圖和功能架構圖十分相似？其實表現上差不多，但是產品藍圖還包含了對整套系統的發展方向預期，裡面的很多模塊可能處於「會有的」狀態，隨著業務的發展不斷補全。

有了產品藍圖後，新需求就可以很方便的進行歸類，做版本規劃時也可以看得出距離預期目標還有哪些沒有實現的地方，然後進行補齊。

更重要的是，產品藍圖作為產品設計方向的指導作用，能讓技術對產品未來的完整形態一目了然，然後再進行以業務為驅動的代碼服務化，這樣就能讓代碼能適應更長遠的發展需要，避免盲目設計導致最終影響業務發展、需要推倒重來。

通過產品藍圖、產品規劃，產品經理能讓技術了解整個業務的未來發展方向，讓技術可以更熟悉產品，知道「為什麼這麼做」、「以後還要做什麼」，這樣在寫代碼的時候可以更有方向的做兼容。

微服務其實是技術、產品的目標一致化的必然結果，大家都以如何更好的發展業務去進行工作。

產品經理可以不需要深入了解微服務下各種配套的機制、利弊的問題，但需要知道，微服務其實是產品架構在代碼層的映射、體現。

一個好的產品架構，將有利於技術框架的成型和發展，反之一個模糊不清、結構混亂的產品架構，將會讓技術也無從下手，只能頭痛醫頭的解決眼前的需求，無法從代碼層面做長遠的兼容、發展考慮。

所以我的觀點是，微服務是技術架構適應業務發展的一個過程，如果從技術的工作上看，讓代碼順應業務的發展其實是個大難事，關愛程序猿人人有責。而產品經理雖然不需要知道微服務的技術細節和實現方法，但應該更多的強化自己的產品能力，多將業務發展方向的事情與技術同事聊聊、科普一下，有利於技術架構更好的發展。