Azure Service Fabric编程模型的决策路径

Question

背景

我们正在考虑将“单片”3层Web应用程序移植到微服务架构中。 Web应用程序向消费者显示列表（想想Craiglist）。

后端包含一个REST API，它调用SQL DB并为SPA应用程序返回JSON以构建UI（还有一个移动应用程序）。数据通过后台服务（ftp + worker角色）写入SQL DB。还有一些页面允许用户写入。

所需信息：

我正在试图弄清楚如何（如果有的话），Azure Service Fabric将非常适合我的场景中的微服务架构。我知道微服务与monolith的优点/缺点，但我试图找出各种微服务编程模型的应用程序到我们当前的架构。

问题

• Azure Service Fabric是否适合这种情况？如果没有，其他建议？目前我倾向于一堆基于OWIN的.NET网站，按区域/服务分开，每个网站都在自己的机器上托管，并由API网关连接在一起。
• 我会选择哪种Service Fabric编程模型？无状态服务有自己的后备DB？我无法看到有状态或演员模型在这里会有什么帮助。
• 如果我使用有状态服务/ Actor，我将如何更新数据作为维护/临时管理请求的一部分？传统上我们只需登录到数据库并更新数据，API就会返回新数据 - 但如果它在内存中/跨群集中的节点持久存在，我们将如何更新它？我是否必须通过服务上的方法公开这一切？同样，我如何将现有SQL数据导入有状态服务？
• 对于有状态服务/演员模型，如何使用对象资源管理器/ UI以可视方式“查看”数据。我们的数据是我们的黄金，我担心在可靠的服务模式中缺乏对它的控制/可见性

基本上，决策路径上是否有一些文档需要针对哪些编程模型？我可以将“列表”建模为一个Actor，并拥有数百万个 - 当然，但我也可以拥有一个在本地存储列表的有状态服务，我也可以拥有一个从数据库中取出它的无状态服务。对于给定的用例，如何确定哪种方法最佳？

感谢。

Answer 1

您当前的设置不符合您的要求是什么？您希望从更复杂的架构中获得什么？

微服务不是一个神奇的子弹。您主要获得四项好处：

1. 您可以独立扩展和分发整个系统的各个部分。 Service Fabric具有非常复杂的工具和高级功能。
2. 您可以单独部署和升级整个系统的各个部分。 Service Fabric再次拥有先进的功能。
3. 您可以使用多语言系统 - 每个服务都可以使用不同的语言/平台编写。
4. 您可以使用冲突的依赖项 - 每个服务都可以拥有自己的一组依赖项，例如不同的框架版本。

所有这些都需要付出代价，并且会引入系统崩溃的复杂性和新方法。例如：您的快速编译时检查的in-proc方法调用现在变得很慢（与进程内函数调用相比）容易出现故障的网络调用。这些不特定于Service Fabric，顺便说一句，这就是从进程内方法调用到跨机器I / O的过程 - 无论你使用什么平台都无关紧要。这里的决策路径是一个特定于您的应用程序和您的要求的pro / con列表。

具体回答您的Service Fabric问题：

• 您选择哪种编程模型？从ASP.NET Core开始使用无状态服务。这将是您当前架构的最简单的翻译，不需要在您的数据层中使用。
• Stateful有很多很好的用途，但它不一定是你的RDBMS的替代品。一个好的起点是热数据，可以存储在简单的键值对中，经常访问，需要低延迟（你得到本地读取！），不需要数据。一些示例包括用户会话状态，缓存数据，数据流中最新项目的“快照”（如股票报价流中的最新股票报价）。
• 目前，查看或查询数据的唯一方法是以可编程方式直接针对Reliable Collection API。没有观众或“管理工作室”工具。您必须在每个可以显示和查询数据的服务中编写（并保护）API。
• 最后，演员模型是非常利基模型。它用于特定目的，但如果您只是将其视为数据存储，它将不适合您。在您的示例中，每个actor的列表可能不起作用，因为您无法在该列表中进行查询，或者甚至让多个用户同时阅读同一个列表。