[[410054]]

本文轉載自微信公眾號「腦子進煎魚了」，作者陳煎魚。轉載本文請聯系腦子進煎魚了公眾號。

大家好，我是煎魚。

我有一個好朋友小咸魚，他們組織早期是業務萌芽的初期，在快速發展階段，面臨著軟件開發周期的挑戰。

過去的巨石應用

這 “強大又厚實” 的巨石應用是他們應用架構上的一個早期策略：

但隨著業務的持續發展，巨石應用的痛點也非常明確。像是：

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

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

現代的微服務架構

正式邁向了微服務轉型之路，一切先從拆分開始：

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

微服務拆分有以下幾種粗的基準：

• UI、靜態內容組件化，解耦出來成為可獨立部署的客戶端應用。
• 定義邊界，服務要有較為明確清洗的邊界。
• 單一職責，服務的能力要單一，數據庫等第三方依賴存儲要獨立。

絞殺者模式

在完成微服務改造的基準的定義后，絕大部分公司都是采取業界中比較著名的 “絞殺者” 模式。

如下圖：

由于會考慮微服務的組織，大多都是有成熟業務的盈利組織了，業務發展太迅猛，才發現技術架構跟不上業務要求的迭代速度和周期，不大可能停下業務硬重構。

因此業內基本采取邊遷移，邊改造為微服務的漸進式重構的方式，實現 “絞殺者”，把技術債務給償還了。

服務太小

在微服務逐步的演進過程中，我們就會發現一個新的問題。雖然在微服務做規劃時，都會很認真的對服務的拆分進行深入研討，但還是出現了服務拆的很爽，但后面實戰的時候發現服務太小了。

N 人維護數倍服務

出現了 “10 名工程師組成了維護 60 項服務的小組。一人負責一個服務還不夠用” 的情況。

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

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

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

當然，應用還沒上線，就拆成數倍的服務。形成 N 個人維護其自身數量的數倍服務，不大合理。這也是業內很多互聯網公司需要思考和解決的問題。

新功能歸屬誰

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

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

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

• 這個新功能是什么，具體的業務領域劃分?
• 為什么這兩個服務會存儲共享這一個新功能的可能?
• 這兩個服務，是否應該繼續拆開，要不要合并?
• 由于新功能的出現，是不是應該拆出第三個服務?

在真實的項目場景中，我們會按照事前定的 “契約” 進行設計和開發。也就是在設計時，就要針對服務的上下文邊界確立好，做好約束和規范。

出現上面這些問題，我們要想想：是不是服務的職責不清晰還是拆分有偏差，又或是業務領域改變了?。

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

總結

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

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

服務太小又分為兩種情況：

• 起步上來就一頓拆，應用還沒上線就拆出來 60，70 個服務，拆的很開心。
• 發展時發現有新業務領域，又或是用的時候不對勁。頻繁一塊功能，好幾個服務左右反復橫跳，感覺應該在一塊。

這種情況下，我們需要分清楚，這是人，還是設計上的問題(這很重要)。及時重新界定新的領域，面向服務做好新的上下文界定，能夠適當的解決部分問題。

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