### 引言

对于一个工程师而言，不仅要有过硬的自身本领，还要有一定的技术影响力。当我们解决一个问题之后，如何在团队中顺利的推广并落地，也同样重要。接下来，想给大家分享一下，我在团队中推广一项技术解决方案的全过程。

### 问题的出现

年前的时候，我们团队对 [Odin一站式](http://odin.xiaojukeji.com/) 的**微前端**方案进行了改造和升级。最早是通过 `iframe` 来完成这一方案的。

iframe 作为一个非常 “古老” 的，人人都觉得普通的技术，却一直很管用。它能有效地将另一个网页/单页面应用嵌入到当前页面中，两个页面间的 CSS 和 JavaScript 是相互隔离的——除去 iframe 父子通信部分的代码，它们之间的代码是完全不相互干扰的。iframe 便相当于是创建了一个全新的独立的宿主环境，类似于沙箱隔离，它意味着前端应用之间可以相互独立运行。

但是 iframe 不够灵活。它会使路由、历史记录和深层链接变得更加复杂，并且很难做成响应式页面。

于是，团队决定使用 `Web Components` 的方案来替代 iframe。

Web Components 是一套不同的技术，允许开发者创建可重用的定制元素（它们的功能封装在代码之外），并且在 web 应用中使用它们。

![avatar](http://img-hxy021.didistatic.com/static/way/do1_5GEBaCJbfKEhnkNXUBui)

我们上线这一方案之后遇到一个问题：用户刷新浏览器之后没有看到系统的更新。由于我们注册子服务时，使用的是一个不带哈希 `js` 文件来注册的。而代理层对于这部分静态资源的缓存策略是会缓存下来的。这种死文件名的方式就使得缓存的问题重新暴露了出来，用户使用我们的系统时，需要强制刷新或者不使用缓存，才能看到系统更新的内容。

当然，也可以让接入层设置不缓存所有文件。但是这样的话每次都需要请求所有文件，十分影响性能。而且需要频繁修改Nginx的配置，会增加跨部门协作的成本。可能就将一个简单的问题复杂化了。

### 获得灵感

本着 **“我一定不是第一个遇到这个问题的人”** 的思想，一个技术问题一般会有如下的解决方案：

- 1、google 搜索
- 2、当一个伸手党
- 3、开源社区提问
- 4、探究原理，明白到底发生了什么
- 5、看源码，尝试自己解决

其实，前3个方式都是提问，只是方式不同罢了。但是如果可以问对人，那么一定是最快的方式。

而我这次可以解决这个技术难题，也源自我参加了2020年1月11日Node party线下分享。阿里的流司分享的主题，就是[《⾯向B端⼯作台的微前端⽅案-ConsoleOS》](https://github.com/aliyun/alibabacloud-console-os)。在分享结束的时候，我向他提出了我的疑问。他们的方案中是使用 `manifest` 来解决一个入口，多个文件的问题的。`manifest.json` 中，可以保存子系统多版本的所有资源文件。这样的话，只需要写死一个入口，里面的资源文件就可以加上哈希后缀，从而解决这一问题。

### 解决问题

第二天，我就冲到公司，对主系统和子系统进行了改造。折腾了一天之后，就完成了这个方案的第一版：使用 `manifest.json` 作为入口文件，加载子系统。

![avatar](http://img-hxy021.didistatic.com/static/way/do1_V4W5LLVsea5qyUGnKpYM)

在推行这个方案的时候，起初是没有被采纳的。原因如下：

- 演示不够具有说服力。Demo 中只能演示上图的加载过程，并没有完整的演示缓存问题的解决。
- 跨部门协作成本较大。接入层的缓存策略一般是不缓存 `index.html` ，`manifest.json`也是会缓存的，这个方案需要接入层调整代理配置，代价较大。
- 方案不具备通用性。每一个子系统在打包的时候，命令和配置不是完全一样的。这个方案不一定适用于每个子系统。
- 风险不可控。方案中没有考虑到测试，到上线各个阶段的注意点。访问的链路增加，是否会影响性能？子系统发布之后，是否会影响到一站式，和老系统的使用？
- 没有通俗易懂的文档。

### 让你方案变得可靠

工程师的真正价值就是把未知变成已知的能力。但是一个想法从知道，到实际落地，还是存在一定距离的。

- 1、探究原理。在这个过程中，我做的第一件事，还是去了解这个问题发生的根本原因，了解 [HTTP 缓存](https://developer.mozilla.org/zh-CN/docs/Web/HTTP/Caching_FAQ) 的原理。

![avatar](http://img-hxy021.didistatic.com/static/way/do1_qCBbJqdxr7gz8zj9x5RJ)

- 2、降低跨部门协作成本。在明白原理并与后端同学沟通之后，明白接入层不会缓存 `index.html` 这个高频更新的文件，于是就优化了链路。

![avatar](http://img-hxy021.didistatic.com/static/way/do1_EJdAVxuVs1kCseBT22zr)

- 3、让方案变得通用。接下来，就需要明确各个系统的接入层缓存配置，并且对几个典型的系统进行改造，发到测试环境。
- 4、让方案可以兼容各个阶段。上线的时候，所有系统的更新会有先有后。在打包子系统的时候，不仅会生成新系统需要的 `manifest.json`，还会生成老版本一站式所需要的 `entry.js` 文件。让整个升级变得更加平滑，不会出现系统不可用的情况。
- 5、健全的文档。梳理子系统的改造过程，将子系统改造的每个步骤写清楚，以及遇到各种情况的处理方案。

这次，方案终于通过，可以进入实际改造的环节。?

### 积极地帮助他人

在这里，容我先放一张沙雕图..

![img](http://cooper.didichuxing.com/reads3/shimo-images/kUjVJaTwLA04w305/image.png)

不同的人，对于同一个方案的理解，有时候可能会有些差异。而且，其实我在整理方案的时候，并没有考虑到所有情况。

![img](http://cooper.didichuxing.com/reads3/shimo-images/I88gaLngnfYE4LWw/image.png)

这个时候，就需要扮演好客服，以及售后的角色了。第一时间帮助同事解决出现的各种情况。

### 总结

跌跌撞撞一个月，在小伙伴的协助下，这个方案最终还是上线了。[体验地址：Odin](http://odin.v5.intra.xiaojukeji.com/) 。

之前有看张铁蕾老师的文章[《技术攻关：从零到精通》](https://mp.weixin.qq.com/s/mix-0Ft9G1F5yddNjSzkrw)，文中讲到如何解决一个从来没接触过的任务：

- 研究问题本身：先研究问题本身是怎么产生的
- 对专业领域的Overview：花最短的时间快速了解相关的各个概念
- Run起来，获得感性认识
- 同行交流：能够Run起一个实现，并从API层面粗略地了解一项技术之后，在这个认识的基础上，我们就差不多可以找同行交流一下了。
- 研究Spec：所谓Spec，是集中体现该项技术的设计思想的东西，是高度抽象的描述，一般也是一份完备的、系统性的描述。
- 研究和选择具体实现
- 研究相似产品的实现
- 网上浏览最佳实践
- 结合自己的系统设计方案
- 系统实现的过程

到这里，问题应该已经得到了解决。但是真正要推广开来，还需要：

- 沟通，听取他人意见。去了解当前方案需要哪些人的协助，举办评审会，收集、听取他人的建议。
- 确定影响范围，增强方案的兼容性。
- 通俗易懂，经得起反复推敲的**文档**。

如果可以做到这些，相信难题也可以迎刃而解了~

##作者：张博轩【滴滴出行高级软件开发工程师】

嘀～滴滴云618来啦！年中巨惠，错过今天，再等半年！
滴滴云使者专属特惠，包年云服务器低至68元／年
[![](http://img.blog.itpub.net/blog/2020/06/10/955c1226cb53e4a1.png?x-oss-process=style/bb)](https://www.didiyun.com/?channel=14816)
[![](http://img.blog.itpub.net/blog/2020/06/10/2789d0c05210236a.png?x-oss-process=style/bb)](https://www.didiyun.com/?channel=14816)

ITPub博客

如何在团队中推广一项技术 —— 解决Odin一站式微前端的缓存问题

最新文章