微服務和分布式對象第一定律

當我寫 企業應用程序架構的模式 時，我創造了我所謂的分布式對象設計 第一定律：“不分發你的對象” 。近幾個月來， 微服務 引起了很多人的興趣，導致一些人質疑微服務是否違反了這項定律，如果是，我為什么贊成他們？

在第一個定律聲明中，我使用短語“分布式對象”。這折射出一種觀點，這種觀點在90年代末00年代初期相當流行，但從那以后便（理所當然）失去了青睞，即你可以設計對象，并選擇在進程或遠程使用這些相同的對象，其中遠程可能意味著同一機器中的另一進程，或在不同的機器上。聰明的(Clever)中間件（如 DCOM 或 CORBA 實現）將處理內部/遠程區分，因此你的系統可以被編寫，并且你可以將其分解為進程，而這與應用程序的設計無關。

我反對分布式對象的概念，因為，盡管你可以在對象內部進行封裝，但你 無法封裝遠程和進程內調用的差異 。進程內的函數調用很快速，成功率高（因為任何異常都是由應用程序而不僅僅是由調用引起的）。 然而，遠程調用的速度慢了幾個數量級，并且由于遠程進程或連接中的故障，遠程調用總是有失敗的可能。

這種差異會導致 API 使用準則的不同。在進程內調用可以是細粒度的，如果你想獲得 100 個產品的價格和存貨量，你可能會分別調用 100 次產品價格功能，再調用 100 次獲得其存貨量。但是，如果該功能是遠程調用，你最好將所有這一切批處理為一個調用，一次請求所有產品的價格和存貨量。因為這樣會產生與產品對象迥異的接口。因此，你不能使用相同的類（主要是關于接口層的），還要以透明方式在進程內或遠程方式之前切換。

微服務倡導者非常清楚這種區別，我從未聽他們談論過進程內/遠程的透明度。因此他們沒有重蹈分布式對象的覆轍，也就沒有違反第一定律。相反，他們倡導通過 HTTP 或輕量級消息來傳遞與文檔進行的粗粒度交互。

因此，從本質上來說，我發表的對于分布式對象和微服務倡導者的觀點并不相矛盾。盡管如此，此處還有另一個問題有待商榷。微服務意味著使用通過遠程連接進行通信的小型分布式單元的數目遠遠超過單片機。即使它滿足第一定律的字面意義，但符合第一定律的核心價值嗎？

我認為分布式是一個復雜性的助推器。粗粒度的 API 比細粒度的 API 更難以使用。遠程調用的失敗時，你需要想出處理方法，并找出其對一致性和可用性的影響。即使通過協議設計將遠程調用的影響降至最低，你仍然需要考慮與之相關的性能問題。當設計一個單片機架構時，你必須考慮模塊之間的責任分配問題；使用分布式系統時，你必須考慮模塊和分布式因子之間的責任分配問題。

雖然小型微服務更容易理解，但可能是將復雜性傳遞到服務之間的互連上，因此更難以弄清楚什么時候出錯。當你必須跨越遠程邊界做重構時，會變得更加困難。微服務倡導者降低對異步通信的耦合度，但異步是另一個復雜度的助推器。 Cookie-cutter scaling 允許你在不增加分布式復雜度的前提下處理大流量數據。

因此，比起分布式我更傾心單片式設計。那為什么我要耗費精力來描述微服務并給予支持它的同事以支持呢？因為直覺也會出錯。許多團隊已經采用了微服務的方法，并已取得成功，如 Netflix，亞馬遜，以及 ThoughtWorks 內外的各個團隊。我本質上是一個經驗主義者，即使理論很具說服力，但依然相信經驗勝過理論。

并不是說我認為問題已經解決了。在軟件交付中，是否成功（交付） 難以識別 。雖然像 Netflix 和 Spotify 這樣的組織已經使用微服務獲得了早期的成功，但也有像 Etsy 或 非死book 這樣的例子，它們取得了諸多基于單片機架構的成功。無成功使用微服務的團隊，有時也會想是否使用單片機能取得更好的效果？微服務方法出現時間相對較短，所以我們缺乏充足的例證將傳統微服務架構與單片機架構做對比。并且在某些未知的情況下，單片機架構可能更適用。鑒于在軟件開發中收集證據的困難性，即使很多年過去了，也很可能不會有一個令人信服的判斷來支持微服務或單片機。

答案不是固定的。作為作者，最重要的就是將我們所學的知識清晰地傳達給讀者，即使觀點相互矛盾，我們也要將邏輯理清。讀者會做出自己的選擇，作者的任務是不管讀者做出何種決定，都要確保他們的觀點是經文章啟發的。

來自：https://www.oschina.net/translate/distributed-objects-microservices