为 .NET Core 应用程序生成 Docker 映像

本教程重点介绍了如何在 Docker 上使用 .NET Core。 首先，我们探讨 Microsoft 维护和提供的各种不同的 Docker 映像，及其使用情况。 然后讲解了如何生成和 Docker 化 ASP.NET Core 应用。 在本教程中可学习： 了解 Microsoft.NET 核心 Docker 映像 获取用于 dockerize 的 ASP.NET Core 示例应用程序 在本地运行 ASP.NET 示例应用 使用 Docker for Linux 容器生成和运行示例 使用 Docker for Windows 容器生成和运行示例 Docker 映像优化 为开发人员生成 Docker 映像时，侧重于以下三种主要方案： 用于开发 .NET Core 应用的映像 用于生成 .NET Core 应用的映像 用于运行 .NET Core 应用的映像 为什么是三个映像？ 因为在开发、生成和运行容器化应用程序时，具有不同的优先级。 开发： 优先级注重循环访问更改的速度以及调试更改的能力。 与更改代码并且快速查看相比，映像的大小是否不是那么重要？ 生成： 此映像包含编译应用所需的所有内容，其中包括编译器和任何其他用于优化二进制文件的依赖项。 可使用生成映像创建置于生产映像中的资产。 生成映像用于持续集成或用于生成环境中。 此方法允许生成代理在生成映像实例中编译和生成应用程序（包括所有必需的依赖项）。 生成代理只需要了解如何运行此 Docker 映像即可。 生产： 部署和启动映像的速度可以有多快？ 此映像很小，因此从 Docker 注册表到 Docker 主机的网络性能得到了优化。 已准备运行内容，以此实现从 Docker 运行到处理结果的最快时间。 Docker 模型中不需要动态代码编译。 放置在此映像中的内容将限制为运行应用程序所需的二进制文件和内容。 例如，dotnet publish 输出包含： 已编译的二进制文件 .js 和 .css 文件 在生产映像中包括 dotnet publish 命令输出的原因是使生产映像保持最小大小。 某些 .NET Core 映像共享不同标记之间的层，因此下载最新标记是一个相对轻量的过程。 如果计算机上已有较早版本，此体系结构会降低所需的磁盘空间。 当多个应用程序在同一计算机上使用公共映像时，在公共映像之间共享内存。 映像必须相同才可共享。 Docker 映像变体 为了实现上述目标，我们在 microsoft/dotnet 下提供了映像变体。 microsoft/dotnet:<version>-sdk(microsoft/dotnet:2.1-sdk) 此映像包含带有 […]

View Details

Docker 容器、映像和注册表

使用 Docker 时，开发人员会创建一个应用或服务，并将它及其依赖项打包到一个容器映像中。 映像是应用或服务及其配置和依赖项的静态表示形式。 若要运行应用或服务，应用的映像会实例化，以创建一个在 Docker 主机上运行的容器。 最初，会在开发环境或 PC 中测试容器。 开发人员应将映像存储在注册表中，该注册表可充当映射库并在部署到生产业务流程协调程序时使用。 Docker 通过 Docker 中心维护公共注册表；其他供应商为不同映像集合提供注册表，包括 Azure 容器注册表。 或者，企业可以拥有一个本地专用注册表，用于其 Docker 映像。 图 2-4 显示了 Docker 中的映像和注册表与其他组件相关联的方式。 还显示了供应商的多个注册表产品/服务。 图 2-4。 Docker 术语和概念的分类 将映射存储到注册表中可存储静态和不可变的应用程序，包括其在框架级别的所有依赖项。 然后，这些映像可部署到多种环境中，并进行版本控制，从而提供一致的部署单元。 无论是托管在本地还是托管在云中，在下列情况下都建议使用专用映像注册表： 由于保密性，不能公开分享映像。 在映像和所选部署环境之间，希望网络延迟保持最低。 例如，如果生产环境是 Azure 云，为实现最低的网络延迟，可将映像存储在 Azure 容器注册表中。 同样，如果生产环境是在本地，便需要使本地 Docker 信任的注册表在相同的本地网络中可用。 from:https://docs.microsoft.com/zh-cn/dotnet/standard/microservices-architecture/container-docker-introduction/docker-containers-images-registries

View Details

Docker 术语

