Question

我正在处理已部署到Azure的Service Fabric应用程序。目前，它仅包含5个无状态服务。压缩后的档案大小约为200MB，这已经成为问题。

通过检查档案的内容，我可以看到主要问题是所有服务都需要许多文件。因此，每个服务的文件夹中都存在这些文件的精确副本。但是，对于压缩文件中的重复文件，zip压缩格式没有任何巧妙之处。

作为一个实验，我编写了一个小脚本来查找部署中的所有重复文件，并删除每个文件中的所有文件（除了其中一个）。然后，我尝试压缩结果，结果变得更加实用38MB。

我还注意到系统库是捆绑在一起的，包括：

System.Private.CoreLib.dll（12MB）
System.Private.Xml.dll（8MB）
coreclr.dll（5MB）

这些都是大文件，所以我想知道是否有一种方法可以将我的文件捆绑一次。我尝试完全删除它们，但是Service Fabric无法启动应用程序。

任何人都可以提供有关如何大幅减少部署程序包大小的建议吗？

注意：我已经阅读了compressing packages上的文档，但是对于为什么使用其压缩方法会有所帮助却感到非常困惑。确实，我尝试过但没有尝试过。他们所做的只是将每个子文件夹压缩在主zip文件中，但不会对所涉及的文件进行重复数据删除。

Answer 1

有一种减小包装尺寸的方法，但我想这不是一个好方法，也不是应该做的事情，但我仍然认为它可以在某些情况下使用案例。

请注意：此方法要求目标计算机已安装所有必备组件（包括.NET Core Runtime等）

构建.NET Core应用程序时，有两种部署模型：独立的和依赖于框架的。

在独立模式下，所有必需的框架二进制文件与应用程序二进制文件一起发布，而在与框架相关的情况下，仅应用程序二进制文件被发布。

默认情况下，如果项目在<RuntimeIdentifier>win7-x64</RuntimeIdentifier>中指定了运行时：.csproj，则发布操作是自包含的-这就是为什么您的所有服务都复制所有内容的原因。

要关闭此功能，您只需将SelfContained = false属性添加到您拥有的每个服务项目中即可。

以下是新的.NET Core无状态服务项目的示例：

<PropertyGroup>
  <TargetFramework>netcoreapp2.2</TargetFramework>
  <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
  <IsServiceFabricServiceProject>True</IsServiceFabricServiceProject>
  <ServerGarbageCollection>True</ServerGarbageCollection>
  <RuntimeIdentifier>win7-x64</RuntimeIdentifier>
  <TargetLatestRuntimePatch>False</TargetLatestRuntimePatch>
  <SelfContained>false</SelfContained>
</PropertyGroup>

我做了一个小测试，并创建了包含五个服务的新Service Fabric应用程序。调试中未压缩的程序包大小约为500 MB。在我修改了所有项目之后，程序包的大小降到了约30MB。

部署的应用程序在本地群集上运行良好，因此证明了此概念是减小程序包大小的有效方法。

最后，我将再次强调警告：

请注意：此方法要求目标计算机已安装所有必备组件（包括.NET Core Runtime等）

Answer 2

您通常不希望知道哪个节点运行哪个服务，并且想要彼此独立地部署服务版本，因此在其他情况下独立的服务之间共享二进制文件会产生非常不自然的运行时依赖性。我建议不要这样做，当然除了平台二进制文件（如AspNet和DotNet）。

但是，您是否了解有关创建差异包的信息？ https://docs.microsoft.com/en-us/azure/service-fabric/service-fabric-application-upgrade-advanced#upgrade-with-a-diff-package，这将在最初达到200MB时减小升级包的大小。

Answer 3

这是另一种选择： https://devblogs.microsoft.com/dotnet/app-trimming-in-net-5/

<SelfContained>True</SelfContained>
<PublishTrimmed>True</PublishTrimmed>

根据刚刚的快速测试，修剪一个应用程序将包大小从 ~110m MB 减少到 ~70MB（相比之下，selfcontained=false 为 ~25MB）。

不过，单个应用程序的修整过程需要几分钟，而我所从事的项目每个 Service Fabric 项目有 10-20 个应用程序。此外，我怀疑当您在代码中严重依赖依赖注入模型时，此过程并不安全。

对于调试版本，我们使用 SelfContained=False 因为开发人员将在他们的机器上拥有所需的运行时。但不适用于发布部署。

最后一点，因为 OP 提到文件上传是一个特定的瓶颈：

<块引用>

大部分部署时间只是压缩和上传包

我最近注意到，我们在构建管道期间上传工件时使用了已弃用的 Publish Build Artifacts task。上传 2GB 的文件需要 20 分钟。我切换了建议的 Publish Pipeline Artifact task 并将我们的发布步骤缩短到 10-20 秒。据我所知，它正在为这项新任务使用各种技巧来加速上传（和下载），包括文件重复数据删除。我怀疑此时自己压缩构建工件实际上会影响您的上传时间。

如何使Service Fabric包装尺寸实用？

3 个答案: