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