Spring Web應用程序體系結構

Question

我正在學習Spring Framework。所以我想要構建一個體繫結構足夠好的應用程序。例如，我的應用程序將是某種社交網絡。我爲這個Web應用程序使用Spring Boot容器。 這個架構是否正確？我的意思是可擴展性，未來的代碼支持等。有什麼優點和缺點？我想使用REST API和微服務。 1頁= 1個控制器= 1個服務。

Answer 1

1服務，1個控制器，1頁是不限制自己的好事。你會發現一個頁面可能會使用一大堆不同的服務。想象一下，如果你的Facebook個人資料是一個控制器。這將是巨大的，不可能維持。儘可能按邏輯分解事情。有時候可能有一個使用多個控制器的頁面，有時你可以有一個控制器來處理多個頁面，所以你沒有30個真正的小控制器。我會說，如果你有一個複雜的頁面，你需要多個控制器，如果你有一個非常簡單的頁面，一個控制器可以處理其中的很多。

我也可以建議你不要在不需要的時候分解它。您所有的微服務都可以作爲應用程序中的組件。否則，你會發現你維護代碼只是轉發和接收HTTP請求的大量開銷。這也可能會讓你成爲一個非常有價值的工具：交易！您將失去交易，這可能會導致維護數據不一致。請記住你只有一個人。我一直在努力完成我一直在研究的webapp，其中95％完成了，下班後我每天花8個小時工作，直到凌晨2點。做你自己的忙，不要爲自己創造更多的工作。

Answer 2

我同意Snickers3192's answer的大部分觀點。微服務不是你應該預先計劃好的，你的應用程序應該首先存在，一開始就是一個巨無霸。馬丁福勒寫了a good piece about the Microservices yes or no question。一旦你的應用程序增長了，並且你看到需要單獨擴展應用程序的某些部分或者需要獨立開發的團隊，那麼你就有了微服務的商業案例（正如你從Fowler的文章中看到的那樣，你還必須準備好支持這樣的體系結構）。現在它是過度工程。這就是說：如果你從一個龐然大物開始，並計劃在以後發展到微服務，那麼你需要注意你的依賴關係樹。應用程序的不同部分需要彼此訪問，這很好，但要確保不引入循環依賴，否則稍後提取微服務將成爲一場噩夢。理想情況下，您可以識別將要使用的服務接口，並且現在在本地實現它們，但稍後可以通過調用Rest API來實現它們。

您建議的模式（1個控制器的1個服務器）映射到Backends for Frontends模式，這可能是一個好主意，具體取決於您的網站的複雜程度。如果你有很多在控制器之間共享的UI組件，那麼你可能想要採用另一種方法，例如， Big Pipe。但是，讓一個控制器綁定給定頁面需要知道的所有內容並將其委託給上游服務是有意義的，而不管這些控制器是全部在同一臺機器上還是在微服務體系結構中。

最後：如果您確實需要使用微服務，請注意韌性。使用像Hystrix這樣的斷路器或事件驅動架構，否則一個垂死的服務可能會佔用整個架構。