本节列出了在深入了解 Docker 之前应熟悉的术语和定义。 有关进一步的定义，请参阅 Docker 提供的详细术语表。 容器映像：包含创建容器所需的所有依赖项和信息的包。 映像包括所有依赖项（例如框架），以及容器运行时使用的部署和执行配置。 通常情况下，映像派生自多个基础映像，这些基础映像是堆叠在一起形成容器文件系统的层。 创建后，映像不可变。 Dockerfile：包含有关如何生成 Docker 映像的说明的文本文件。 与批处理脚本相似，首先第一行将介绍基础映像，然后是关于安装所需程序、复制文件等操作的说明，直至获取所需的工作环境。 生成：基于其 Dockerfile 提供的信息和上下文生成容器映像的操作，以及生成映像的文件夹中的其他文件。 可以使用 Docker 的“docker 生成”命令生成映像。 容器：Docker 映像的实例。 容器表示单个应用程序、进程或服务的执行。 它由 Docker 映像的内容、执行环境和一组标准指令组成。在缩放服务时，可以从相同的映像创建多个容器实例。 或者，批处理作业可以从同一个映像创建多个容器，向每个实例传递不同的参数。 卷：提供一个容器可以使用的可写文件系统。 由于映像只可读取，而多数程序需要写入到文件系统，因此卷在容器映像顶部添加了一个可写层，这样程序就可以访问可写文件系统。 程序并不知道它正在访问的是分层文件系统，此文件系统就是往常的文件系统。 卷位于主机系统中，由 Docker 管理。 标记：可以应用于映像的标记或标签，以便可以识别同一映像的不同映像或版本（具体取决于版本号或目标环境）。 多阶段生成：Docker 17.05 或更高版本的一个功能，可帮助减小最终映像的大小。 概括来说，借助多阶段生成，可以使用一个包含 SDK 的大型基础映像（以此为例）编译和发布应用程序，然后使用发布文件夹和一个小型仅运行时基础映像生成一个更小的最终映像 存储库 (repo)：相关的 Docker 映像集合，带有指示映像版本的标记。 某些存储库包含特定映像的多个变量，例如包含 SDK（较重）的映像，包含唯一运行时（较轻）的映像，等等。这些变量可以使用标记进行标记。 单个存储库中可包含平台变量，如 Linux 映像和 Windows 映像。 注册表：提供存储库访问权限的服务。 大多数公共映像的默认注册表是 Docker 中心（归作为组织的 Docker 所有）。 注册表通常包含来自多个团队的存储库。 公司通常使用私有注册表来存储和管理其创建的映像。 另一个示例是 Azure 容器注册表。 多体系结构映像：就多体系结构而言，它是一种根据运行 Docker 的平台简化相应映像选择的功能，例如当 Dockerfile 从注册表请求基础映像 FROM microsoft/dotnet:2.1-sdk 时，实际上它会获得 2.1-sdk-nanoserver-1709、2.1-sdk-nanoserver-1803 或 2.1-sdk-alpine，具体取决于操作系统和运行 Docker 的版本。 Docker Hub：上传并使用映像的公共注册表。 Docker 中心提供 Docker 映像托管、公共或私有注册表，生成触发器和 Web 挂钩，以及与 GitHub 和 Bitbucket 集成。 Azure 容器注册表：用于在 Azure 中使用 Docker 映像及其组件的公共资源。 这提供了接近 Azure 中部署的注册表，授予控制访问权限，使其可以使用 Azure Active Directory 组和权限。 Docker 受信任注册表 (DTR)：Docker 注册表服务（来自 Docker），可以安装在本地，因此它存在于组织的数据中心和网络中。 这对于应该在企业内部管理的私有映像来说很方便。 Docker 受信任注册表是 Docker 数据中心产品的一部分。 有关详细信息，请参阅 Docker 受信任注册表 […]

View Details

什么是 Docker？

