作者：潘罡 （Van Pan） @ Microsoft
上一节我们谈到了Stateful Service。在Service Fabric中，Stateful Service是理解Micro Service的抓手。
在理解了Stateful Service的基础上，我们只需要记住：Actor是单线程模型Stateful Service，Stateless Service是无持久化Stateful Service。
Actor
Actor的基类是Stateful Service。
作为程序员，很快就能理解Actor具有Stateful Service的所有特性：数据持久化，事务，partition，replia 等等。
但是因为Actor是Stateful Service的扩展，因此它有一项Stateful Service没有的特性：单线程模型。
Actor应对于这样一个场景：某种共用数据，并且需要保证数据一致性。
举个例子：多个玩家合作在打Boss，每个玩家都是一个单独的线程，但是Boss的血量需要在多个玩家之间同步。同时这个Boss在多个服务器中都存在，因此每个服务器都有多个玩家会同时打这个服务器里面的Boss。
如果是Stateful Service，很难应对上面的场景。因为如果多线程并发请求Stateful Service，默认情况下它只会并发处理。这种情况下可能造成数据冲突。
但是Actor是单线程模型，意味着即使多线程来通过Actor ID调用同一个Actor，任何函数调用都是只允许一个线程进行操作。并且同时只能有一个线程在使用一个Actor实例。
同时，Actor实例的生命周期是由Service Fabric控制的。虽然调用过某个ID的Actor，但是Service Fabric依然可能会在长时间没有使用时回收这个Actor实例。
另外，Actor和Stateful Service一样，在发布前会定义好partition key和partition数量。当外部服务根据Actor ID来获取某个Actor实例时，Service Fabric会根据HASH算法返回对应的Actor实例。
Stateless Service
如果你已经理解了Stateful Service和Actor，那Stateless Service就非常好理解了。
Stateless Service没有partition，没有replica，也没有持久化数据。
唯一能控制Stateless Service的，是instance count。
也就是说，Stateless Service的不同实例就是跑在不同node上。
比如在发布时如果设置Stateless Service instance count是3，同时发布目标Service Fabric Node有5台，那Service Fabric就会随机选择三台node运行这个Stateless Service。
Stateless Service的典型场景是：Web前端
Web前端只需要负责接收HTTP request并调用后端服务获取数据并进行渲染。一般架构下，Web前端都是一些动态页面，不会持久化任何数据。
Web前端服务数越多，理论上就能处理更多的并发量。
希望以上的介绍，可以帮助你理解Actor和Stateless Service。
我们会在后续内容中介绍如何使用Actor和Stateless Service.