Background
我们正在考虑将"整体式"3 层 Web 应用移植到微服务体系结构。Web应用程序向消费者显示列表(想想Craiglist)。
后端包含一个 REST API，该 API 调用 SQL 数据库并返回 SPA 应用的 JSON 以构建 UI(还有一个移动应用程序)。数据通过后台服务(ftp + 辅助角色)写入 SQL 数据库。还有一些页面允许用户写入。
所需信息：
我正在尝试弄清楚 Azure Service Fabric 如何(如果有的话)非常适合我的方案中的微服务体系结构。我知道微服务与单体的优缺点，但我正在尝试弄清楚各种微服务编程模型在我们当前架构中的应用。
问题
- Azure Service Fabric 是否适合此？如果没有，其他建议？目前，我倾向于一堆基于 OWIN 的 .NET 网站，这些网站按区域/服务划分，每个网站都托管在自己的机器上，并通过 API 网关绑定在一起。
- 我将选择哪种 Service Fabric 编程模型？具有自己的备份数据库的无状态服务？我看不出有状态或Actor模型在这里会有什么帮助。
- 如果我使用有状态服务/参与者，我将如何更新数据作为维护/临时管理员请求的一部分？传统上，我们只需登录到数据库并更新数据，API 将返回新数据 - 但如果它持久保存在内存中/跨集群中的节点，我们将如何更新它？我是否必须通过服务上的方法公开这一切？同样，如何将现有 SQL 数据导入有状态服务？
- 对于有状态服务/参与者模型，如何使用对象资源管理器/UI 直观地"查看"数据。我们的数据是我们的黄金，我担心在可靠的服务模型中缺乏对它的控制/可见性
基本上，是否有一些关于选择哪种编程模型的决策路径的文档？我可以将"列表"建模为 Actor，并拥有数百万个 - 当然，但我也可以有一个在本地存储列表的有状态服务，我也可以有一个从数据库中获取它的无状态服务。对于给定的用例，如何确定哪种方法是最佳方法？
谢谢。
您当前的设置有什么不符合您的要求？您希望从更复杂的架构中获得什么？
微服务不是灵丹妙药。您主要获得四个好处：
- 您可以独立扩展和分发整个系统的各个部分。Service Fabric 为此提供了非常复杂的工具和高级功能。
- 您可以独立部署和升级整个系统的各个部分。Service Fabric 再次为此提供了高级功能。
- 你可以有一个多语言系统 - 每个服务都可以用不同的语言/平台编写。
- 可以使用冲突的依赖项 - 每个服务都可以有自己的一组依赖项，例如不同的框架版本。
所有这些都是有代价的，并引入了复杂性和系统可能失败的新方式。例如：快速的编译时签入进程内方法调用现在变得缓慢(与进程内函数调用相比)容易出错的网络调用。顺便说一句，这些并不是特定于Service Fabric的，这只是从进程内方法调用到跨计算机I/O发生的情况 - 无论您使用什么平台。此处的决策路径是特定于您的应用程序和要求的利弊列表。
若要具体回答 Service Fabric 问题，请执行以下操作：
- 你选择哪种编程模型？从具有 ASP.NET Core 的无状态服务开始。这将是您当前架构的最简单翻译，不需要处理数据层。
- Stateful有很多很好的用途，但它不一定是RDBMS的替代品。一个好的起点是热数据，它可以存储在简单的键值对中，经常访问并且需要低延迟(你可以得到本地读取！)，并且不需要数据挖掘。一些示例包括用户会话状态、缓存数据、数据流中最新项目的"快照"(如股票报价流中的最新股票报价)。
- 目前，查看或查询数据的唯一方法是以编程方式直接针对可靠集合 API。没有查看器或"管理工作室"工具。您必须在每个服务中编写(并保护)一个可以显示和查询数据的 API。
- 最后，演员模型是一个非常小众的模型。它有特定的用途，但如果您只是将其视为数据存储，它将不适合您。就像在你的示例中一样，每个参与者的列表可能不起作用，因为您无法跨该列表进行查询，甚至无法让多个用户同时阅读同一列表。