Docker 是一种开源项目，用于将应用程序自动部署为可在云或本地运行的便携式独立容器。 Docker 也是一家公司，它与云、Linux 和 Windows 供应商（包括 Microsoft）协作，致力于推广和发展这项技术。 图 2-2。 Docker 在混合云的所有层部署容器 Docker 映像容器可以在 Linux 和 Windows 上本机运行。 但是，Windows 映像仅能在 Windows 主机上运行，Linux 映像可以在 Linux 主机和 Windows 主机上运行（到目前为止，使用 Hyper-V Linux VM），其中主机是指服务器或 VM。 开发人员可以在 Windows、Linux 或 macOS 上使用开发环境。 在开发计算机上，开发人员运行部署了 Docker 映像（包括应用及其依赖项）的 Docker 主机。 在 Linux 或 Mac 上进行开发的开发人员使用基于 Linux 的 Docker 主机，并且他们可以仅为 Linux 容器创建映像。 （在 Mac 上进行开发的开发人员可以从 macOS 中编辑代码或运行 Docker CLI，但截至撰写本文时，容器不在 macOS 上直接运行。）在 Windows 上进行开发的开发人员可以为 Linux 或 Windows 容器创建映像。 为了在开发环境中承载容器，并提供其他开发人员工具，Docker 为 Windows 或 macOS 提供了 Docker 社区版 (CE)。 这些产品安装了承载容器所需的 VM（Docker 主机）。 Docker 还提供 Docker 企业版 (EE)，该版本专为企业开发而设计，供生成、交付和在生产中运行大型业务关键型应用程序的 IT 团队使用。 若要运行 Windows 容器，有两种类型的运行时可供使用： Windows Server 容器通过进程和命名空间隔离技术提供应用程序隔离。 Windows Server 容器与容器主机和主机上运行的所有容器共享内核。 Hyper-V 容器通过在高度优化的虚拟机中运行各容器来扩展 Windows Server 容器提供的隔离。 在此配置中，容器主机的内核不与 Hyper-V […]

View Details

容器和 Docker 简介

容器化是软件开发的一种方法，通过该方法可将应用程序或服务、其依赖项及其配置（抽象化为部署清单文件）一起打包为容器映像。 容器化应用程序可以作为一个单元进行测试，并可以作为容器映像实例部署到主机操作系统 (OS)。 就像船只、火车或卡车运输集装箱而不论其内部的货物一样，软件容器充当软件部署的标准单元，其中可以包含不同的代码和依赖项。 按照这种方式容器化软件，开发人员和 IT 专业人员只需进行极少修改或不修改，即可将其部署到不同的环境。 容器还会在共享 OS 上将应用程序彼此隔离开。 容器化应用程序在容器主机上运行，而容器主机在 OS（Linux 或 Windows）上运行。因此，容器的占用比虚拟机 (VM) 映像小得多。 每个容器可以运行整个 Web 应用或服务，如图 2-1 所示。 在此示例中，Docker 主机是容器主机，而 App1、App2、Svc 1 和 Svc 2 是容器化应用程序或服务。 图 2-1. 在一个容器主机上运行多个容器 容器化的另一个优势在于可伸缩性。 通过为短期任务创建新容器，可以快速扩大。 从应用程序的角度来看，实例化映像（创建容器）类似于实例化 服务或 Web 应用等进程。 但出于可靠性考虑，在多个主机服务器上运行同一映像的多个实例时，通常要使每个容器（映像实例）在不同容错域中的不同主机服务器或 VM 中运行。 总而言之，容器在整个应用程序生命周期工作流中提供以下优点：隔离性、可移植性、灵活性、可伸缩性和可控性。 最重要的优点是可在开发和运营之间提供隔离。 from:https://docs.microsoft.com/zh-cn/dotnet/standard/microservices-architecture/container-docker-introduction/index

View Details

使用nginx-http-concat优化网站响应

前言： 我们在访问淘宝的时候，会看到代码中的js和css文件是通过一次请求或得的，我们知道浏览器一次请求只能并发访问数个资源，这样的处理错输在网络传输层面可以大大节省时间，这里使用的技术就是把css、js等静态资源合并为一个资源。淘宝使用的tengine是基于nginx的web服务器，从11年底开源。所使用的是mod_concat模块，合并多个文件在一个响应报文中。 http1.1下浏览器的并发访问资源数 IE6                                 2 IE7                                 2 IE8                                 6 Firefox2                          2 Firefox3                          6 Safari 3,4         […]

View Details

静态资源缓存控制编译工具

前不久在 知乎 上回答了一个问题：大公司里怎样开发和部署前端代码？。其中讲到了大公司在前端静态资源部署上的一些要求： 配置超长时间的本地缓存 —— 节省带宽，提高性能 采用内容摘要作为缓存更新依据 —— 精确的缓存控制 静态资源CDN部署 —— 优化网络请求 更资源发布路径实现非覆盖式发布 —— 平滑升级 其中比较复杂的部分就是 以文件的摘要信息为依据，控制缓存更新与非覆盖式发布 这个细节。因此基于 fis 包装了一个简单的命令行工具，并设立此项目，用于演示这部分功能。 这个工具基于 fis 的小工具是完全可以用作工程中的，有任何问题可以在 这里 留言。 请跟着下面的步骤来使用这个命令行小工具： 第一步：安装工具 这个命令行小工具依赖 nodejs 环境，因此，请先确保本地安装了它。 使用 nodejs 随带的 npm 包管理工具进行安装：

