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这样的断路器或事件驱动架构，否则一个垂死的服务可能会占用整个架构。