Azure 服务结构使用
Azure Service Fabric usage
Service Fabric 刚刚在构建大会上宣布。我正在阅读有关它的稀缺文档，但我有一个问题。
我正在评估 Service Fabric 以托管目前内置于 ASP.NET WebApi 中的微服务之类的 CRUD。
Service Fabric 是否适合托管接收数据、处理数据并return结果的小块功能，而不是托管 CRUD WebApi 类型的应用程序？
此视频回答了我自己的问题：http://channel9.msdn.com/Events/Build/2015/2-704。总之，我们应该使用无状态服务来托管基于 ASP.NET 的站点或 API 的站点，这些站点将数据持久保存到外部数据存储。
如果您没有状态（或外部有状态），无状态服务是开始的方式。
原问题的答案是"both"。基本上，任何具有 main() 函数的东西（有几个更扩展的契约方法来与 Service Fabric 对话）都可以是 Service Fabric 世界中的服务。
Service Fabric 支持创建无状态和有状态微服务。
顾名思义，如果节点出现故障，由无状态服务实例维护的任何状态都将丢失。一个新的实例将在集群的其他地方简单地启动。
有状态服务提供了在不依赖外部存储的情况下保持状态的能力。存储在 Reliable Collection 中的任何数据都将自动复制到集群中的多个节点，确保状态对故障具有弹性。
一种常见的模式是使用无状态服务作为应用程序面向客户端的网关，然后让该服务将流量定向到应用程序的分区有状态服务。这隐藏了从客户端解析分区的工作，允许它们将所有请求定位到一个逻辑端点。
查看 WordCount sample 以了解其工作原理的示例。 WordCount.WebService 无状态服务充当应用程序的前端。它只是根据传入的请求解析分区，然后继续发送。 WordCount.Service 有状态服务（根据单词的第一个字母进行分区）立即将这些传入请求放入 ReliableQueue 中，然后在后台处理它们，将结果存储在 ReliableDictionary 中。
有关详细信息，请参阅 Reliable Services Overview。
注意：目前，向客户端公开 WebAPI 端点的最佳方式是在无状态服务中自行托管 OWIN 服务器。 ASP.NET 5 个项目也将很快得到支持。
Service Fabric 刚刚在构建大会上宣布。我正在阅读有关它的稀缺文档，但我有一个问题。
我正在评估 Service Fabric 以托管目前内置于 ASP.NET WebApi 中的微服务之类的 CRUD。
Service Fabric 是否适合托管接收数据、处理数据并return结果的小块功能，而不是托管 CRUD WebApi 类型的应用程序？
此视频回答了我自己的问题：http://channel9.msdn.com/Events/Build/2015/2-704。总之，我们应该使用无状态服务来托管基于 ASP.NET 的站点或 API 的站点，这些站点将数据持久保存到外部数据存储。
如果您没有状态（或外部有状态），无状态服务是开始的方式。
原问题的答案是"both"。基本上，任何具有 main() 函数的东西（有几个更扩展的契约方法来与 Service Fabric 对话）都可以是 Service Fabric 世界中的服务。
Service Fabric 支持创建无状态和有状态微服务。
顾名思义，如果节点出现故障，由无状态服务实例维护的任何状态都将丢失。一个新的实例将在集群的其他地方简单地启动。
有状态服务提供了在不依赖外部存储的情况下保持状态的能力。存储在 Reliable Collection 中的任何数据都将自动复制到集群中的多个节点，确保状态对故障具有弹性。
一种常见的模式是使用无状态服务作为应用程序面向客户端的网关，然后让该服务将流量定向到应用程序的分区有状态服务。这隐藏了从客户端解析分区的工作，允许它们将所有请求定位到一个逻辑端点。
查看 WordCount sample 以了解其工作原理的示例。 WordCount.WebService 无状态服务充当应用程序的前端。它只是根据传入的请求解析分区，然后继续发送。 WordCount.Service 有状态服务（根据单词的第一个字母进行分区）立即将这些传入请求放入 ReliableQueue 中，然后在后台处理它们，将结果存储在 ReliableDictionary 中。
有关详细信息，请参阅 Reliable Services Overview。
注意：目前，向客户端公开 WebAPI 端点的最佳方式是在无状态服务中自行托管 OWIN 服务器。 ASP.NET 5 个项目也将很快得到支持。