IKEA 微前端经验谈

  • Jan Stenberg
  • 谢丽

2018 年 8 月 9 日

话题:JavaScript语言 & 开发架构

如今,我们意识到,我们不应该把整个企业放在一个服务里,因此,我们把企业架构分割成较小的服务,即微服务。但是,我们也开始意识到,对于庞大的前端,我们面临着和庞大的后端一样的问题,Gustaf Nilsson Kotte在近日接受Stefan Tilkov采访时这样解释说。使用微前端架构,把前端分解成较小的部分,使团队可以自主部署,从而实现 Web 前端的持续交付。

Kotte 是Jayway的 IT 顾问,目前是作为 IKEA 的 Web 架构师,他喜欢把系统垂直分割,由同一个团队构建包含后端和前端的自包含系统。他认为,一个团队包含 10 到 12 个人时可以运转的比较好,超过那个数,团队就会不那么高效了。他还认为,如果服务小,则团队可以有不只一个服务,但是这会增加架构的压力,因为团队和服务都应该是自治的。

当 Tilkov 问,如果有 24 个人,他会如何安排。Kotte 不赞成创建一个前端团队和两个后端团队,他指出,后端团队向终端用户交付价值可能会需要前端团队的变更。两个后端团队可能还会增加前端故事队列。他更愿意创建两个独立的团队,每个 12 人,每个团队的后端和前端服务都由自己开发,可以按照自己的节奏部署,虽然这会带来一系列你必须处理的新问题,像协作和组件重用。

在 Kotte 看来,微服务关乎多样性和异构架构,允许使用不同的技术。他认为,前端也应该如此。前端领域还在发生着重大的变化,他见过一些大型的前端重写项目,并指出,我们往往低估了这些重写的成本。为期 2 到 4 年的重写周期于业务是不利的,相反,我们应该从一开始就支持多样化的前端技术栈。

不能依赖于单个框架,如ReactVue,不编写自己的框架,他认为那是个坑,Kotte 发现,要在前端获得我们期望从后端微服务获得的好处,唯一的解决方案是使用某种形式的嵌入机制——一种把一个电子文档包含在另一个文档中的方法。在客户端,其中一个嵌入的例子是 image 标签。该标签有一个 src 属性,指向一个 URL,浏览器在渲染时会使用实际的图片替换那个标签——浏览器把图片文档嵌入到了 HTML 文档中。

在服务器端,如果没有 HTML,则Edge Side Includes(ESI)对应 image 标签。它有一个源属性,URL 指向一个必须获取并包含在结果文档中的资源。ESI 是 IKEA 微前端概念中的基础技术。他们有页面和片段的概念,一个团队负责一套页面和片段。页面中可以有指向片段的 ESI,那些 ESI 引用可以跨团队。一个例子是,产品团队有产品缩略图的片段,其他团队可以引用这些产品缩略图,而不用自己创建。

由于页面是由不同团队开发的片段组合而成,可能使用了不同的技术,所以,这些片段需要使用某种技术组合在一起。为了解决这个问题,IKEA 的团队使用了一种名为自包含片段的技术,可以把片段需要的所有东西如 CSS 和 JavaScript 都包含进来。你不必考虑片段的依赖,只需要用一个 ESI 把样式包含进来,一个 ESI 把脚本包含进来,那样应该就可以了。Kotte 指出,这项技术本身有点复杂,但对于使用它的团队而言相当简单。

为了使页面和片段可以协同,他们只需设定几项规则。他们没有试图提前处理任何可能出现的问题,相反,他们有一种可以快速修复问题的通用方法,更看重平均恢复时间,而不是平均故障间隔时间

Kotte 在总结中强调,他介绍的架构并不一定适合所有人。你必须从组织层面考察不同设计的优缺点,找出最佳的解决方案。

要了解更多有关微前端的信息,Kotte 建议阅读他之前写的一篇文章,以及他在Øredev 2018 大会上关于微服务网站的介绍。此外,有一个网站专门介绍微前端

查看英文原文:Experiences Using Micro Frontends at IKEA

JavaScript语言 & 开发架构