大公司里怎样开发和部署前端代码？
fouber opened this issue · 179 comments
本文搬运自我在知乎上 同名问题 中的答案。
这是一个非常有趣的 非主流前端领域，这个领域要探索的是如何用工程手段解决前端开发和部署优化的综合问题，入行到现在一直在学习和实践中。
在我的印象中，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地址，现在要发布代码上线，亲爱的前端研发同学，你来告诉我，咱们是先上线页面，还是先上线静态资源？
先部署页面，再部署资源：在二者部署的时间间隔内，如果有用户访问页面，就会在新的页面结构中加载旧的资源，并且把这个旧版本的资源当做新版本缓存起来，其结果就是：用户访问到了一个样式错乱的页面，除非手动刷新，否则在资源缓存过期之前，页面会一直执行错误。先部署资源，再部署页面：在部署时间间隔之内，有旧版本资源本地缓存的用户访问网站，由于请求的页面是旧版本的，资源引用没有改变，浏览器将直接使用本地缓存，这种情况下页面展现正常；但没有本地缓存或者缓存过期的用户访问网站，就会出现旧版本页面加载新版本资源的情况，导致页面执行错误，但当页面完成部署，这部分用户再次访问页面又会恢复正常了。
好的，上面一坨分析想说的就是：先部署谁都不成！都会导致部署过程中发生页面错乱的问题。所以，访问量不大的项目，可以让研发同学苦逼一把，等到半夜偷偷上线，先上静态资源，再部署页面，看起来问题少一些。
但是，大公司超变态，没有这样的“绝对低峰期”，只有“相对低峰期”。So，为了稳定的服务，还得继续追求极致啊！
这个奇葩问题，起源于资源的 覆盖式发布，用 待发布资源 覆盖 已发布资源，就有这种问题。解决它也好办，就是实现 非覆盖式发布。
看上图，用文件的摘要信息来对资源文件进行重命名，把摘要信息放到资源文件发布路径中，这样，内容有修改的资源就变成了一个新的文件发布到线上，不会覆盖已有的资源文件。上线过程中，先全量部署静态资源，再灰度部署页面，整个问题就比较完美的解决了。
所以，大公司的静态资源优化方案，基本上要实现这么几个东西：
- 配置超长时间的本地缓存 —— 节省带宽，提高性能
- 采用内容摘要作为缓存更新依据 —— 精确的缓存控制
- 静态资源CDN部署 —— 优化网络请求
- 更资源发布路径实现非覆盖式发布 —— 平滑升级
全套做下来，就是相对比较完整的静态资源缓存控制方案了，而且，还要注意的是，静态资源的缓存控制要求在 前端所有静态资源加载的位置都要做这样的处理 。是的，所有！什么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就当做这样的一个选择吧。
一直对fis了解的模模糊糊的。通过fouber最近几篇慢慢理解fis具体在做什么了，也学到了很多少见的干货。
期待持续更新好文。
示例的链接搬错了。
今天把几篇文章详细阅读了几遍，加上前几天的面授，受益良多
fuck things!
点赞
👍
@fouber
请教一个问题：
我们项目使用的是PHP开发但模板引擎不是 Smarty。
这种情况如何利用fis帮助我实现检测文件修改后自动更新对应资源路径。
File "src/photo/img.jpg" changed.
Create "src/photo/img_XmsD8daS.jpg" .
Replace :
<img src=\"src/photo/img_8sDuxSma.jpg\" > ==> <img src=\"src/photo/img_XmsD8daS.jpg\" >
background-image:url("src/photo/img_8sDuxSma.jpg") ==> background-image:url("src/photo/img_XmsD8daS.jpg")
Update: http//static.cdn.com/src/photo/img_8sDuxSma.jpg
如何不要求后端做任何修改的情况下完成自动检测修改-复制修改资源并加上md5后缀-更新资源。
https://github.com/fouber/static-resource-management-system-demo
可以参考一下这个样例，有完整的运行起来的方案
你的理解非常非常正确。
前端架构大部分工作要解决的是 如何用工具连接框架和规范的问题。这是一个工程问题。fis想解决的正是规范与框架的链接问题，而不是简单的前端源码构建。
所谓框架，主要指模块化框架，其职责包括对模块化资源的管理和加载，管理包括js/css的依赖管理，加载包括按需加载和请求合并，以及资源缓存与更新。
所谓规范，主要是指开发和部署规范，比如哪些是模块化资源，哪些是非模块化资源，模块化资源如何包装、优化和部署，非模块化资源如何部署等，什么文件发布到什么目录，是否有CDN等等。
框架、规范、工具三者需要紧密配合才能比较完美的解决模块化开发、性能优化等前端工程问题。
fis本身是一种特殊的 “工具”，通过一些比较 “奇怪” 的配置设计，实现了框架与规范的绑定过程。这些问题我觉得是grunt/gulp不曾思考过的。
fis的解决方案，包括你看到的rsd，还有 scrat，其实都是对fis的配置，每一套配置用于连接一种特定的规范和框架：
- fis-plus：以smarty为模板引擎，以 mod 为模块化框架，适用于php后端渲染及部署运维方式的解决方案。
- yogurt：以swig为模板引擎，以 mod 为模块化框架，适用于nodejs后端渲染架构及部署运维方式的解决方案
- jello：以velocity为模板引擎，以 mod 为模块化框架，适用于java后端渲染架构及部署运维方式的解决方案
- pure：无后端渲染，使用前端模板，以 mod 为模块化框架，适用于纯前端，前后端严格分类的项目
- gois：go语言解决方案。
- spmx：纯前端方案，以seajs为模块化框架，一个示例项目，不完整，不要用于生产
- rsd：纯粹是为了展示静态资源md5问题的项目，把fis所有的语言插件都装上，可以在一个项目里混合多种语言进行开发，用资源内嵌实现打包，可以认为是最简易的fis，不适合大规模生产。
- scrat：以 scrat.js 为模块化框架，内含webapp、seo、olpm三种模式，其中：
- webapp是纯前端解决方案，依赖combo服务实现资源合并，适用于中型移动端单页面应用。
- seo是多页面模式，以swig为模板引擎，进行后端渲染，支持quickling（或者pjax），以combo服务合并资源，面向需要seo的单页面应用。
- olpm是运营后台模板开发模式，我们内部有一个CMS，可以用这种模式进行开发，本地预览，然后把代码打包上传到cms系统，作为专题模板使用。
总之，由于前端的开发环境、开发模式、部署方式实在是太五花八门了，有传统多页面模式，有移动端SPA模式，有CMS组件化拼装模式，不同的模式还可能会结合不同的后端语言（不要以为前端可以完全从后端剥离出来，不理解其中的原理，我可以单独写一篇文章说明），所以不可能有一种固定模式能解决所有问题，fis的设计就是把所有这些模式中的公共部分抽取出来形成一个基础工具，面对不同开发部署规范、不同模块化框架再做配置即可。
所有不同的前端开发模式，有一些相同的内在联系，那就是：资源定位，资源内嵌和资源依赖这三种语言能力。这三种语言能力为什么会成为所有开发模式的共性，这和前端这种特殊的GUI软件的安装和运行方式有关，后面再另开文章讲解吧，这里就不再解释了。
在我理解，yo属于脚手架工具吧，而我说的连接主要是指：
“在开发目录中的什么文件，将来要部署到什么集群上，框架中要做哪些处理” 这样的事情，也就是连接开发规范、部署规范和模块化框架的工作。三者是需要工具进行转换的。
要实现一个完整的模块化开发体系，我觉得需要有一个工具做这些事情：
- 对模块化资源进行扫描，获取资源依赖关系，生成依赖表，注入到模块化框架中供依赖管理、按需加载、合并请求等优化使用（资源依赖，用于连接框架）
- 接收一种配置，标记每种类型的文件会发布到什么目录或集群中，然后扫描所有文件中的资源定位标记，将其替换成部署路径（资源定位，用于连接开发和部署规范）
- 允许一些资源并不是通过模块化方式加载，而是直接内嵌到其他资源中使用，比如把图片以base64形式嵌入到css、js中（资源内嵌，非必须，但很有用）
以上三件事并不是yo的工作。下面图解一下这几件事：
1.所谓工具连接框架
连接框架就是工具把静态分析的依赖关系以某种形式传递给框架，用于框架在运行时的资源管理、加载及优化
2.所谓工具连接规范（连接的是开发规范和部署规范）
给一个配置文件，告诉工具，源码中的什么文件(用reg匹配)部署后会发布到哪里(release定义)，这样，工具会把源码中所有关于这个资源的定位标记替换成部署路径。实现开发时使用工程路径，构建后使用部署路径的功能。这个功能可以保证资源的独立性，并且能对性能做优化（加md5戳）。独立性可以让资源无论是被合并、移位还是在其他地方加载都能正常运行。
不使用fis 通过其他工具能达到这样的效果嘛？
占座围观
assets pipeline?
百度有考虑用angularjs么？
angularjs感觉对CRUD类产品比较合适，但百度的很多产品并非这种类型的，而且很多产品每天千万甚至几亿的访问量，如果放一个angularjs，不但每次研发部署后用户重新下载资源的性能大打折扣，而且很多业务的前端场景并不能很好的覆盖angular的功能，不能充分发挥它的价值，进一步浪费带宽。
所以，一般不太喜欢在页面上放一个几百K的，但只使用其中20%功能的前端框架，大家都恨不得量体裁衣。目前在业内能找到angular应用场景的项目，感觉大多集中在 ( pc端的 || 非核心功能的 || 后台管理系统类的 || 访问量小的 ) 页面上，我感觉百度也有团队在用，只是在一些我们没有很关注的某个页面的角落里而已。
有没有类似fis管理静态文件的开源软件。
原来是这样，技术放在大场景里要考虑这么多，这么细~
angular虽然是google的，但是现在google也没有几个产品在用，但是打算用angular替代一些主要业务。观察它的发展吧~
类似fis的专注管理前端静态资源的“软件”目前貌似没有同类，因为静态资源管理是一个结合开发框架、开发规范和部署规范的过程，并不是一个独立的软件完成的。如果提供了资源管理，绝大多数情况下要提供前/后端框架，并且定义开发规范，这是必然结果。
虽然没有独立软件，但类似的解决方案倒是有的，就是Rails的assets pipeline，相关资料：
英文版：http://guides.rubyonrails.org/asset_pipeline.html
中文版：http://guides.ruby-china.org/asset_pipeline.html
这些我在这篇blog中有提到的
grunt貌似也提供了相关的插件：http://segmentfault.com/blog/jiyinyiyong/1190000000442070
恩，只是貌似
我在这里 #5 列出了md5计算的过程，并且说明了为什么grunt这种task-based的调度控制非常难完美实现md5的原因，包括md5的递归计算、coffee/less等文件的编译之后资源定位等问题，下面也有一些讨论。
目前一直在用grunt工具处理前端资源的打包和压缩，遇到的问题确实如楼主所言的那样，停留在URL中添加版本控制。现在也在考虑MD5文件戳的方式，也一直在查找之类的工具，前段时间看到了grunt-usemin， 它对HTML的静态资源的处理很优雅，整合了常用的grunt的插件，这是典型的YO风格。今天看到rsd和fis的处理方式，确实是目前所期望的，:smiley_cat:
mark
@fouber 请教一个问题：
业务场景：
使用AJAX获取打折商品列表配合 handlebars 渲染。如果模板中需要定位CDN部署资源，如何实现？(模板也是通过AJAX获取的，不使用CSS background )
模板内容：
<!-- http://www.domain.com/tpl/goods.tpl -->
{{#list}}
<div class="box">
<img src="/src/img/sale.jpg" alt="特价" class="sale">
{{name}} ￥{{price}}
</div>
{{#list}}把图片变成模板变量，在js中定位资源，渲染模板的时候传进去
var tpl = __inline('tpl.handlebars');
var data = {...};
data.image = __uri('/src/img/sale.jpg');
var html = tpl(data);
console.log(html);感谢。 最近工作中遇到一些前端后端联调的问题，准备通过在前端的角度**“多做事”**解决问题。但没有实践过望 fouber 指点。
问题：
- 前端交付 HTML 给后端后因为 HTML 逻辑复杂导致后端无法按预期格式输出。（后端渲染后的页面和前端页面代码不一致）
- 为了方便修改页面需要分公用头底。后端不了解页面中 HTML 的细节，哪些公用哪些不公用。导致HTML转换为后端模板后无法按预期格式输出。
例如：<?php include "common/header.php"; ?>的header.php包含了<link>和<script>，而<link>和<script>在不同页面中href和src都不一样。
解决方案：
前端在前端开发环境（node）中编写兼容后端模板语法的模板，并模拟数据源进行渲染。先上示例：
数据源
{
list:[
{
title: '标题1',
name: '张三'
},
{
title: '标题2',
name: '李四'
}
],
listid:[
1,2,3,4,5,6,7
],
userid: false
}模板文件
<!-- /example/include.html -->
<?php include "common/header.php"; ?>
content
<br><br>
{{#userid}}
您的用户ID是{{userid}}
{{/userid}}
{{^userid}}
<a href="/login/">请登录</a>
{{/userid}}
<br><br>
{{#list}}
<ul>
<li>{{title}}:{{name}}</li>
</ul>
{{/list}}
任务列表：
{{#listid}}
<input name="listid[]" type="checkbox" value="{{.}}" >{{.}}
{{/listid}}
<hr>
<!--{layout:example/sidebar.html}-->
<?php include "common/footer.php"; ?>详细说明
前端开发环境是用 node 开发的服务器，拥有rewriteRule staticWriteReplace connect中间件 AJAX数据模拟等功能。这样前端可以模拟任何数据。而此时我只需使用 staticWriteReplace 这个功能。
// 静态资源替换 - Static write replace
staticWriteReplace: function (file, req, res) {
// file = {
// pathname: pathname ( example/index.html )
// dirname: dirname (example/)
// data: filedata ( <!DOCTYPE html> <html lang="en"> <head> ... </html> )
// }
// 实现 <?php include "common/header.php"; ?> 功能
file.data = file.data.replace(/<\?php (include|require) ["]([^"]+)"; \?>/g, function () {
var sPath = arguments[2],
fs = require('fs');
if (!/\.php$/.test(sPath)) {
sPath = sPath + '.php';
}
var sFileData = fs.readFileSync(__dirname + file.dirname + sPath, 'utf-8', function (err, data) {
return data;
})
return sFileData
})
// 实现<!--{layout:example/sidebar.html}-->
// 省略
// 实现 Mustache 语法的模板引擎
if (file.pathname === '/example/include.html'){
var Mustache = require('./_nodeajax/lib/mustache');
file.data = Mustache.render(file.data,{
list:[
{
title: '标题1',
name: '张三'
},
{
title: '标题2',
name: '李四'
}
],
listid:[
1,2,3,4,5,6,7
],
userid: false
})
}
}此处使用的是 Mustache ，最终会使用 smarty 作为前端环境和后端框架的模板引擎。利用 https://www.npmjs.com/package/nsmarty 让node 只支持 smarty 。
此时 http://127.0.0.1:18081/example/include.html 显示效果如下：
前端开发工作完成后直接交付模板而不是交付 HTML ，后端同事只需按照数据源的说明文档提供数据
**总结：**前端开发工作包括页面模板引擎渲染的开发工作，并利用开发环境和约定使前端开发出来的模板可以直接被后端框架使用。（前端通过开发环境模拟数据源用 类似 nsmarty 的库来兼容 smarty）此时后端工程师只需要提供真实数据支持。
**分析：**以 MVC 来看，后端在 View 的工作只是按照前端HTML输出数据，直接让前端控制 View 的输出形式让后端在 C 层面提供真实数据源的输出。
**我的疑惑：**虽然我感觉前端控制 View 的渲染和 AJAX 结合handlebars 做渲染类似。从来没有试过前端控制 V 的数据模拟和渲染，担心交付代码时因为前端对后端的不了解导致变成多此一举。
小公司，没开发体系和前人建议，也没能力做彻底的node前后端分离。想结合公司环境想做一些增加工作效率的事。望 fouber 指点
- 如果后后端渲染页面，最终都要走向前端写后端模板的方式，不应该有“前端写静态页面，后端将其模板化”这种过程，所以，你的思路是对的。
- rewriteRule模块设计的很好，fis的一种解决方案中也设计了这个实现，使得工程师可以完全脱离后端环境，在本地渲染页面，并且url路由是一致的
- 用nodejs渲染php模板，恐怕是一个很深的坑，其实想实现本地开发，不一定非要使用nodejs，fis有内置的java-php服务器，可以帮助实现这个效果。用nodejs把php翻译成handlebars不能完整对应，在fis的基础上写一个支持php模板本地开发的方案并不困难。
- 关于静态资源，不推荐使用原生的script或者link标签，而是写一个后端的模块化资源管理框架，可以参考这个例子： https://github.com/fouber/fis-php-md.js 把这个例子跑一下，可以了解一下另外一种优雅的做法
刚跟后端开完会，决定由前端指定模板引擎。准备使用 mustache 来保证前后端模板引擎的语法一致。完全由前端控制 View 的显示。
用 nodejs 渲染PHP模板的原因是想让前端很方便的在 node 中编写测试代码。
我们的前端的node开发环境中包含AJAX模拟等其他功能所以没有用 PHP 直接渲染，而是依然依赖 node。
我先试下 mustache 应用到项目中的的实际效果如何
再次感谢 fouber 让我少走很多弯路。
对于使用RequireJS，文件被碎片化很厉害，合并成单文件或两三个文件，会导致每次即便改动一两行的更新都需要重新下载，如果不合并随便访问一个页面就需要加载几百个文件，这类问题有解决办法吗？
对于楼上这个问题,确实很麻烦,只能根据情况考虑了~
http://webpack.github.io
这个能解决你的需求
Sent from my iPhone
On Mar 6, 2015, at 23:39, Elson notifications@github.com wrote:
对于使用RequireJS，文件被碎片化很厉害，合并成单文件或两三个文件，会导致每次即便改动一两行的更新都需要重新下载，如果不合并随便访问一个页面就需要加载几百个文件，这类问题有解决办法吗？
—
Reply to this email directly or view it on GitHub.
恩，这是一个很实在的问题。打包有一些策略，比如高频修改的，跟低频修改的分开打包，使得合并之后的资源总体失效率降低。静态打包最终极的策略是根据统计来动态调整打包方案，这个需要与日志系统、模块化系统结合，根据每个页面的pv、页面与页面之间的访问关系以及每个页面的模块使用情况来最终确定打包策略，这种方式才是资源合并的终极形态。
@fouber
比如使用nginx-http-concat 后统计到 jquery/1.11.1/jquery.min.js 在80%的js文件请求都存在时，jquery 不打包合并。jquery单独加载？
文件修改的频率是一种线下开发的概念，并不是合并的统计。
线下开发过程中，每个版本迭代文件修改的统计是一种统计，用于分别高频修改文件和低频修改文件。
还有一种是模块化资源加载的统计，这个并不是统计谁和谁合并，而是统计每个页面都用了哪些资源，这些页面之间的访问路径是怎样的等等，基于这些统计，可以做一个简单的排序计算，从而确定打包策略。
举个简单的例子，我们有A、B两个页面，其中：
- A页面用了资源 a, b, c, d
- B页面用了资源 a, b, c, e, f
如果AB是两个独立的页面，那么我们可以用nginx-http-concat服务，让A页面加载 a,b,c,d的combo，让B页面加载a,b,c,f,e的combo
但是，如果AB页面有跳转关系呢？想象一下A页面是搜索引擎首页，B页面是搜索结果页。很明显很多来到首页的用户，接下来90%以上的可能性是要搜索关键词，然后来到B页面，那么，我们可以通过统计数据看到，B页面有很多请求是来自A页面的，这个时候，我们就有理由将A、B页面共同的静态资源进行合并打包，得到：
- A页面使用combo：a,b,c 和 d
- B页面使用combo：a,b,c 和 e,f
之前，用户访问A页面之后再去访问B页面，会重复加载a,b,c这个资源，现在，我们将a,b,c独立出来，用户浏览的时候就能有资源复用，由A跳转到B，只加载e,f，由B返回A，只加载d。
基于全站的页面访问+资源引用统计，还能看到更多有价值的合并策略，这些是分析独立页面所看不到的
赞，能做到这点的确需要精益求精的专业精神。
在 2015年3月10日 上午12:18，张云龙 notifications@github.com写道：
@nimojs https://github.com/nimojs
文件修改的频率是一种线下开发的概念，并不是合并的统计。
线下开发过程中，每个版本迭代文件修改的统计是一种统计，用于分别高频修改文件和低频修改文件。
还有一种是模块化资源加载的统计，这个并不是统计谁和谁合并，而是统计每个页面都用了哪些资源，这些页面之间的访问路径是怎样的等等，基于这些统计，可以做一个简单的排序计算，从而确定打包策略。
举个简单的例子，我们有A、B两个页面，其中：
- A页面用了资源 a, b, c, d
- B页面用了资源 a, b, c, e, f
如果AB是两个独立的页面，那么我们可以用nginx-http-concat服务，让A页面加载
a,b,c,d的combo，让B页面加载a,b,c,f,e的combo但是，如果AB页面有跳转关系呢？想象一下A页面是搜索引擎首页，B页面是搜索结果页。很明显很多来到首页的用户，接下来90%以上的可能性是要搜索关键词，然后来到B页面，那么，我们可以通过统计数据看到，B页面有很多请求是来自A页面的，这个时候，我们就有理由将A、B页面共同的静态资源进行合并打包，得到：
- A页面使用combo：a,b,c 和 d
- B页面使用combo：a,b,c 和 e,f
之前，用户访问A页面之后再去访问B页面，会重复加载a,b,c这个资源，现在，我们将a,b,c独立出来，用户浏览的时候就能有资源复用，由A跳转到B，只加载e,f，由B返回A，只加载d。
基于全站的页面访问+资源引用统计，还能看到更多有价值的合并策略，这些是分析独立页面所看不到的
—
Reply to this email directly or view it on GitHub
#6 (comment).
sfsdf
感谢两位 @Duan112358 @fouber 提示:)
方便说下插图是什么软件做的吗
菜鸟取经。。。
不错，不错！
Awesome!
mark
mark
mark
取经··
非覆盖刷新，如果一个页面反复修改，岂不是会产生很多很多的过期文件，留着？还是作何处理？
留着就好了，基于统计一年清理一次也没问题。实际冗余量都没多少的。
发自我的 iPhone
在 2015年9月23日，18:43，smlie123 notifications@github.com 写道：
非覆盖刷新，如果一个页面修改，岂不是会产生很多很多的过期文件，留着？还是作何处理？
—
Reply to this email directly or view it on GitHub.
在这里请教一个问题，如果是前端 + 后端（Java）项目，前端的代码如何在构建完之后发布到后端的Java web工程环境。麻烦谁给解答一下
fis能做到这一点吗？ 或者说，怎么来做到，流程是怎样的
Java构建环境，一般是使用Maven或者Ant，前端构建工具一般是使用Grunt，依赖Node.js，然后与CI持续集成环境结合到项目最终发布。这里的衔接是怎么处理的。还有，解决缓存问题的话，好像还需要改变HTML中的前端资源访问路径，这些fis能处理吗？
@majianxiong
我之前写过一个例子： https://github.com/fouber/fis-java-jsp 你可以参考一下，原理我在许多地方都有提到。
@fouber 好的，谢谢
@majianxiong
你可以不用完整运行这个demo，只是看一下我在示例中写的 jsp页面代码 ，然后大概猜猜一下示例中扩展的tag做了什么事情，应该就不难想象fis的工作原理了。
对于jsp标签的扩展部分，源码在这里： https://github.com/fouber/fis-java-resource
@majianxiong
java版资源管理最核心的部分在这里： https://github.com/fouber/fis-java-resource/blob/master/src/com/baidu/fis/Resource.java
@fouber 谢谢，呵呵，正在看的
@fouber ,非常感谢分享，学习了，请教一个问题，如何把之前不再用的静态文件删除呢？谢谢
这个问题，大致要分两种情况讨论：
- 使用了CDN缓存
- 未使用CDN缓存
首先我们先看看非覆盖式发布的部署方式，假设我们把静态资源部署到线上服务器的webroot目录下，第一次发版，其内文件为：
─ webroot
├─ foo.82068b6.js
└─ bar.c1e6b0e.js
接下来版本迭代，产生了新的资源文件需要部署上线，再假设待部署的文件是：
─ release
├─ foo.5899c6d.js
└─ bar.1d163de.js
如果你的项目使用了CDN缓存
由于CDN可以缓存大部分静态资源，所以部署新版本的时候，你可以考虑只部署一份内容，将之前的线上代码直接备份后删除，然后将新的代码部署到webroot下，这样，你的线上部署的结果始终只有一份：
─ webroot # 部署无冗余
├─ foo.5899c6d.js
└─ bar.1d163de.js
这种做法有一个小漏洞，就是部署过程中，如果用户访问旧页面请求了一个很『冷』的资源，在CDN上恰好无缓存需要回源时，由于你的源服务器只保留一个版本，最终会导致资源加载不到而页面报错，但由于出现这种问题的概率比较低，可以忽略不计。
这种部署策略可以让你不用烦恼冗余部署的清理问题
如果你的项目没使用CDN缓存
没有CDN缓存，我们一般也会把静态资源部署到独立的静态资源服务器上，这个时候可以利用服务器的缓存功能可以暂时保留当前版本，这种情况下也可以如使用了CDN缓存一样只保留单一版本。
如果没有任何缓存支持，而项目又是多集群部署的话，静态资源就需要冗余了：
─ webroot # 部署有冗余
├─ foo.82068b6.js
├─ foo.5899c6d.js
├─ bar.c1e6b0e.js
└─ bar.1d163de.js
这种情况下，需要求助运维同学写清理脚本，定期清理。清理的策略主要是根据文件名收集冗余版本，然后根据创建日期保留最近2个版本，其他文件都清理掉。
这里不由得让我想起webpack，webpack在处理资源定位上用了一个讨巧的办法，把所有资源目录层级去掉，展平了放在一起，这种设计对构建工具来说实现很方便，不用保留原始路径，但最终部署的时候会导致一个目录下部署太多静态资源文件，如果再结合多版本冗余部署，最终会对系统读写文件的性能造成一定的影响。
@John-Tingjun
因为代码都压缩了，冗余文件不会太多。在没有运维同事的情况下尽量不要自己清除。
@fouber ,谢谢您的耐心解答，我们正在尝试使用FIS，谢谢！
@fouber
近期在关注FIS，有个问题咨询下，望指导一二：
如下现状：
css代码有一个重构部门集中维护，以shtml的公共脚本方式引入(nginx)
公共脚本文件：也是通过shtml方式引入
如果代码是在公司的平台上开发，发布，那服务器已经做到了资源的定位，以及文件名摘要的变更，对于引入方来说，引入的永远是shtml文件，由服务器nginx直接解析定位到资源。
不知道FIS能否解决以下问题
问题1：
自己本地开发，又想引入css脚本，或者公共的js脚本。如果是直接引入shtml的话，本地调试是无法直接解析的。（FIS能否解决直接替换html中的shtml引入格式为其内容，调试的时候可不关注具体内容）
目前自己的解决办法是，简历2套模版一套是线上的shtml引入格式，一套是dev使用的，通过打包环境的配置，发布成针对开发调试的版本或者针对线上发布的版本
开发模版内容：
<script type="text/javascript" src="http://static/*/jquery-1.11.1.min.js?t=@@timestamp"></script>生产模版内容：
然后在html中用一个标记标明，在打包的时候替换为相应环境的内容
更好来说能否直接把html中的shtml直接通过请求替换成其真实内容，且只是初次替换
问题2：
FIS是否提供制作多份环境的打包配置，比如说通过命令行指定环境，就可以打包某个环境的包，配合监控，自动刷新
伪代码：fis deply dev/gamma/prd
FIS能否解决直接替换html中的shtml引入格式为其内容，调试的时候可不关注具体内容?
这个是可以自己编写 插件 进行实现的。
问题2 其实也都是可以实现的，如果有哪些功能不是 FIS 本身提供的，方可以自己码插件，这还是很方便的。
在大家在想 FIS能不能解决xxx问题？的时候，其实可以换个角度，我要怎么利用FIS 实现xxx功能/解决xxx问题 ？。这样的话，那都不是事儿了~~
@jincdream 如果有现成解决方案最好，没有的话就只能自己实现了。因为这些我现在都是利用webpack+gulp实现的。就是要不断的找插件，FIS是一站的啊
@lovesmilesha 我个人眼里的 FIS 其实是一个骨架（最近觉得它还是臃肿了点，想把它真正的"骨架化"），FIS 并不能帮你解决各种棘手的问题，但它给你提供了解决问题的工具，例如在编译各个阶段开放接口，让其他人可以订制各种功能。
而且每个公司、团队的环境不一样，除非你想把团队打造得跟别人一样，否则也就不太可能用同样的（现成的）解决方案去解决自己的工程问题吧，但是可以用类似的解决方案的。
插件化的时代其实正在......
@fouber ，Hi 云龙，请教您个问题，我现在用FIS3作为构建工具，利用FIS3自动部署，可以吧静态资源(css,js picture)部署到另外一台服务器上，问题是，在html文件中，我、怎么能把引用的静态文件路径比如/static/js/a.js，改成http://xxx:81/js/a.js(静态资源单独使用一个站点进行部署), 望指教，谢谢！
fis.media('prod').match('*.js', {
domain: 'http://cdn.baidu.com/'
});
后通过 fis3 release prod -d ./output 后 __RESOURCE_MAP__ 的内容就会加上 domain前缀、
如果你要在后端模板引擎中引用这些加了md5的js文件就需要在模板引擎中增加个插件。
可参考这个项目：
Github:fis-fms-php
在线示例
关键是要实现这个函数
function _src($path) {
$json = file_get_contents('../output/view/map.json');
$json = json_decode($json, true);
if (isset($json['res'][$path]['uri'])) {
echo $json['res'][$path]['uri'];
}
else {
echo $path .'不存在';
}
}https://github.com/nimojs/fis-fms-php/blob/master/mock/index.php
@nimojs ,谢谢您的回复，利用您说的domain完美解决.
读瓶神文章，受益匪浅
👍 好文，知道故事的來龍去脈了
@fouber @nimojs , 请教一个问题，如果js 文件中用到了图片路径，那么在FIS3 发布时怎么把图片路径改成发布的路径呢(静态资源使用了CDN进行独立部署, 和程序没有在一起)？ 问题的起源是，我用的requirejs做的模块化，有2个静态html header.html & footer.html(文件里面有引用图片), 然后我先用了r.js对依赖项进行了压缩和合并，html 和 js 都合并到一个js 文件中了，这时候我再用fis3 进行发布，怎样能把 r.js build 出来的js 文件中的路径也改了呢？ 谢谢
我也有看咱们FIS3提供了模块化开发插件，但是当我使用时也发现了2个问题
- build 出来的 aio.js 文件没法使用， 这个文件开头是“;define” , 即时我把第一个分号去掉也会报"define is not defined"
- build 出来的新文件 aio.js文件没有包含我的静态资源文件内容 header.html and footer.html
望指导，谢谢。
@John-Tingjun https://github.com/fex-team/fis3/blob/master/doc/docs/user-dev/uri.md
//源码:
var img = __uri('images/logo.gif');
//编译后
var img = '/images/logo_74e5229.gif';在js中嵌入其他文本文件:
https://github.com/fex-team/fis3/blob/master/doc/docs/user-dev/inline.md
//源码
var css = __inline('a.css');
//编译后
var css = "body \n{ color: red;\n}";使用了 hook module的话，会对isMod:true属性的js文件进行自动包裹define。
如果单纯只是对 FIS3 有问题，可以去开 issue的：
https://github.com/fex-team/fis3/issues
@fouber 文章又啃了一遍。
现在我们这边有个更头痛的问题：
CMS静态页面如何开发和部署前端代码？
如果进行了 html 文件的修改，那就要发布十几二十万，甚至几百万的静态页面。
感觉除了将其做成动态模板输出之外没其他办法，这个发布和部署之后的修改代码真是头疼的问题。~
@jincdream
静态页面可以写 md 转 html 的工具。也就是你说的自己做一个动态模板。
可以参考这个项目的 https://github.com/nimojs/css-tips fis-conf.json
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="UTF-8">
<title>{{title}}</title>
<link rel="stylesheet" href="/static/bootstrap.min.css">
<link rel="stylesheet" href="/static/github.css">
<style>
body {
padding-left:10px;
padding-right:10px;
}
</style>
</head>
<body>
{{include "/nav.md"}}
<hr>
{{{content}}}
</body>
</html>webpack也很强大。。。好吧 。。感觉像是自己是来 踢馆的
那个。。。大家如果没有什么问题或者见解的话能不能不要发诸如：
受益匪浅
受教了
感谢分享
等等这些评论。。。notification里面被你刷屏刷得很混乱啊。。。（虽然这也是一条没有营养的comment。。)
@KIDJourney 你可以直接关闭通知啊
@dd1994 关闭通知就看不到有用的回复了。
相当赞的文章，感觉看了之后有一种醍醐灌顶的感觉。 虽然没有用过FIS，最近因为使用react，在使用webpack，webpack实现了包括资源依赖，资源_md5，资源合并，小图片base64内嵌等功能， 感觉跟楼主是一个思路。
👍
又仔细看了一下 里面确实提到rails了 怪不得第一次看的时候感觉那么的熟悉呢 ，The Asset Pipeline基本上 就是这样做的吧 可以看作是解决方案
很赞的文章，是否可以分享一下前后端单独上线的解决方案
目前在准备做这块，没有什么好的思路
不错，正在学习中。
我想问个问题：
文中提到的http://static.xxx.com/，实际开发中可能是放在本地的http://192.168.x.x/，怎样在发布测试或者上线的时候替换成http://test.xxx.com/或http://cdn.xxx.com/
构建工具切换的，在开发阶段构建的时候，产出的结果是 /blabla，上线前的构建，添加了domain，得到的结果是 http://static.xxx.com/blabla
@fouber
我的意思是http://192.168.x.x/是本地的一个库，可能多个项目都会用到它，所以在本地的时候就已经是用绝对路径找的了，不知道FIS3有没有解决方案。或者只能像楼上面说的通过其他手段
我看了下百度首页，有个问题需要请教。
在chrome下强制刷新（Ctrl + F5），百度的很多资源依旧从Cache里面加载的.
比如 logo https://www.baidu.com/img/bd_logo1.png
不知如何实现。
mark
@fouber 以文件的摘要信息为依据，控制缓存更新与非覆盖式发布 这个在Java端如何处理
@fouber 已经想到办法实现了
@fouber 强制浏览器使用本地缓存（cache-control/expires），这个地方的最佳设置能不能说明一下，谢谢
请教一下，如何对不同的前端资源images，JS，CSS进行 ETag、Cache-Control 设置呢
同文～～～～
在 2016年3月10日，上午11:34，majianxiong notifications@github.com 写道：
请教一下，如何对不同的前端资源images，JS，CSS进行 ETag、Cache-Control 设置呢
—
Reply to this email directly or view it on GitHub #6 (comment).