微服務是與團隊管理相關的 - filipnikolovski

banq發表於2021-12-02
微服務

我知道微服務的話題已經被反覆討論過，我只是想根據我在這種設計 Web 應用程式的方法方面的經驗，將我的經驗加進去：
  • 很多人認為微服務架構解決了具有擴充套件性和效能性質的軟體問題。但他們解決的最重要的問題是組織問題。
  • 康威定律一直在起作用。當您考慮構建的軟體應該是什麼樣子時，您需要考慮您的組織結構應該是什麼樣子。他們總是齊頭並進。
  • 如果您是一個團隊，那麼從這個角度來看，涉及多個移動部件的設計沒有多大意義。誰應該擁有每個元件的所有權？這些服務如何才能真正相互獨立？糾纏它們是不可避免的，因為這樣更方便，最終得到類似於微服務架構的東西，但實際上它更像是一個“分散式單體”。從微服務架構開始是很多人的錯誤做法。軟體的結構最終看起來總是像組織的結構。這是不可避免的。
  • 如果您只有一個團隊，切勿從微服務架構開始。
  • 隨著組織規模的擴大，團隊中加入了更多的人，現在是對當前架構設計提出問題的時候了。
  • 隨著團隊的成長，管理起來會越來越困難。將這個大團隊分解成多個、更小、獨立的團隊是向前邁出的自然一步。那麼我們應該問的問題是：這些團隊如何對他們負責的產品部分擁有完全的所有權？如何讓團隊掌握自己的“命運”？
  • 對於一個真正獨立的團隊來說，它需要在堆疊的每一層都有完整的決策能力：從 UI/UX、後端將要公開的 API，一直到將為整個事物提供動力的基礎設施. 作為單個單體應用程式這樣做當然是可行的，但是團隊需要在他們的開發過程中同步，尤其是在部署階段。他們會不斷地踩對方的腳趾。因此，需要建立一種能夠反映組織架構的架構。微服務解決了這個確切的問題 - 擴充套件團隊。
  • 服務需要是可組合的，並且可以很好地相互配合，就像您在單體應用中建立可組合模組一樣。將它分開並簡單地在它前面放置一個 Web 伺服器不會拯救你。
  • 對於跨越多個域的功能，明確的資料所有權以及清晰一致的 API 是必須的，否則您可能會使所涉及的服務之間的關係複雜化。定義這些邊界是開發此功能的團隊的責任。服務之間的溝通應該反映團隊之間的溝通。

相關文章