将Service Fabric应用程序迁移到Azure Functions

Question

我目前有一个服务结构应用程序，由2个Asp.Net core WebApi-based stateless services组成，使用CosmosDb作为后端存储。这是针对文档数据库的基本CRUD操作。

由于我知道此应用程序将演变为更多的服务，并且可能还会进行其他直接的服务到服务的通信，因此我想知道迁移到基于Azure Functions的解决方案是否有意义。 还是这将迫使我走到一个角落，最终我发现Azure功能非常有限，并且针对非常不同的用例而设计。

是否有理由期望我可以将asp.net核心服务迁移到Azure功能，而只需对服务进行少量代码更改，还是我需要考虑进行完全重新设计以适应不同的编程模型？

并且由于Service Fabric Mesh现在处于公开预览状态，然后不久（希望）在某个时候发布GA，这对我来说是一个更好的解决方案吗？从sf到sf网格的迁移路径很简单。

Answer 1

将现有的asp.net api应用程序迁移到Azure Functions的工作程度将有所不同。将多个asp.net API项目迁移到Azure Functions后，我发现其核心逻辑在单独的层中实现的项目取得了最大的成功。如果您的Web API大量使用中间件层，依赖项注入或大量使用基于属性的过滤器，那么您将需要做一些工作，因为那些不能直接在Azure函数中转换。通常由中间层提供的复杂的身份验证和授权方案也常常是一个挑战。有一些社区项目提供了在功能中托管asp.net API的方法，但我对它们没有任何经验，它们当然不受MS支持。

关于问题的“我应该”部分，我认为您必须查看Azure Functions提供的好处（微型计费\缩放\ devops \ etc），并根据迁移的成本来衡量平台代码和潜在的功能损失。我是Azure Functions的大力支持者，但我不会考虑从Service Fabric这样的功能强大的平台进行迁移，而该服务平台实际上是微服务的理想选择，而无需进行此类评估。

Answer 2

您为什么考虑转向Azure功能？

如果您希望服务到服务的通信有所增加，我怀疑您应该从服务结构转移到Azure功能。因此，我不知道您的应用程序是什么，除非您可能拥有一个基于事件的完整应用程序，并且使用Azure Function可以降低Azure成本，否则转向Azure Function将不会受益。

要回答您的问题，您可能可以重用大多数代码，但是必须重新实现托管/部署以及服务之间的通信。