第二步：创建项目 在 命令行 下clone本仓库，或者自己创建一个新的项目，并进入：

在项目根目录下创建一个空的 fis-conf.js 文件，这是工具配置，什么都不用写，空着就行。 然后开始在项目目录下，随意创建或添加 页面、脚本、样式、图片、字体、音频、视频等等前端资源文件，正常写前端代码吧！ 第三步：发布代码 在项目根目录下执行：

然后去到 ../output 目录下去查看一下产出结果吧，所有静态资源都以md5摘要形式发布了出来，所有资源链接，我说 所有链接，包括html中的图片、样式、脚本以及js中的资源地址、css中的资源地址全部都加上了md5戳。 上述命令中，--md5 就是表示要给所有资源定位标记加上摘要信息的意思，不加这个参数就没有摘要信息处理。--dest ../output 表示把代码发布到当前目录上一级的output目录中。整个这条命令还可以简写成：

或者进一步连写成：

在本地服务器中浏览发布代码 你本地安装了诸如 Apache、Nginx、Lighttpd、IIS等服务器么？如果安装了，假设你的服务器 根目录 在 d:\wwwroot，你可以利用rsd工具的release命令，把代码发布过去，比如：

这样就把代码发布到了本地服务器根目录下，然后就可以在浏览器中查看效果了！ 如果你本地没有安装任何服务器，你可以使用rsd内置的调试服务器，执行命令：

接下来我们同样要把代码发布到这个内置服务器中，release命令如果省略 --dest <path>参数，就表示把代码发布到内置服务器的根目录下：

在浏览器中访问： http://localhost:8080 即可   一些小技巧 rsd集成了对很多前端编程语言的支持，包括： 类CSS语言：less, sass, scss, stylus 类JS语言：coffee-script 类HTML语言：markdown, jade 前端模板：handlebars-v1.3.0, EJS 内置了压缩器，在release的时候追加 -o 或者 --optimize 参数即可开启，压缩器包括： clean-css: 压缩所有类CSS语言代码 uglify-js: 压缩所有类JS语言代码 html-minifier: 压缩所有类HTML语言代码 还可以给资源加CDN域名，在release的时候追加 -D 或者 --domains 参数即可，域名配置写在fis-conf.js里：

所有常规代码中的资源定位接口都会经过工具处理，包括： 类CSS文件中： 背景图url font-face字体url ie特有的滤镜属性中的src 类JS文件中： 提供了一个叫 __uri('path/to/file') 的编译函数用于定位资源 类HTML文件中： link标签的href属性 script, img, video, audio, object 等标签的src属性 script标签中js代码里的资源定位标记 style标签中css代码里的资源定位标记 所有资源文件可以任意相互引用，工具会处理资源定位标记，使之服从知乎回答中提到的优化策略。 还提供了资源内嵌的编译接口，用于把一个资源的内容以文本、字符串或者base64的形式嵌入到 任意 一个文本文件中。 为了不用每次保存代码就执行一下release命令，工具中提供了文件监听和浏览器自动刷新功能，只要在release的时候在追加上 -w 和 -L 两个参数即可（注意L的大小写），比如：

关于这个小工具 它的原码在 这里。是的，就这么一点点代码，花了大概半小时写完的，因为一切都在 fis 中集成好了，我只是追加几个语言编译插件而已。   from:https://github.com/fouber/static-resource-digest-project

View Details

变态的静态资源缓存与更新

