從Monolith到微服務：理論與實踐 - Kent Beck

banq發表於2020-10-07
Mono微服務

我們如何才能快速地從整體變為微服務？
無法回答這個問題。首先，“迅速”就在窗外。你一個月都沒弄糟。您將不會在一個月內修復它。其次，您希望從微服務中獲得一些您目前無法獲得的好處。那有什麼好處？微服務不是重點。
拒絕了這個問題之後，我將繼續回答。在我無法解釋為什麼無法快速更改微服務之前，如果強制轉換是危險的，這是作用在軟體設計上的基本力量。在20世紀70年代中期，Yourdon＆Constantine在結構化設計中闡明瞭這些， 並且沒有改變。
他們的論據是這樣的：
  1. 我們設計軟體以降低其成本。
  2. 軟體成本等於≈更改軟體的成本。
  3. 更改軟體的成本≈昂貴的更改（電源定律等）的成本。
  4. 透過級聯的變化所產生的昂貴變化的成本-如果我改變這個話，我必須改變的是和那個，如果我改變的是那麼...
  5. 設計元素之間的耦合就是更改傳播的傾向。
  6. 因此，設計≈成本≈變化≈大變化≈耦合。可傳遞地軟體設計≈管理耦合。

（這跳過了很多有趣的東西，但是我只是試圖建立一個論點，說明為什麼將整體式快速分解為微服務會適得其反。）
 

管理聯軸器
請注意，我並不是說“消除耦合”。去耦帶有其自身的成本，既包括去耦本身的成本，也包括未預期到的變更的未來成本。設計越能完美地適應一組更改，就越有可能被新穎的更改所矇蔽。在耦合、去耦和成本三者之間必須權衡。
您可以透過以下兩種方式之一來管理耦合：

  • 消除耦合。具有硬編碼的read（）和write（）函式的客戶端和伺服器就協議更改而耦合。更改一個write（），您將不得不更改read（）。但是，引入一種介面定義語言，您可以在一個地方新增到協議中，並使更改自動傳播到read（）和write（）。
  • 縮小耦合範圍。如果更改一個元素意味著要更改另外十個元素，那麼將這些元素放在一起比將它們分散在整個系統中更好-更少的導航，更少的檢查，更少的測試。更改元素的數量相同，但是每次更改的成本較小。（這也被稱為“一堆肥”原則，或芳香性較低的“內聚力”。）

 

無法很快
有兩個因素會阻止快速去耦：

  • 技能
  • 知識

我看到有關軟體設計的有用民俗知識-例如，使模型與檢視和控制器分離-但很少明確承認或管理耦合。戴上耦合眼鏡後，您將看不到耦合，但是過渡需要一段時間。識別耦合，尋找Emmenthal變化（乳酪之間有很多孔的變化），增加內聚力，在一個方向上減小內聚力，然後在另一個方向上增加內聚力，進行設計。
一旦可以進行抽象設計，就可以將這些技能應用於您的系統。系統的內部邊界應該在哪裡？發現它們需要一段時間和一些實驗。最好先輕描淡寫邊界，然後再更牢固地繪製邊界，然後再切除零件。素描錯誤是可逆的。服務提取並非永遠都是永久的，但是當您發現兩個服務耦合時，進行逆向操作的代價很高。
 

好訊息
您如何快速將整體分解為微服務？不能，因為您需要學習方法，也需要學習什麼。好訊息是，您不必快速將整體分解為微服務即可快速獲得所需的某些好處。
更改叢集。如果您整理步行的街道，並且大部分時間都走同一條街道，那麼稍微整理一下就會使您的街道大部分都保持整潔。進行更改之前，請先增加內聚力。在進行更改之前，請消除耦合。變革很快就會加速。

banq評：高聚合低耦合，尋找凝聚力，邏輯一致性體現了一種凝聚力；1+2=3加法彙總就是一種邏輯一致性，還有其他數學形式的演算法，當然還有小的業務規則和業務約束等。包括在你的if/else中的業務邏輯。
 

相關文章