Answers:
Actor模型-是用于并发计算的数学模型，而微服务是面向服务的体系结构的实现。相似之处是偶然的。
当然，有可能基于某些参与者模型构建微服务，并使用参与者模型对某些微服务架构进行建模，但这并不意味着它们是等效的。用“电子邮件系统”替换“微服务系统”，它仍然是正确的。用“通信顺序过程”（CSP）替换“角色模型”，它也将是“ true”，因为CSP和角色模型系统可以相互建模。
给定参与者模型，您可以使用微服务，SOA甚至电子邮件来实现它，但这并不意味着它们具有相同的抽象级别才能真正进行比较。
而且，参与者模型强调缓冲区（在微服务领域中可以被视为消息队列），因此某些参与者/微服务可能尚未准备就绪，而固有的异步通信仍然可能。
换句话说，与演员模型进行比较可以带来很高的考虑度，从而带来一些创造性的见解，但主要是苹果与橘子。
如果目标是将SOA /微服务的数学模型与Actor模型进行比较，那么它也不是微不足道的，因为：1）SOA的数学模型没有达成共识，2）模型通常包含此目的。SOA /微服务建模很可能与参与者模型的目的不同。此处尝试对SOA建模的一个示例。
当然，可以使用微服务创建参与者模型系统，并将每个服务称为参与者（请参阅严格定义参与者模型）。但这并不意味着两者在一般意义上都没有任何有意义的关系。
微服务是一种将软件的关注点划分为自己的可部署工件（可执行文件，脚本，JAR，WAR等）的一种组织方式。这为您提供了灵活性，例如，通过允许您在需要的地方部署更多实例来进行扩展。假设用户花费更多的时间在查看目录上，而不是在购物车中添加东西。一个可部署的工件处理目录功能，另一个可处理购物车功能－您可以运行目录服务的更多副本来处理负载。
它还将它们与内部更改隔离开来。假设您从关系数据库转移到用于存储产品数据的文档数据库-很有可能您的购物车服务不需要更改。
actor模型的级别比可部署工件的级别低，更多地是用来实现服务的对象类型。继续上面的示例，您的系统中的购物车可能由actor表示，因此每个用户的购物车都是一个不同的actor，并且消息告诉它添加商品，删除商品，以当前内容进行响应，添加运输，签出等等。在这种情况下，您仍然拥有微服务，并且使用actor模型来实现。
我要说的主要区别是粒度之一。
对于actor模型，它的粒度相对较细，因为actor倾向于表示OOP中一个对象的等效项。
对于微服务，它的粒度相对较粗，因为单个微服务可能包含大量的参与者或对象。
请注意，您实际上并不需要太想像一下就可以说现代网络是同一件事，甚至粒度更大（“宏服务”）；并且（例如）HTTP服务器是宏服务，数据库服务器是宏服务，Web浏览器是宏服务等。
大致相同-相互沟通的孤立片段。改变的只是碎片的大小（因此碎片的数目）。