这是一个非常有趣的 非主流前端领域，这个领域要探索的是如何用工程手段解决前端开发和部署优化的综合问题，入行到现在一直在学习和实践中。 在我的印象中，facebook是这个领域的鼻祖，有兴趣、有梯子的同学可以去看看facebook的页面源代码，体会一下什么叫工程化。 接下来，我想从原理展开讲述，多图，较长，希望能有耐心看完。 让我们返璞归真，从原始的前端开发讲起。上图是一个“可爱”的index.html页面和它的样式文件a.css，用文本编辑器写代码，无需编译，本地预览，确认OK，丢到服务器，等待用户访问。前端就是这么简单，好好玩啊，门槛好低啊，分分钟学会有木有！ 然后我们访问页面，看到效果，再查看一下网络请求，200！不错，太™完美了！那么，研发完成。。。。了么？ 等等，这还没完呢！对于大公司来说，那些变态的访问量和性能指标，将会让前端一点也不“好玩”。 看看那个a.css的请求吧，如果每次用户访问页面都要加载，是不是很影响性能，很浪费带宽啊，我们希望最好这样： 利用304，让浏览器使用本地缓存。但，这样也就够了吗？不成！304叫协商缓存，这玩意还是要和服务器通信一次，我们的优化级别是变态级，所以必须彻底灭掉这个请求，变成这样： 强制浏览器使用本地缓存（cache-control/expires），不要和服务器通信。好了，请求方面的优化已经达到变态级别，那问题来了：你都不让浏览器发资源请求了，这缓存咋更新？ 很好，相信有人想到了办法：通过更新页面中引用的资源路径，让浏览器主动放弃缓存，加载新资源。好像这样： 下次上线，把链接地址改成新的版本，就更新资源了不是。OK，问题解决了么？！当然没有！大公司的变态又来了，思考这种情况： 页面引用了3个css，而某次上线只改了其中的a.css，如果所有链接都更新版本，就会导致b.css，c.css的缓存也失效，那岂不是又有浪费了？！ 重新开启变态模式，我们不难发现，要解决这种问题，必须让url的修改与文件内容关联，也就是说，只有文件内容变化，才会导致相应url的变更，从而实现文件级别的精确缓存控制。 什么东西与文件内容相关呢？我们会很自然的联想到利用 数据摘要要算法 对文件求摘要信息，摘要信息与文件内容一一对应，就有了一种可以精确到单个文件粒度的缓存控制依据了。好了，我们把url改成带摘要信息的： 这回再有文件修改，就只更新那个文件对应的url了，想到这里貌似很完美了。你觉得这就够了么？大公司告诉你：图样图森破！ 唉~~~~，让我喘口气 现代互联网企业，为了进一步提升网站性能，会把静态资源和动态网页分集群部署，静态资源会被部署到CDN节点上，网页中引用的资源也会变成对应的部署路径： 好了，当我要更新静态资源的时候，同时也会更新html中的引用吧，就好像这样： 这次发布，同时改了页面结构和样式，也更新了静态资源对应的url地址，现在要发布代码上线，亲爱的前端研发同学，你来告诉我，咱们是先上线页面，还是先上线静态资源？ 1.先部署页面，再部署资源：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本的资源当做新版本缓存起来，其结果就是：用户访问到了一个样式错乱的页面，除非手动刷新，否则在资源缓存过期之前，页面会一直执行错误。 2.先部署资源，再部署页面：在部署时间间隔之内，有旧版本资源本地缓存的用户访问网站，由于请求的页面是旧版本的，资源引用没有改变，浏览器将直接使用本地缓存，这种情况下页面展现正常；但没有本地缓存或者缓存过期的用户访问网站，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误，但当页面完成部署，这部分用户再次访问页面又会恢复正常了。 好的，上面一坨分析想说的就是：先部署谁都不成！都会导致部署过程中发生页面错乱的问题。所以，访问量不大的项目，可以让研发同学苦逼一把，等到半夜偷偷上线，先上静态资源，再部署页面，看起来问题少一些。 但是，大公司超变态，没有这样的“绝对低峰期”，只有“相对低峰期”。So，为了稳定的服务，还得继续追求极致啊！ 这个奇葩问题，起源于资源的覆盖式发布，用 待发布资源覆盖 已发布资源，就有这种问题。解决它也好办，就是实现非覆盖式发布。 看上图，用文件的摘要信息来对资源文件进行重命名，把摘要信息放到资源文件发布路径中，这样，内容有修改的资源就变成了一个新的文件发布到线上，不会覆盖已有的资源文件。上线过程中，先全量部署静态资源，再灰度部署页面，整个问题就比较完美的解决了。 所以，大公司的静态资源优化方案，基本上要实现这么几个东西： 1.配置超长时间的本地缓存 —— 节省带宽，提高性能 2.采用内容摘要作为缓存更新依据 —— 精确的缓存控制 3.静态资源CDN部署 —— 优化网络请求 4.更资源发布路径实现非覆盖式发布 —— 平滑升级 全套做下来，就是相对比较完整的静态资源缓存控制方案了，而且，还要注意的是，静态资源的缓存控制要求在 前端所有静态资源加载的位置都要做这样的处理 。是的，所有！什么js、css自不必说，还要包括js、css文件中引用的资源路径，由于涉及到摘要信息，引用资源的摘要信息也会引起引用文件本身的内容改变，从而形成级联的摘要变化，大概示意图就是： 好了，目前我们快速的学习了一下前端工程中关于静态资源缓存要面临的优化和部署问题，新的问题又来了：这™让工程师怎么写码啊！！！ 要解释优化与工程的结合处理思路，又会扯出一堆有关模块化开发、资源加载、请求合并、前端框架等等的工程问题，以上只是开了个头，解决方案才是精髓，但要说的太多太多，有空再慢慢展开吧。 总之，前端性能优化绝逼是一个工程问题！ 以上不是我YY的，可以观察 百度 或者 facebook 的页面以及静态资源源代码，查看它们的资源引用路径处理，以及网络请中静态资源的缓存控制部分。再次赞叹facebook的前端工程建设水平，跪舔了。 建议前端工程师多多关注前端工程领域，也许有人会觉得自己的产品很小，不用这么变态，但很有可能说不定某天你就需要做出这样的改变了。而且，如果我们能把事情做得更极致，为什么不去做呢？ 另外，也不要觉得这些是运维或者后端工程师要解决的问题。如果由其他角色来解决，大家总是把自己不关心的问题丢给别人，那么前端工程师的开发过程将受到极大的限制，这种情况甚至在某些大公司都不少见！ 妈妈，我再也不玩前端了。。。。5555   业界实践 Assets Pipeline Rails中的Assets Pipeline完成了以上所说的优化细节，对整个静态资源的管理上的设计思考也是如此，了解rails的人也可以把此答案当做是对rails中assets pipeline设计原理的分析。 rails通过把静态资源变成erb模板文件，然后加入<%= asset_path 'image.png' %>，上线前预编译完成处理，fis的实现思路跟这个几乎完全一样，但我们当初确实不知道有rails的这套方案存在。 相关资料： 英文版：http://guides.rubyonrails.org/asset_pipeline.html 中文版：http://guides.ruby-china.org/asset_pipeline.html FIS的解决方案 用 F.I.S 包装了一个小工具，完整实现整个回答所说的最佳部署方案，并提供了源码对照，可以感受一下项目源码和部署代码的对照。 源码项目：https://github.com/fouber/static-resource-digest-project 部署项目：https://github.com/fouber/static-resource-digest-project-release 部署项目可以理解为线上发布后的结果，可以在部署项目里查看所有资源引用的md5化处理。 这个示例也可以用于和assets pipeline做比较。fis没有assets的目录规范约束，而且可以以独立工具的方式组合各种前端开发语言（coffee、less、sass/scss、stylus、markdown、jade、ejs、handlebars等等你能想到的），并与其他后端开发语言结合。 assets pipeline的设计思想值得独立成工具用于前端工程，fis就当做这样的一个选择吧。   from:https://www.cnblogs.com/minigrasshopper/p/7694053.html

