使用 Azure Service Fabric 创建（4）可靠有状态服务
以下是以往与Azure相关的文章列表。
使用 Azure 容器服务（一）：基本部署
使用 Azure 容器服务（二）：自动化部署
使用 Azure Service Fabric（一）：配置使用环境
使用 Azure Service Fabric（二）：无状态服务
使用 Azure Service Fabric（三）：可靠演员服务
在 Service Fabric 中定义的应用程序中，最后一个是 Stateful Reliable Service。
不论怎么说，我希望 Reliable Stateful Service 和 Stateful Reliable Service 中的其中一个被统一起来。因为在官方文档中两者都混合使用，所以应该都可以吧。
有状态可靠的服务
有状态可靠服务指的是通过称为可靠集合（Reliable Collection）的机制来管理状态的应用程序，除了具备可靠服务的特点。
可靠的收集是以以下方式描述的。
Reliable Collection 是一组使用 C# 集合的可靠性较高且对于之前使用过的用户来说很熟悉的集合类。在过去，为了在服务中以可靠的方式管理状态，需要使用外部系统。使用 Reliable Collection，用户可以将状态存储在其计算机旁边，并实现与高可用性外部存储相同水平的高可用性和可靠性。同时，通过将计算和状态放在一起，还可以缩短延迟时间。
这似乎是基于C#的集合。我从来没有接触过C#的集合，所以不太清楚，但我猜它可以与LINQ等结合使用。
真正的Stateful Service的定义
实际上，在Service Fabric中，Stateful Service是指必须将一部分状态保持持久化并保持一致性的服务。换句话说，Azure的BLOB或数据库也被视为Stateful Service。
然而，如果这样做的话，那么本次的文章就没有可写之处了，所以至少在这篇文章中，我想使用前面提到的定义。
尝试创建一个有状态的服务。
那我们立刻开始制作吧。我们将继续使用以前的环境。所使用的模板与可靠的服务相同。
好吧，为了成为可靠的有状态服务，我们需要使用可靠集合。但是，可靠集合究竟是什么呢？
可靠的收集
可靠的集合是C＃中System.Collections的自然演进和发展。它的特点是，
-
- ローカルに状態が永続化される
-
- 状態が複数のインスタンスにレプリケートされる
-
- 基本的に操作は非同期
- トランザクションの概念
在中国，以下是一种翻译的方式：
被提到了几种选项。事务默认情况下似乎使用了大多数仲裁。这和Cassandra等系统类似。
其他特征也具备了分布式存储的特点。
-
- 分離レベルの存在
基本的に自動で選択されます
行単位のロック
ちょうどCassandraのような感じです
2-Phase Transaction
ログとチェックポイント
通常情况下，读取或写入操作默认设置了超时以进行死锁检测。我们建议不要更改这个默认行为。
可靠收集是指采用System.Collection接口的分布式存储。
尝试实现有状态服务…
我查看了一下C#和Java的库，发现使用了一些根本不存在的类，而且作为复制的方法只有针对Actor的类。
此外，不同于StatelessService，虽然存在名为StatelessService的基类，但却没有名为StatefulService的基类。顺便提一下，虽然存在名为StatefulServiceBase的类，看起来明显是基类，但只实现了作为ActorService的实现。
简而言之，目前如果要自己创建有状态服务。
-
- 以Actor服务的形式来实现
-
- 努力实现类似于ActorStateManager的东西
- 我稍微看了一下里面的内容，他们似乎正努力实现它。
目前看来，似乎只有这个选择。真遗憾…
总结
尝试做Java上的Stateful Service，但是没成功，最后得出了这个结论。考虑为什么Java版本的SDK没有实现通用的Stateful Service，可以猜想可能是因为在Java中实现Reliable Collection非常困难。
在C#中，有一个与异步处理有关的语言规范，即async/await，可以被广泛地使用。然而，在Java中却没有类似的东西。基于这样的情况，我认为可能是因为这个原因，先实现了针对特定接口ActorStateManager的实现，而推迟了对Reliable Collection本身的实现。
实际上，如果在Actor和无状态服务以及Azure服务上进行持久化，似乎不会特别麻烦。
就这样吧，特别没有什么结尾的意思。
