桌面应用程序可以具有微服务架构吗？

Question

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

Answer 1

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

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

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

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

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

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

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

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

在消息传递的情况下，您将不得不使用一些消息传递中间件，这几乎从来都不是一个好主意（这些工具在具有适当硬件的服务器上运行良好）。

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

它完全适用于您的桌面应用程序吗？

因此，再次考虑什么对您的客户、您的应用程序和您来说是最好的 :) 并选择正确的架构。

Answer 2

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