1. 案例介紹

1.1 需求

實(shí)現(xiàn)?個(gè)電商平臺(tái)(不真實(shí)實(shí)現(xiàn), 僅為演?)

?個(gè)電商平臺(tái)包含的內(nèi)容?常多, 以京東為例, 僅從??上就可以看到巨多的功能

我們?cè)撊绾螌?shí)現(xiàn)呢? 如果把這些功能全部寫在?個(gè)服務(wù)?, 這個(gè)服務(wù)將是巨?的.

巨多的會(huì)員, 巨?的流量, 微服務(wù)架構(gòu)是最好的選擇.

微服務(wù)應(yīng)?開發(fā)的第?步, 就是服務(wù)拆分. 拆分后才能進(jìn)?"各?開發(fā)"

1.2 服務(wù)拆分

服務(wù)拆分原則

微服務(wù)到底多?才算"微", 這個(gè)在業(yè)界并沒有明確的標(biāo)準(zhǔn). 微服務(wù)并不是越?越好, 服務(wù)越?, 微服務(wù)架構(gòu)的優(yōu)點(diǎn)和缺點(diǎn)都會(huì)越來越明顯.

服務(wù)越?, 微服務(wù)的獨(dú)?性就會(huì)越來越?, 但同時(shí), 微服務(wù)的數(shù)量也會(huì)越多, 管理這些微服務(wù)的難度也會(huì)提?. 所以服務(wù)拆分也要考慮場(chǎng)景

拆分微服務(wù)—般遵循如下原則:

1. 單?職責(zé)原則

單?職責(zé)原則原本是?向?qū)ο笤O(shè)計(jì)中的?個(gè)基本原則, 它指的是?個(gè)類應(yīng)該專注于單?功能. 不要存在多于?個(gè)導(dǎo)致類變更的原因.

在微服務(wù)架構(gòu)中, ?個(gè)微服務(wù)也應(yīng)該只負(fù)責(zé)?個(gè)功能或業(yè)務(wù)領(lǐng)域, 每個(gè)服務(wù)應(yīng)該有清晰的定義和邊界, 只關(guān)注??的特定業(yè)務(wù)領(lǐng)域.

組織團(tuán)隊(duì)也是, ?個(gè)?專注做?件事情的效率遠(yuǎn)?于同時(shí)關(guān)注多件事情.
?如?個(gè)?同時(shí)管理和維護(hù)?份代碼, 要?多個(gè)?同時(shí)維護(hù)多份代碼的效率?

?如電商系統(tǒng)

2. 服務(wù)?治

服務(wù)?治是指每個(gè)微服務(wù)都應(yīng)該具備?度?治的能?, 即每個(gè)服務(wù)要能做到獨(dú)?開發(fā), 獨(dú)?測(cè)試, 獨(dú)?構(gòu)建, 獨(dú)?部署, 獨(dú)?運(yùn)?.

以上?的電商系統(tǒng)為例，每?個(gè)微服務(wù)應(yīng)該有??的存儲(chǔ), 配置，在進(jìn)?開發(fā), 構(gòu)建, 部署, 運(yùn)?和測(cè)試時(shí)，并不需要過多關(guān)注其他微服務(wù)的狀態(tài)和數(shù)據(jù)

?如企業(yè)管理

每個(gè)部分負(fù)責(zé)每個(gè)部?的事情, 并且盡可能少的受其他團(tuán)隊(duì)影響
研發(fā)部?只負(fù)責(zé)需求功能的開發(fā), ?不負(fù)責(zé)需求?檔的書寫和UI的設(shè)計(jì). 并且其他部?的?員變動(dòng), 流程變更, 也盡可能少的影響研發(fā)部?. 部?和部?之間盡可能?治.

3. 單向依賴

微服務(wù)之間需要做到單向依賴, 嚴(yán)禁循環(huán)依賴, 雙向依賴

循環(huán)依賴: A -> B -> C ->A
雙向依賴: A -> B, B -> A

如果?些場(chǎng)景確實(shí)?法避免循環(huán)依賴或者雙向依賴, 可以考慮使?消息隊(duì)列等其他?式來實(shí)現(xiàn)

服務(wù)拆分?例

?個(gè)完整的電商系統(tǒng)是龐?的, 當(dāng)然這也不是咱們課程的重點(diǎn), 咱們課程中重點(diǎn)關(guān)注如何使?SpringCloud解決微服務(wù)架構(gòu)中遇到的問題.

以訂單列表為例:

簡(jiǎn)單來看, 這個(gè)??提供了以下信息:

1. 訂單列表
2. 商品信息

根據(jù)服務(wù)的單?職責(zé)原則, 我們把服務(wù)進(jìn)?拆分為: 訂單服務(wù), 商品服務(wù)

訂單服務(wù): 提供訂單ID, 獲取訂單詳細(xì)信息

商品服務(wù): 根據(jù)商品ID, 返回商品詳細(xì)信息.

2. 項(xiàng)目搭建

步驟圖示
見我的 gitee 倉(cāng)庫(kù)代碼