[[410054]]

本文轉(zhuǎn)載自微信公眾號「腦子進(jìn)煎魚了」，作者陳煎魚。轉(zhuǎn)載本文請聯(lián)系腦子進(jìn)煎魚了公眾號。

大家好，我是煎魚。

我有一個好朋友小咸魚，他們組織早期是業(yè)務(wù)萌芽的初期，在快速發(fā)展階段，面臨著軟件開發(fā)周期的挑戰(zhàn)。

過去的巨石應(yīng)用

這 “強(qiáng)大又厚實” 的巨石應(yīng)用是他們應(yīng)用架構(gòu)上的一個早期策略：

但隨著業(yè)務(wù)的持續(xù)發(fā)展，巨石應(yīng)用的痛點也非常明確。像是：

• 難以部署和維護(hù)。
• 頻繁部署的障礙。
• 不相關(guān)的功能之間的依賴性。
• 難以嘗試新的技術(shù)/框架。

這些痛點也正給他們公司帶來各種各樣的組織問題，而當(dāng)代微服務(wù)的橫空出世，對軟件工程師很有吸引力，他們也就轉(zhuǎn)型了。

現(xiàn)代的微服務(wù)架構(gòu)

正式邁向了微服務(wù)轉(zhuǎn)型之路，一切先從拆分開始：

在以往的大單體中，我們會將其 Cache、DB 等混合在遺愛。但在做微服務(wù)后，我們會選用拆成多個服務(wù)的方式，最終演變成：

微服務(wù)拆分有以下幾種粗的基準(zhǔn)：

• UI、靜態(tài)內(nèi)容組件化，解耦出來成為可獨立部署的客戶端應(yīng)用。
• 定義邊界，服務(wù)要有較為明確清洗的邊界。
• 單一職責(zé)，服務(wù)的能力要單一，數(shù)據(jù)庫等第三方依賴存儲要獨立。

絞殺者模式

在完成微服務(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)的方式，實現(xiàn) “絞殺者”，把技術(shù)債務(wù)給償還了。

服務(wù)太小

在微服務(wù)逐步的演進(jìn)過程中，我們就會發(fā)現(xiàn)一個新的問題。雖然在微服務(wù)做規(guī)劃時，都會很認(rèn)真的對服務(wù)的拆分進(jìn)行深入研討，但還是出現(xiàn)了服務(wù)拆的很爽，但后面實戰(zhàn)的時候發(fā)現(xiàn)服務(wù)太小了。

N 人維護(hù)數(shù)倍服務(wù)

出現(xiàn)了 “10 名工程師組成了維護(hù) 60 項服務(wù)的小組。一人負(fù)責(zé)一個服務(wù)還不夠用” 的情況。

正當(dāng)以為這不是常見問題時，最近看到我的好朋友 HHF(@HHFCodeRv)提到有人向他咨詢架構(gòu)相關(guān)的問題。

下面是咨詢他的公司的 Java 架構(gòu)師落地的方案。如下圖：

亮點是這 2 個后端開發(fā)，其中一個還是架構(gòu)師。結(jié)合實際情況，可能只有 1 個后端在干活。這堪稱 1:17 的人和服務(wù)的配比量，每天光切 IDE 找服務(wù)可能就得好幾東...

當(dāng)然，應(yīng)用還沒上線，就拆成數(shù)倍的服務(wù)。形成 N 個人維護(hù)其自身數(shù)量的數(shù)倍服務(wù)，不大合理。這也是業(yè)內(nèi)很多互聯(lián)網(wǎng)公司需要思考和解決的問題。

新功能歸屬誰

在實際的業(yè)務(wù)場景中，出現(xiàn)了 “有人要求我把一個新功能同時部署到兩個不同服務(wù)之中” 的訴求。

因為這個新功能同時是 ServiceA 和 ServiceB 這兩個服務(wù)的職責(zé)劃分的所有者或者部分所有者，所以新功能理應(yīng)同時在這兩個服務(wù)都要有所提供。

這時候需要考慮以下問題：

• 這個新功能是什么，具體的業(yè)務(wù)領(lǐng)域劃分?
• 為什么這兩個服務(wù)會存儲共享這一個新功能的可能?
• 這兩個服務(wù)，是否應(yīng)該繼續(xù)拆開，要不要合并?
• 由于新功能的出現(xiàn)，是不是應(yīng)該拆出第三個服務(wù)?

在真實的項目場景中，我們會按照事前定的 “契約” 進(jìn)行設(shè)計和開發(fā)。也就是在設(shè)計時，就要針對服務(wù)的上下文邊界確立好，做好約束和規(guī)范。

出現(xiàn)上面這些問題，我們要想想：是不是服務(wù)的職責(zé)不清晰還是拆分有偏差，又或是業(yè)務(wù)領(lǐng)域改變了?。

我們要盡快對整體的服務(wù)做一個再規(guī)劃，界定新的上下文。否則，以后會越來越亂，有好受的。

總結(jié)

在今天的文章中，我們介紹了巨石應(yīng)用和微服務(wù)架構(gòu)的一些基本特性。同時也給大家展示了，最常見的切換方式：絞殺者模式。

隨后和大家探討了所有微服務(wù)演講中，都必然會碰到的一個大問題：服務(wù)太小。

服務(wù)太小又分為兩種情況：

• 起步上來就一頓拆，應(yīng)用還沒上線就拆出來 60，70 個服務(wù)，拆的很開心。
• 發(fā)展時發(fā)現(xiàn)有新業(yè)務(wù)領(lǐng)域，又或是用的時候不對勁。頻繁一塊功能，好幾個服務(wù)左右反復(fù)橫跳，感覺應(yīng)該在一塊。

這種情況下，我們需要分清楚，這是人，還是設(shè)計上的問題(這很重要)。及時重新界定新的領(lǐng)域，面向服務(wù)做好新的上下文界定，能夠適當(dāng)?shù)慕鉀Q部分問題。

業(yè)務(wù)是在持續(xù)發(fā)展的，若要做好，要長期的階段性復(fù)盤。但若是人的問題，那就需要好好思考了，畢竟康威定律。