Actor 模型与微服务

由 Mux 主办的 DEV 全球展示挑战赛：展示你的项目！

我最近突然想到：如果微服务是重复发明轮子呢？如果微服务试图实现与 Actor 模型相同的功能呢？

我不是第一个问这个问题的人

StackExchange 上也有类似的问题。我对给出的答案并不信服。

Actor 模型——是并发计算的数学模型，而微服务——是面向服务的架构的一种实现。

然后呢？有很多东西都可以用于计算，例如，Lambda演算（逻辑中的形式系统）、台球、量子力学、活细胞、生命游戏等等。它们虽然属于不同的类别，但这并不妨碍我们将它们全部用于计算。

再次强调，微服务也可以是有状态的，但这违背了微服务的设计原则。

没错，但是你需要把这些信息（账户、记录、用户）存储在某个地方？如果你不把数据库本身算作服务，那么同样的逻辑也可以应用于参与者。

如果什么？

对于微服务架构，你需要使用某种通信协议，例如 REST、Protocol Buffer、GraphQL 等等。在 Actor 模型中，这和函数调用一样简单。

部署微服务时，通常假设每个微服务都隔离在各自的机器上（虚拟机、Jail、Docker 等），因此最终需要大量的机器。部署大量机器既困难又昂贵，而部署虚拟机则需要使用 Kubernetes 或类似的工具。Actor 模型则不同，它将 Actor 部署到集群中，并且可以自动分布。

使用微服务时，需要利用分布式追踪来调试问题。在 Actor 模型中，可以使用“堆栈跟踪”（这可能是编程语言本身提供的功能）。

开发微服务时，你会把所有东西都放在单独的代码仓库里，但这样一来，跨多个服务进行更改就变得很困难，所以你又会把所有东西都放到单体仓库里。感觉就像在原地打转。

最大的区别在于，在微服务中你可以使用不同的编程语言，但在 Actor 模型中你只能使用一种编程语言（不包括外部接口和 shell 调用）。

一旦程序员习惯了复杂的解决方案，那么简单的解决方案就会让他们觉得不完整、不舒服。

——道格·霍伊特

免责声明：我指的并非Actor模型的具体实现，而是一种更理想化的Actor模型。我希望这匹小马能接近我的设想，但我还没有实际操作过。