IKEA 微前端经验谈

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

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

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

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

不能依赖于单个框架，如 React 或 Vue ，不编写自己的框架，他认为那是个坑，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