過去，我使用我認為是“微服務”的東西。我們有一個服務發現，應用程式通過 REST 同步呼叫相互通信，我相信這稱為請求/回應。
現在我們正在開發一個應用程式，該應用程式被簡單地分解為多個小應用程式，這些應用程式通過使用 Kafka 的發布/訂閱協同作業，它們之間沒有直接通信，也沒有服務發現。
是否可以肯定地說這些也是“微服務”，或者我應該如何稱呼它們？
uj5u.com熱心網友回復：
正如一位評論者指出的那樣 - 答案總是固執己見（而且 stackoverflow 通常不是基于意見的問題的最佳場所），但我并不害怕提供我的幫助。
我的觀點與 Martin Fowler 和其他人在過去十年中教給我們的內容以及來自亞馬遜的 Werner Vogels 開創性作業的見解一致。他們的定義是，微服務不是一個定義明確的單一標準，而是一種架構風格，可以涵蓋分布式計算中的一系列不同方法。它們的共同點是在許多不同維度上提供可擴展性，但主要是系統復雜性、組織生產力、吞吐量和彈性——所有這些都是負擔得起的。為了實作這一點，設計應該圍繞：
- 根據業務目標切割服務邊界（一種領域驅動設計）。
- 規模/服務范圍受到限制（著名的兩個披薩團隊規模的想法）。
- 在組織職責和維護方面明確分離。這包括每個服務的獨立團隊和發布/維護周期。
- 擁抱所有層的自動化（云虛擬化、devops、CICD、基礎設施即代碼等如何成為流行的工具）。
- 設計側重于故障恢復操作，例如避免級聯故障、定義的故障狀態、回退等。
這些目標的結果也是采用分布式系統架構和水平可擴展性設計（無狀態、計算和存盤分離等）。
因此，如果您覺得您的設計符合這些路線，那么在我看來，您將成功應用微服務架構風格。
如果您想了解更多關于這種思想流派的資訊，我推薦您閱讀。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/441682.html