View Details

前端工程精粹（一）：静态资源版本更新与缓存

每个参与过开发企业级web应用的前端工程师或许都曾思考过前端性能优化方面的问题。我们有雅虎14条性能优化原则，还有两本很经典的性能优化指导书：《高性能网站建设指南》、《高性能网站建设进阶指南》。经验丰富的工程师对于前端性能优化方法耳濡目染，基本都能一一列举出来。这些性能优化原则大概是在7年前提出的，对于web性能优化至今都有非常重要的指导意义。 然而，对于构建大型web应用的团队来说，要坚持贯彻这些优化原则并不是一件十分容易的事。因为优化原则中很多要求是与工程管理相违背的，比如“把css放在头部”和“把js放在尾部”这两条原则，我们不能让团队的工程师在写样式和脚本引用的时候都去修改一个相同的页面文件。这样做会严重影响团队成员间并行开发的效率，尤其是在团队有版本管理的情况下，每天要花大量的时间进行代码修改合并，这项成本是难以接受的。因此在前端工程界，总会看到周期性的性能优化工作，辛勤的前端工程师们每到月圆之夜就会倾巢出动根据优化原则做一次性能优化。 本文从一个全新的视角来思考web性能优化与前端工程之间的关系，通过解读百度前端集成解决方案小组（F.I.S）在打造高性能前端架构并统一百度40多条前端产品线的过程中所经历的技术尝试，揭示前端性能优化在前端架构及开发工具设计层面的实现思路。 性能优化原则及分类 笔者先假设本文的读者是有前端开发经验的工程师，并对企业级web应用开发及性能优化有一定的思考，因此我不会重复介绍雅虎14条性能优化原则。如果您没有这些前续知识，请移步这里来学习。 首先，我们把雅虎14条优化原则，《高性能网站建设指南》以及《高性能网站建设进阶指南》中提到的优化点做一次梳理，按照优化方向分类，可以得到这样一张表格： 优化方向 优化手段 请求数量 合并脚本和样式表，CSS Sprites，拆分初始化负载，划分主域 请求带宽 开启GZip，精简JavaScript，移除重复脚本，图像优化 缓存利用 使用CDN，使用外部JavaScript和CSS，添加Expires头，减少DNS查找，配置ETag，使AjaX可缓存 页面结构 将样式表放在顶部，将脚本放在底部，尽早刷新文档的输出 代码校验 避免CSS表达式，避免重定向 表格1 性能优化原则分类 目前大多数前端团队可以利用yui compressor或者google closure compiler等压缩工具很容易做到“精简Javascript”这条原则；同样的，也可以使用图片压缩工具对图像进行压缩，实现“图像优化”原则。这两条原则是对单个资源的处理，因此不会引起任何工程方面的问题。很多团队也通过引入代码校验流程来确保实现“避免css表达式”和“避免重定向”原则。目前绝大多数互联网公司也已经开启了服务端的Gzip压缩，并使用CDN实现静态资源的缓存和快速访问；一些技术实力雄厚的前端团队甚至研发出了自动CSS Sprites工具，解决了CSS Sprites在工程维护方面的难题。使用“查找-替换”思路，我们似乎也可以很好的实现“划分主域”原则。 我们把以上这些已经成熟应用到实际生产中的优化手段去除掉，留下那些还没有很好实现的优化原则。再来回顾一下之前的性能优化分类： 优化方向 优化手段 请求数量 合并脚本和样式表，拆分初始化负载 请求带宽 移除重复脚本 缓存利用 添加Expires头，配置ETag，使Ajax可缓存 页面结构 将样式表放在顶部，将脚本放在底部，尽早刷新文档的输出 表格2 较难实现的优化原则 现在有很多顶尖的前端团队可以将上述还剩下的优化原则也都一一解决，但业界大多数团队都还没能很好的解决这些问题。因此，本文将就这些原则的解决方案做进一步的分析与讲解，从而为那些还没有进入前端工业化开发的团队提供一些基础技术建设意见，也借此机会与业界顶尖的前端团队在工业化工程化方向上交流一下彼此的心得。 静态资源版本更新与缓存 如表格2所示，“缓存利用”分类中保留了“添加Expires头”和“配置ETag”两项。或许有些人会质疑，明明这两项只要配置了服务器的相关选项就可以实现，为什么说它们难以解决呢？确实，开启这两项很容易，但开启了缓存后，我们的项目就开始面临另一个挑战：如何更新这些缓存。 相信大多数团队也找到了类似的答案，它和《高性能网站建设指南》关于“添加Expires头”所说的原则一样——修订文件名。即： 最有效的解决方案是修改其所有链接，这样，全新的请求将从原始服务器下载最新的内容。 思路没错，但要怎么改变链接呢？变成什么样的链接才能有效更新缓存，又能最大限度避免那些没有修改过的文件缓存不失效呢？ 先来看看现在一般前端团队的做法： 或者 大家会采用添加query的形式修改链接。这样做是比较直观的解决方案，但在访问量较大的网站，这么做可能将面临一些新的问题。 通常一个大型的web应用几乎每天都会有迭代和更新，发布新版本也就是发布新的静态资源和页面的过程。以上述代码为例，假设现在线上运行着index.html文件，并且使用了线上的a.js资源。index.html的内容为： 这次我们更新了页面中的一些内容，得到一个index.html文件，并开发了新的与之匹配的a.js资源来完成页面交互，新的index.html文件的内容因此而变成了：   好了，现在要开始将两份新的文件发布到线上去。可以看到，index.html和a.js的资源实际上是要覆盖线上的同名文件的。不管怎样，在发布的过程中，index.html和a.js总有一个先后的顺序，从而中间出现一段或大或小的时间间隔。对于一个大型互联网应用来说即使在一个很小的时间间隔内，都有可能出现新用户访问。在这个时间间隔中，访问了网站的用户会发生什么情况呢？ 如果先覆盖index.html，后覆盖a.js，用户在这个时间间隙访问，会得到新的index.html配合旧的a.js的情况，从而出现错误的页面。 如果先覆盖a.js，后覆盖index.html，用户在这个间隙访问，会得到旧的index.html配合新的a.js的情况，从而也出现了错误的页面。 这就是为什么大型web应用在版本上线的过程中经常会较集中的出现前端报错日志的原因，也是一些互联网公司选择加班到半夜等待访问低峰期再上线的原因之一。此外，由于静态资源文件版本更新是“覆盖式”的，而页面需要通过修改query来更新，对于使用CDN缓存的web产品来说，还可能面临CDN缓存攻击的问题。我们再来观察一下前面说的版本更新手段： 我们不难预测，a.js的下一个版本是“1.0.1”，那么就可以刻意构造一串这样的请求“a.js?v=1.0.1”、“a.js?v=1.0.2”、……让CDN将当前的资源缓存为“未来的版本”。这样当这个页面所用的资源有更新时，即使更改了链接地址，也会因为CDN的原因返回给用户旧版本的静态资源，从而造成页面错误。即便不是刻意制造的攻击，在上线间隙出现访问也可能导致区域性的CDN缓存错误。 此外，当版本有更新时，修改所有引用链接也是一件与工程管理相悖的事，至少我们需要一个可以“查找-替换”的工具来自动化的解决版本号修改的问题。 对付这个问题，目前来说最优方案就是基于文件内容的hash版本冗余机制了。也就是说，我们希望工程师源码是这么写的： 但是线上代码是这样的： 其中”_82244e91”这串字符是根据a.js的文件内容进行hash运算得到的，只有文件内容发生变化了才会有更改。由于版本序列是与文件名写在一起的，而不是同名文件覆盖，因此不会出现上述说的那些问题。同时，这么做还有其他的好处： 线上的a.js不是同名文件覆盖，而是文件名+hash的冗余，所以可以先上线静态资源，再上线html页面，不存在间隙问题； 遇到问题回滚版本的时候，无需回滚a.js，只须回滚页面即可； 由于静态资源版本号是文件内容的hash，因此所有静态资源可以开启永久强缓存，只有更新了内容的文件才会缓存失效，缓存利用率大增； 修改静态资源后会在线上产生新的文件，一个文件对应一个版本，因此不会受到构造CDN缓存形式的攻击 虽然这种方案是相比之下最完美的解决方案，但它无法通过手工的形式来维护，因为要依靠手工的形式来计算和替换hash值，并生成相应的文件。这将是一项非常繁琐且容易出错的工作，因此我们需要借助工具。我们下面来了解一下fis是如何完成这项工作的。 首先，之所以有这种工具需求，完全是由web应用运行的根本机制决定的：web应用所需的资源是以字面的形式通知浏览器下载而聚合在一起运行的。这种资源加载策略使得web应用从本质上区别于传统桌面应用的版本更新方式。为了实现资源定位的字面量替换操作，前端构建工具理论上需要识别所有资源定位的标记，其中包括： css中的@import url(path)、background:url(path)、backgournd-image:url(path)、filter中的src js中的自定义资源定位函数，在fis中我们将其规定为__uri(path)。 html中的<script src=”path”>、<link href=”path”>、<imgsrc=”path”>、已经embed、audio、video、object等具有资源加载功能的标签。 为了工程上的维护方便，我们希望工程师在源码中写的是相对路径，而工具可以将其替换为线上的绝对路径，从而避免相对路径定位错误的问题（比如js中需要定位图片路径时不能使用相对路径的情况）。 fis的资源定位设计思想 fis有一个非常棒的资源定位系统，它是根据用户自己的配置来指定资源发布后的地址，然后由fis的资源定位系统识别文件中的定位标记，计算内容hash，并根据配置替换为上线后的绝对url路径。 要想实现具备hash版本生成功能的构建工具不是“查找-替换”这么简单的。我们考虑这样一种情况： 资源引用关系 由于我们的资源版本号是通过对文件内容进行hash运算得到，如上图所示，index.html中引用的a.css文件的内容其实也包含了a.png的hash运算结果，因此我们在修改index.html中a.css的引用时，不能直接计算a.css的内容hash，而是要先计算出a.png的内容hash，替换a.css中的引用，得到了a.css的最终内容，再做hash运算，最后替换index.html中的引用。 这意味着构建工具需要具备“递归编译”的能力，这也是为什么fis团队不得不放弃gruntjs等task-based系统的根本原因。针对前端项目的构建工具必须是具备递归处理能力的。此外，由于文件之间的交叉引用等原因，fis构建工具还实现了构建缓存等机制，以提升构建速度。 在解决了基于内容hash的版本更新问题之后，我们可以将所有前端静态资源开启永久强缓存，每次版本发布都可以首先让静态资源全量上线，再进一步上线模板或者页面文件，再也不用担心各种缓存和时间间隙的问题了！ 在本系列的下一部分，我们将介绍静态资源管理与模板框架的思路和用法。 作者简介：张云龙，百度公司Web前端研发部前端集成解决方案小组技术负责人，目前负责F.I.S项目，读者可以关注他的微博：http://weibo.com/fouber/。   from:http://www.infoq.com/cn/articles/front-end-engineering-and-performance-optimization-part1

View Details