我們有兩種方式可以拆分服務,第一種我們的系統分為買家端和賣家端,你可以把vue放到app上,用來做買家端需要的接口,賣家端呢,也就是PC端,由freemark做的html頁面作為另外一個邊緣服務,兩端同時向后端的通用服務請求數據,等同于就是手機端和PC端,直接來劃分,第二種你可以把訂單UI,邊緣服務里面,商品和支付你可以把它單獨放到一個邊緣服務里面,等于UI是按照業務來,不是按照終端來劃分了,那么這兩種拆分的方式,哪一種才是正確的呢,大家趕緊選一個,心理面想一個,第一種還是第二種,正確是這兩種都不對,可能最長的路就是師兄的套路了,那我們來看一下為什么說不對,如果點餐項目就是我自己的小店,BOSS是我,開發人員是我,小二還是我,我上線了自己的微信點餐,每天賣個100、80萬,月入幾萬塊,小日子過得挺滋潤,這個時候有個人跑過來跟我說,你這個小餐系統可以微服務化,要微服務拆分,那我肯定會當場拒絕他,沒拆分的必要,團隊迭代變化也不大,搞成微服務,部署上就麻煩很多,果斷拒絕,現在我們是一個快速發展的IT點餐部門了,業務現在快速增長,需求不斷提出,確實需要微服務化了,我們應該審視一下,比如當前公司技術人員的技術棧,看看前端技術人員的水平,是不是適合將UI這一部分,單獨拆成一個微服務,由2前端的同志們,單獨維護,比如前端團隊精通Node.js,但是團隊人數也不是那么多,那就可能傾向于單獨獎Vue APP,接口部分拆分成一個單獨的服務,傾向于第一種方案,那如果是服務增長異常迅速,不論是訂單,支付,廣告商品,各種業務增長都特別特別的快,前后端開發人員,在公司里面也特別充足,那就可能根據業務分成多個小組,一個小組負責一個微服務,有自己單獨的前端人員,那么第二種拆分方法,可能會是個更好的選擇,所以起點和團隊結構,溝通方式,是真的會影響你在軟件上的趨勢

我們來聊聊具體的方法論,首先這是我比較喜歡的擴展立方模型,他出自一本書,叫做可擴展的藝術,大家有興趣的話可以去看看,講的是三維伸縮性模型,X軸水平復制,就是通過副本擴展,將應用程序水平復制,通過負載均衡復制一樣的應用的方式,來實現應用程序的伸縮性,提高應用程序的容量,和可用度,Z軸呢,是將按數據分區,簡單點說,就是每個服務器,負責一個數據子集,每個服務器運行的代碼是一樣的,伸縮性的第三個維度,是針對功能性分解的,Y軸伸縮,就是將不同職責的模塊,分成不同的服務,通過這個模型,我們很自然的能夠理解,服務拆分的兩個關鍵地方,功能和數據

先來聊聊拆功能,拆功能的首要原則就是,貫徹單一職責,每一個服務只負責單獨的一個部分,要讓服務松耦合,高內聚,松耦合就是服務之間耦合度低,修改一個服務不要導致另外一個服務跟著修改,高內聚指的是服務內部,相關的行為都聚集在一個服務內,而不是分散在不同的服務中,這樣修改一個行為時,只要修改一個微服務即可,劃分服務的時候,用這個條件去驗證,服務劃分是否合理,如果修改了一個行為,多個服務都要動,就是應該當初劃分不合理導致的,第二點,是關注點分離,講到關注點分離,可能很多人聽說過界限上下文,界限上下文呢,是來自領域驅動設計一書,是微服務火起來后的一個復蘇經典理論,他完全值得一個專題去學習,我個人對領域驅動設計理解的不是特別深,所以這里只聊聊關注點分離,關注點分離的基本方法有,按職責分離關注點,按通用性分離關注點,按粒度級別分離關注點,按職責分離可以理解成,比如我們的服務,進行分類,比如明顯的,按業務領域可以劃分出來的服務,職責比較單一,比如訂單,商品,還有比如網站的前端服務,APP的服務接口,這些很明顯可以,按通用性分離,是指一些基礎組件,與具體的業務無關的,也可以劃分出來做為一個單獨的服務,比如消息服務,用戶服務,同時前面說的業務劃分出來的服務,我們也應該將其不同模塊,或者組件進行拆分,比如把公共組件,拆分成獨立的原子服務,形成相對獨立的原子服務層,最后我們要考慮服務的粒度,微服務并不是越小越好,他的粒度不是一個好把握的點,比如我點單里面有一個訂單服務,初期他比較合適,后來隨著業務增大,他的功能增加,會導致他變得非常胖,很有可能需要我們再次拆分,拆分成訂單服務,和支付服務,兩個服務,拆分功能和拆分數據,是有先后順序的,應該先考慮拆分其業務功能,再考慮拆分業務功能對應的數據,第二點,是無狀態服務

