Architecture 微服务或SOA就绪架构

这（下面）是一个好的web架构吗

我们有两种服务：前端服务和后端服务

后端服务只提供API，而不是传统的MVC

后端服务将以模块的形式构建，每个模块作为一个小应用程序，具有自己的配置，因此每个模块可能具有不同的数据库引擎和依赖项

与模型的所有通信都是通过存储库完成的

尝试避免任何类型的SQL联接，并通过执行多个查询来获得结果，从而使其保持简单

使用API网关，它将成为所有请求的入口点

因此，通过这一点，我们可以在未来轻松地转向SOA或微服务

您对上述方法有何看法

---

先谢谢你

很难同意这样的说法：

几乎所有成功的微服务故事都是从一块巨大的巨石开始的，它被破坏了。几乎所有我听说过的系统都是从零开始构建的微服务系统，它最终陷入了严重的麻烦

有一些微服务的故事并不是从一块巨石开始的，另一方面，也有一些微服务的故事是成功的，是从零开始的

在我看来，很难回答您的问题，但是当您考虑体系结构时，您必须了解不同方法的优缺点，并根据您的需要做出决定

例如，使用monolith方法，水平可伸缩性很难（垂直可伸缩），但监视和部署更容易。
另一方面，使用微服务方法，您可以水平扩展，但部署和监视更加复杂。此外，使用微服务方法，您必须了解微服务将如何通信（例如，代理与生产者-消费者模式）

---

希望这能有所帮助。

但您对上述方法有何看法？一般来说，它好吗？为什么通过存储库进行通信（“与模型的所有通信都通过存储库完成”）？我指的是控制器和模型之间的通信通过存储库完成repositories@justsomedev，看起来像反模式，为什么不使用代理（例如ActiveMQ）在微服务之间进行通信，然后，您可以应用生产者/消费者、请求/回复、观察者、EIP（通过Camel），您可以水平扩展，等等。我计划进行微服务就绪设计，而不是微服务设计，因此当我看到这一点时，我们应该转向微服务，我可以轻松迁移。因此，上面的体系结构是单片的，但可以用于微服务。我想问的是，这种方法好还是不好，为什么要搁置？