作者：潘罡 （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.