先說一下什么是狀態,如果一個數據需要被多個服務共享,才能完成一個請求,那么這個數據就可以稱為狀態,進而依賴這個狀態數據的服務,被稱為有狀態服務,反之稱為無狀態服務,無狀態服務并不是說,在微服務架構里面,不允許這種狀態,而是要把有狀態的業務服務,改變成為無狀態的服務

比如我們以前在本地內存中,建立的數據緩存,Session緩存,到現在微服務架構中,就應該把這些數據,遷移到分布式緩存中,讓業務服務,變成一個無狀態的Session節點,就可以按需動態伸縮,在運行時,動態增刪節點,不用再考慮緩存數據如何同步的問題

基于以上我們先整體來分析一下,點餐業務的功能,原始的點餐業務,買家部分的前端UI,是Vue APP,他通過API接口,向后端SpringBoot服務,請求數據,數據對應的功能,有以下一些,有商品的,訂單的,可以下單和查詢訂單,廣告的,有店鋪的介紹之類,還有用戶的,買家用戶注冊之類,還有支付,原始的是微信支付,根據業務發展,會很自然的想到,支付你以后會接入其他的支付,比如像支付寶,銀聯,賣家部分的前端UI,原始是freemarker提供的模板引擎,渲染而成,后端功能部分,包括以下幾個方面,有商品的,對商品更細粒度的查詢,同時還有增刪改查,用戶的賣家登陸,還有支付,各種支付渠道的后端邏輯,如果要改成微服務架構呢,比如這門課的講師是我,我就以自身的特點,假設我公司的這個組,都是4個到6個,我這個水平的人,這個水平有什么特點呢,就是JAVA后端比較熟悉,在業務方面掌握的馬馬虎虎,那我傾向的方法是,業務APP作為一個單獨的服務,放到Nginx上,原始賣家端UI,就是除去支付UI以外,單獨成為一個單獨服務,而訂單用戶,商品等等,成為獨立的后端服務,就是商品服務和訂單服務,放置在Nginx上的Vue APP,所需要的接口提供數據,也能提供賣家端UI,邊緣服務提供數據,而支付服務由于他的特點,他還包含UI,當前UI和原始業務,建在一起還是一個服務,這有利于他增加支付渠道,如果是放在另外一個環境下呢,比如是在一個業務高速發展的背景下,點餐服務目測的業務擴展,很可能新增的功能,可以來分析一下,比如短信服務,日志服務,積分服務,優惠券服務,那其中比如短信這種,很明顯是和具體的業務無關的,這種服務通常會作為基礎服務,單獨抽取出來,供其他服務調用,同樣類似的比如消息系統,用戶這些是很合適稱為基礎服務,還有比如Redis緩存這一塊,很多公司會對Redis抽取作為一個單獨的服務,在現實中,一個公司的一個小組,不可能去負責所有微服務的實現,讓你去實現的微服務,肯定是有限的,在開展微服務的時候呢,不要妄圖一步到位,我前面強調過,好的架構不是設計出來的,是演進而來的,而且演進一直在持續,很多小伙伴看書看微服務案例,只看到微服務架構的演進結果,主觀或者客觀的忽略了,演進過程,所以正確的做法應該是,快速出一個微服務,微服務就是要低成本,低風險的漸進式演進,所以要一直看一直設計,要用于面對失敗,快速的放到生產環境中,去面對真實的問題,在這個點餐業務中,我們快速選定一到兩個有聯系的服務,確定他的場景,要解決的問題,以及要達到的效果,然后就應該速度開發,快速試錯,不要企圖服務劃分一次就能正確,他就是一個持續權衡取舍的過程,在這里我們先選定商品服務和訂單服務,因為這兩個服務是點餐的核心服務,同時他們之間有調用關系,可以很好地實踐,同時它也應用于我們后面要講的服務間的通信,接下來我們將商品和訂單業務,實現起來,在后續講API網關的章節里,我們會引入另外一個用戶服務,希望對SpringBoot的基本使用是熟練的,我會快速的實現基本功能,對咬實現的業務有一定的了解

?

總結

以上是生活随笔為你收集整理的点餐业务服务拆分分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。