1.4 解耦與服務化

對解耦與服務化的關系進行深入思考，嘗試理解其本質，明確什么是目的，什么是手段，有助于在做決策時分清主次。

解耦和服務化是什么關系？解耦是為了使架構變得靈活（比如靈活部署、靈活擴展、靈活調用），反之則“牽一發而動全身”。服務化不是解耦的手段，但解耦會為服務化打下堅實的基礎。

微服務是由松耦合的、有相應語境的元素構成的一種面向服務的架構，松耦合意味著可以獨立更新這些服務。更新其中一個服務并不會改變其他的服務。

企業應用架構向“微”服務演化時，如果以解耦為基礎考慮服務化，就會水到渠成。“微”不是“比小還小”，而應該理解為“單一職責”。在遵循“單一職責”原則的基礎上，解耦將變得容易一些。

下面借此機會探討一個問題，進而給出一個不嚴格的“單一職責”的度量方法。在一般情況下，對于特定的語言環境，比如 Java 和 C#，代碼行數較少時通常很難實現多個業務功能這個說法是否是對的呢？如果答案是肯定的，那么可以嘗試用子程序（函數、過程、方法）的代碼行數對軟件工程師遵循“單一職責”原則的程度進行度量。

程序設計風格較好時才能獲得高可讀性、高質量、高性能。一個子程序的代碼行數最好不要超過某個數值[9]。對于不同的編程語言，建議對開發小組的子程序代碼行數進行統計，經過一段時間的積累得出合適的經驗值。一般，這個代碼行數的經驗值是和小組的生產能力相關的。

不是所有的系統都適合進行服務化，即使不走服務化道路，降低耦合度也是好的。