微服務的真相: 服務拆的太小，後面迭代忍不了

通常情況下組織業務發展的萌芽初期，在快速發展階段，都面臨着軟件開發週期的挑戰，這個階段活下去最重要，一切只有一個標準 “快”，這個階段組織裏誕生的往往是一些 “巨石應用”。

一開始爲了活下去：快，最重要

過去的巨石應用

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

巨石應用

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

• 難以部署和維護。

• 頻繁部署的障礙。

• 不相關的功能之間的依賴性。

• 難以嘗試新的技術 / 框架。

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

現代的微服務架構

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

圖片

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

Proxy Pattern

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

• UI、靜態內容組件化，解耦出來成爲可獨立部署的客戶端應用。

• 定義邊界，服務要有較爲明確清洗的邊界。

• 單一職責，服務的能力要單一，數據庫等第三方依賴存儲要獨立。

絞殺者模式

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

如下圖：

絞殺模式

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

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

服務太小

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

N 人維護數倍服務

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

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

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

落地方案

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

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

新功能歸屬誰

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

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

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

• 這個新功能是什麼，具體的業務領域劃分？

• 爲什麼這兩個服務會存儲共享這一個新功能的可能？

• 這兩個服務，是否應該繼續拆開，要不要合併？

• 由於新功能的出現，是不是應該拆出第三個服務？

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

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

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

總結

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

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

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

• 起步上來就一頓拆，應用還沒上線就拆出來 60，70 個服務，拆的很開心。

• 發展時發現有新業務領域，又或是用的時候不對勁。頻繁一塊功能，好幾個服務左右反覆橫跳，感覺應該在一塊。

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

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

感謝煎魚本次帶來的分享

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/V_BOx-cSyfQqRDLxG_Eu7Q