建站
咨詢
售后
建站咨詢
新聞中心
本文轉(zhuǎn)載自微信公眾號「腦子進(jìn)煎魚了」，作者陳煎魚。轉(zhuǎn)載本文請聯(lián)系腦子進(jìn)煎魚了公眾號。
大家好，我是煎魚。
我有一個(gè)好朋友小咸魚，他們組織早期是業(yè)務(wù)萌芽的初期，在快速發(fā)展階段，面臨著軟件開發(fā)周期的挑戰(zhàn)。
過去的巨石應(yīng)用
這 “強(qiáng)大又厚實(shí)” 的巨石應(yīng)用是他們應(yīng)用架構(gòu)上的一個(gè)早期策略：
但隨著業(yè)務(wù)的持續(xù)發(fā)展，巨石應(yīng)用的痛點(diǎn)也非常明確。像是：
- 難以部署和維護(hù)。
- 頻繁部署的障礙。
- 不相關(guān)的功能之間的依賴性。
- 難以嘗試新的技術(shù)/框架。
這些痛點(diǎn)也正給他們公司帶來各種各樣的組織問題，而當(dāng)代微服務(wù)的橫空出世，對軟件工程師很有吸引力，他們也就轉(zhuǎn)型了。
現(xiàn)代的微服務(wù)架構(gòu)
正式邁向了微服務(wù)轉(zhuǎn)型之路，一切先從拆分開始：
在以往的大單體中，我們會將其 Cache、DB 等混合在遺愛。但在做微服務(wù)后，我們會選用拆成多個(gè)服務(wù)的方式，最終演變成：
微服務(wù)拆分有以下幾種粗的基準(zhǔn)：
- UI、靜態(tài)內(nèi)容組件化，解耦出來成為可獨(dú)立部署的客戶端應(yīng)用。
- 定義邊界，服務(wù)要有較為明確清洗的邊界。
- 單一職責(zé)，服務(wù)的能力要單一，數(shù)據(jù)庫等第三方依賴存儲要獨(dú)立。
絞殺者模式
在完成微服務(wù)改造的基準(zhǔn)的定義后，絕大部分公司都是采取業(yè)界中比較著名的 “絞殺者” 模式。
如下圖：
由于會考慮微服務(wù)的組織，大多都是有成熟業(yè)務(wù)的盈利組織了，業(yè)務(wù)發(fā)展太迅猛，才發(fā)現(xiàn)技術(shù)架構(gòu)跟不上業(yè)務(wù)要求的迭代速度和周期，不大可能停下業(yè)務(wù)硬重構(gòu)。
因此業(yè)內(nèi)基本采取邊遷移，邊改造為微服務(wù)的漸進(jìn)式重構(gòu)的方式，實(shí)現(xiàn) “絞殺者”，把技術(shù)債務(wù)給償還了。
服務(wù)太小
在微服務(wù)逐步的演進(jìn)過程中，我們就會發(fā)現(xiàn)一個(gè)新的問題。雖然在微服務(wù)做規(guī)劃時(shí)，都會很認(rèn)真的對服務(wù)的拆分進(jìn)行深入研討，但還是出現(xiàn)了服務(wù)拆的很爽，但后面實(shí)戰(zhàn)的時(shí)候發(fā)現(xiàn)服務(wù)太小了。
N 人維護(hù)數(shù)倍服務(wù)
出現(xiàn)了 “10 名工程師組成了維護(hù) 60 項(xiàng)服務(wù)的小組。一人負(fù)責(zé)一個(gè)服務(wù)還不夠用” 的情況。
正當(dāng)以為這不是常見問題時(shí)，最近看到我的好朋友 HHF(@HHFCodeRv)提到有人向他咨詢架構(gòu)相關(guān)的問題。
下面是咨詢他的公司的 Java 架構(gòu)師落地的方案。如下圖：
亮點(diǎn)是這 2 個(gè)后端開發(fā)，其中一個(gè)還是架構(gòu)師。結(jié)合實(shí)際情況，可能只有 1 個(gè)后端在干活。這堪稱 1:17 的人和服務(wù)的配比量，每天光切 IDE 找服務(wù)可能就得好幾東...
當(dāng)然，應(yīng)用還沒上線，就拆成數(shù)倍的服務(wù)。形成 N 個(gè)人維護(hù)其自身數(shù)量的數(shù)倍服務(wù)，不大合理。這也是業(yè)內(nèi)很多互聯(lián)網(wǎng)公司需要思考和解決的問題。
新功能歸屬誰
在實(shí)際的業(yè)務(wù)場景中，出現(xiàn)了 “有人要求我把一個(gè)新功能同時(shí)部署到兩個(gè)不同服務(wù)之中” 的訴求。
因?yàn)檫@個(gè)新功能同時(shí)是 ServiceA 和 ServiceB 這兩個(gè)服務(wù)的職責(zé)劃分的所有者或者部分所有者，所以新功能理應(yīng)同時(shí)在這兩個(gè)服務(wù)都要有所提供。
這時(shí)候需要考慮以下問題：
- 這個(gè)新功能是什么，具體的業(yè)務(wù)領(lǐng)域劃分?
- 為什么這兩個(gè)服務(wù)會存儲共享這一個(gè)新功能的可能?
- 這兩個(gè)服務(wù)，是否應(yīng)該繼續(xù)拆開，要不要合并?
- 由于新功能的出現(xiàn)，是不是應(yīng)該拆出第三個(gè)服務(wù)?
在真實(shí)的項(xiàng)目場景中，我們會按照事前定的 “契約” 進(jìn)行設(shè)計(jì)和開發(fā)。也就是在設(shè)計(jì)時(shí)，就要針對服務(wù)的上下文邊界確立好，做好約束和規(guī)范。
出現(xiàn)上面這些問題，我們要想想：是不是服務(wù)的職責(zé)不清晰還是拆分有偏差，又或是業(yè)務(wù)領(lǐng)域改變了?。
我們要盡快對整體的服務(wù)做一個(gè)再規(guī)劃，界定新的上下文。否則，以后會越來越亂，有好受的。
總結(jié)
在今天的文章中，我們介紹了巨石應(yīng)用和微服務(wù)架構(gòu)的一些基本特性。同時(shí)也給大家展示了，最常見的切換方式：絞殺者模式。
隨后和大家探討了所有微服務(wù)演講中，都必然會碰到的一個(gè)大問題：服務(wù)太小。
服務(wù)太小又分為兩種情況：
- 起步上來就一頓拆，應(yīng)用還沒上線就拆出來 60，70 個(gè)服務(wù)，拆的很開心。
- 發(fā)展時(shí)發(fā)現(xiàn)有新業(yè)務(wù)領(lǐng)域，又或是用的時(shí)候不對勁。頻繁一塊功能，好幾個(gè)服務(wù)左右反復(fù)橫跳，感覺應(yīng)該在一塊。
這種情況下，我們需要分清楚，這是人，還是設(shè)計(jì)上的問題(這很重要)。及時(shí)重新界定新的領(lǐng)域，面向服務(wù)做好新的上下文界定，能夠適當(dāng)?shù)慕鉀Q部分問題。
業(yè)務(wù)是在持續(xù)發(fā)展的，若要做好，要長期的階段性復(fù)盤。但若是人的問題，那就需要好好思考了，畢竟康威定律。
當(dāng)前名稱：微服務(wù)的災(zāi)難：拆的很爽，但服務(wù)太小...
本文URL：http://www.5511xx.com/article/cccgsde.html
