【问题标题】：Migrating a Service Fabric app to Azure Functions将 Service Fabric 应用迁移到 Azure Functions
【发布时间】：2019-01-17 19:12:23
【问题描述】：
我目前有一个由 2 个Asp.Net core WebApi-based stateless services 组成的服务结构应用程序，使用 CosmosDb 作为后端存储。它是关于对文档数据库的基本 CRUD 操作。
由于我知道这个应用程序将演变成更多的服务，并且可能会产生更多的直接服务间通信，我想知道迁移到基于Azure Functions 的解决方案是否有意义。
或者这是否会迫使我进入一个角落，最终我会发现 Azure Functions 非常有限，并且是为非常不同的用例而设计的。
是否可以期望我只需对服务进行少量代码更改就可以将我的 asp.net 核心服务迁移到 Azure Functions，或者我是否需要考虑完全重新设计以适应不同的编程模型？
而且由于Service Fabric Mesh 现在是公开预览版，然后某个时候（希望）很快就会发布，这对我来说会是一个更好的解决方案吗？从 sf 到 sf 网格的迁移路径是微不足道的。
【问题讨论】：
标签：
c#
azure
azure-functions
azure-service-fabric
【解决方案1】：
将现有的 asp.net api 应用程序迁移到 Azure Functions 需要付出不同程度的努力。将几个 asp.net API 项目迁移到 Azure Functions 后，我发现核心逻辑在单独层中实现的项目最成功。如果您的 Web API 大量使用中间件层、依赖项注入或大量使用基于属性的过滤器，那么您还有一些工作要做，因为这些工作不会直接在 azure 函数中进行转换。通常由中间层提供的复杂身份验证和授权场景通常也是一个挑战。有一些社区项目提供了在函数中托管 asp.net API 的方法，但我对它们没有任何经验，它们当然不受 MS 支持。
关于问题的“我应该”部分，我认为您必须查看 Azure Functions 提供的好处（微计费\缩放\devops\等），并根据迁移成本衡量这一点平台的代码和潜在的功能损失。我是 Azure Functions 的忠实拥护者，但如果不进行此类评估，我不会考虑从 Service Fabric 这样一个功能强大的平台迁移，它实际上是微服务的理想选择。
【解决方案2】：
您为什么考虑转向 Azure Functions？
如果您预计服务间通信会有所增长，我怀疑您是否应该从服务结构迁移到 Azure Function。因此，在不了解您的应用程序的情况下，我相信您不会受益于迁移到 Azure Function，除非您可能拥有一个完整的基于事件的应用程序并且使用 Azure Function 可以降低您的 Azure 成本。
要回答您的问题，您可能可以重用大部分代码，但您必须重新实现托管/部署和服务之间的通信。