桌面应用程序可以有微服务架构吗？ [关闭]

Question

可以将基于单体架构的桌面应用程序转换为微服务架构吗？我只能找到有关使用微服务架构的 Web 应用程序的文章。这是否意味着桌面应用程序不能使用这种架构？

Answer 1

一般来说，从技术上讲，没有什么可以阻止您将微服务架构用于任何类型的应用程序，但是当您走这条路时（实际上就像任何其他架构一样），请检查微服务架构的好处以及它是否有意义全部在您的应用程序中。

在我看来，这没有意义，这里有一些想法可以说明我为什么这么认为：

1. 微服务架构几乎肯定意味着许多进程

那么为桌面应用程序保留许多进程是一种好方法吗？您的客户是否愿意将您的应用程序用于多个流程？

1. 微服务架构通常意味着产品的各个部分都可以在生产中独立开发、测试，最重要的是，可以独立更新。

在服务器端它大放异彩，但它在桌面上有意义吗？我个人对此表示怀疑，但是您应该自己回答

1. 微服务架构假设不同的部分相互连接。这可以是用于同步通信的 HTTP（任何其他基于套接字的协议）、用于异步通信的消息系统等等。

如果你使用套接字 - 你会公开端口进行通信吗？如果您将此桌面应用程序安装在具有安全策略（防火墙等）的客户端计算机上，它会起作用吗？

如果是消息传递，您将不得不使用一些消息传递中间件，这几乎不是安装的好主意（这些工具在具有适当硬件的服务器上运行良好）。

4. 微服务架构（相对于单体架构）的一大卖点是可扩展性。理论上，您可以独立于其他部分扩展应用程序的任何特定部分（作为微服务实现）。换句话说 - 你可以说：“这个微服务”处于高负载（或任何其他原因），所以我想启动 5、10 或 100 个它的实例。

它是否适用于您的桌面应用程序？

因此，再次思考什么对您的客户、您的应用程序和您最有利 :) 并选择正确的架构。

Answer 2

当然可能，因为 Windows 有服务，Linux 有守护进程等等，你可以安排不同的服务通过内部网络或其他机制相互通信，具体取决于什么是合适的。然而，这样做是否合适/一个好主意是另一个问题。作为 Web 应用程序的架构，微服务通常更有意义。微服务通常会以组件之间松散耦合的形式产生成本。应用程序中的严格类型将确保应用程序各部分之间的消息正确形成。对于可能彼此分开编译并通过一种更间接的机制进行通信的服务，这一点更难确保。