技术雷达之「微前端」- 将微服务理念扩展到前端开发 | 《前端的逆袭》知乎专栏

本文首发于技术雷达之「微前端」- 将微服务理念扩展到前端开发

欢迎关注知乎专栏 —— 前端的逆袭

欢迎关注个人博客，知乎，GitHub。

---

文章大纲

本文共计约 7k 字，预计阅读时间 15mins

• 微前端的原因：单体应用与微服务架构
  • 微服务架构带来了哪些好处？
  • 那么前端的现状呢？ —— 臃肿的前端
• 微前端的定义 - 将微服务理念扩展到前端开发
  • 拆分微前端所带来的好处
  • 微前端的核心思想
• 微前端的可选实践方案（4 种 +）
  • 建立更小的 Apps（而不是 Components）
  • 如何组合微前端的 App 模块？
    • Option 1: 使用后端模板引擎插入 HTML
    • Option 1.1: 渐进式从后端进行加载
    • Option 2: 使用 IFrame 隔离运行时
    • Option 3: 客户端 JavaScript 异步加载
    • Option 4: WebComponents 整合全部功能模块
  • 不一样 App 模块之间如何交互？
  • More Options…
• 微前端的页面优化与实例
  • 多模块页面加载问题与优化建议
  • 微前端在 AEM（CMS）项目的应用
  • 现成解决方案：Single-SPA “meta framework”
• 总结与思考：微前端的优缺点
  • 优势
  • 缺点
  • 持续思考…
• 参考资料

微前端的原因：单体应用与微服务架构

在传统的软件开发当中，大多数软件都是单体式应用架构的。在瞬息万变的商业时代背景下，企业必须学会适应咱们这个时代的不肯定性。快速试验，快速失败。更快地推出新产品和有效地改进当前产品，从而为客户提供有意义的数字体验。

而单体应用这种软件架构对于企业来讲的致命缺点就是，企业对于市场的响应速度变慢。企业决策者在一年内须要作的决策数量很是有限，因为依赖关系，其响应周期每每会变得很是漫长。每当开发或升级产品，都须要在一系列体量庞大的相关服务中同时增长新功能，这就须要全部利益相关方共同努力，以同步方式进行变动。

微服务架构带来了哪些好处？

假设服务边界已经被正确地定义为可独立运行的业务领域，并确保在微服务设计中遵循诸多最佳实践。那么至少会如下几个方面得到显而易见的好处：

• 复杂性：服务能够更好地分离，每个服务都足够小，完成完整的定义清晰的职责；
• 扩展性：每个服务能够独立横向扩展以知足业务伸缩性，并资源的没必要要消耗；
• 灵活性：每个服务能够独立失败，容许每一个团队决定最适合他们的技术和基础架构；
• 敏捷性：每个服务均可以独立开发，测试和部署，并容许团队扩展独立部署和维护服务的交付。

每一个微服务是孤立的，独立的「模块」，它们共同为更高的逻辑目的服务。微服务之间经过 Contract 彼此沟通，每一个服务都负责特定的功能。这使得每一个服务都可以保持简单，简洁和可测试性。

从而微服务架构容许企业更自发地采起更深远的业务决策，由于每一个微服务都是独立运做的，并且每个管理团队能够很好地控制该服务的变动。

那么前端的现状呢？ —— 臃肿的前端

在前端，每每由一个前端团队建立并维护一个 Web 应用程序，使用 REST API 从后端服务获取数据。这种方式若是作得好的话，它可以提供优秀的用户体验。但主要的缺点是单页面应用（SPA）不能很好地扩展和部署。在一个大公司里，单前端团队可能成为一个发展瓶颈。随着时间的推移，每每由一个独立团队所开发的前端层愈来愈难以维护。

特别是一个特性丰富、功能强大的前端 Web 应用程序，却位于后端微服务架构之上。而且随着业务的发展，前端变得愈来愈臃肿，一个项目可能会有 90％ 的前端代码，却只有很是薄的后端，甚至这种状况在 Serverless 架构的背景下还会愈演愈烈。

微前端的定义 - 将微服务理念扩展到前端开发

微前端（Micro Frontends）这个术语其实就是微服务的衍生物。将微服务理念扩展到前端开发，同时构建多个彻底自治的和松耦合的 App 模块（服务），其中每一个 App 模块只负责特定的 UI 元素和功能。

若是咱们看到微服务提供给后端的好处，那么就能够更进一步将这些好处应用到前端。与此同时，在设计微服务的时候，就能够考虑不只要完成后端逻辑，并且还要完成前端的视觉部分。而对于微前端来讲，与微服务的许多要求也是一致的：监控、日志、HealthCheck、Analytics 等等。

拆分微前端所带来的好处

这样就能使各个前端团队按照本身的步调迭代，并随时准备就绪处于可发布状态，并隔离相互依赖所产生的风险，与此同时也更容易尝试新技术。

• Web 应用程序被分解成独立的特征，而且每一个特征都由不一样的团队拥有，前端到后端。这确保了每一个功能都是独立于其余功能开发，测试和部署的。
• 将网站或 Web 应用程序视为由独立团队拥有的功能组合。每一个团队都有一个独特的业务或关注点肯定的任务。
• 每个团队是跨职能的，从数据库到用户界面端到端地开发其功能/特性。
• 全部前端功能（身份验证，库存，购物车等）都是 Web 应用程序的一部分，并与后端（大部分时间经过 HTTP）进行通讯，并将其分解为微服务。
• 能够同时拥有后端、前端、数据访问层和数据库，即一个服务子域所需的全部内容。
• 查找线上 bug、测试、框架迭代，甚至语言、代码隔离与责任和其余事情变得更容易处理。
• 咱们不得不付出的代价是部署，可是容器（Docker 和 Rocket）以及不可变服务器使得这种状况也获得了极大的改善。

微前端的核心思想

• ✨ Be Technology Agnostic：每一个团队都应该可以选择和升级他们的技术栈，而没必要与其余团队协调。自定义元素（后面会具体提到）是隐藏实现细节的好方法，同时为其余人提供公共接口。
• ✨ Isolate Team Code：即便全部团队使用相同的框架，也不要共享运行时。构建独立的应用程序。不要依赖共享状态或全局变量。
• ✨ Establish Team Prefixes：相互约定命名隔离。为 CSS、浏览器事件、Local Storage 和 Cookies 制定命名空间，以免冲突和明确其全部权。
• ✨ Favor Native Browser Features over Custom APIs：使用浏览器事件进行通讯，而不是构建全局的 PubSub 系统。若是确实须要构建跨团队 API，请尽可能保持简单。（与框架无关，可以使用 CustomEvent）
• ✨ Build a Resilient Site：即便 JavaScript 失败或还没有执行，Web 应用程序的功能仍应有效。可使用通用渲染和渐进加强来提升用户的感知性能。

微前端的可选实践方案（4 种+）

建立更小的 Apps（而不是 Components）

首先让咱们来建立一个典型 Web 应用程序的基本组件（Header、ProductList、ShoppingCart），以 Header 组件为例：

# src/App.js
export default () =>
  <header>
    <h1>Logo</h1>
    <nav>
      <ul>
        <li>About</li>
        <li>Contact</li>
      </ul>
    </nav>
  </header>;
复制代码

而后须要注意的是咱们会用到 Express 对刚刚建立的 React 组件进行服务器端渲染，使之成为一个 App 模块:

# server.js
fs.readFile(htmlPath, 'utf8', (err, html) => {
  const rootElem = '<div id="root">';
  const renderedApp = renderToString(React.createElement(App, null));

  res.send(html.replace(rootElem, rootElem + renderedApp));
});
复制代码

再依次建立其余 Apps 并独立部署：

• microfrontends-header.herokuapp.com/
• microfrontends-products-list.herokuapp.com/
• microfrontends-cart.herokuapp.com/

如何组合微前端的 App 模块？

在每一个独立团队建立好各自的 App 模块后，咱们就能够将网站或 Web 应用程序视为由各类模块的功能组合。下文将介绍多种技术实践方案来从新组合这些模块（有时做为页面，有时做为组件），而前端（无论是否是 SPA）将只须要负责路由器（Router）如何选择和决定要导入哪些模块，从而为最终用户提供一致性的用户体验。

Option 1: 使用后端模板引擎插入 HTML

# server.js
Promise.all([
    getContents('https://microfrontends-header.herokuapp.com/'),
    getContents('https://microfrontends-products-list.herokuapp.com/'),
    getContents('https://microfrontends-cart.herokuapp.com/')
  ]).then(responses =>
    res.render('index', { header: responses[0], productsList: responses[1], cart: responses[2] })
  ).catch(error =>
    res.send(error.message)
  )
);
复制代码

# views/index.ejs
  <head>
    <meta charset="utf-8">
    <title>Microfrontends Homepage</title>
  </head>
  <body>
    <%- header %>
    <%- productsList %>
    <%- cart %>
  </body>
复制代码

可是，这种方案也存在弊端，即某些 App 模块可能会须要相对较长的加载时间，而在前端整个页面的渲染却要取决于最慢的那个模块。

好比说，可能 Header 模块的加载速度要比其余部分快得多，而 ProductList 则由于须要获取更多 API 数据而须要更多时间。一般状况下咱们但愿尽快将网页显示给用户，而在这种状况下后台加载时间就会变得更长。

Option 1.1: 渐进式从后端进行加载

固然，咱们也能够经过修改一些后端代码来渐进式地（Progressive）往前端发送 HTML，但与此同时却徒增了后端复杂度，而且又将前端的渲染控制权交回了后端服务器。并且咱们的优化也取决于每一个模块加载的速度，如果进行优化就必须按必定顺序进行加载。

Option 2: 使用 IFrame 隔离运行时

<body>
  <iframe width="100%" height="200" src="https://microfrontends-header.herokuapp.com/"></iframe>
  <iframe width="100%" height="200" src="https://microfrontends-products-list.herokuapp.com/"></iframe>
  <iframe width="100%" height="200" src="https://microfrontends-cart.herokuapp.com/"></iframe>
</body>
复制代码

咱们也能够将每一个子应用程序嵌入到各自的 <iframe> 中，这使得每一个模块可以使用任何他们须要的框架，而无需与其余团队协调工具和依赖关系，依然能够借助于一些库或者 Window.postMessageAPI 来进行交互。

• 优势：
  • 最强大的是隔离了组件和应用程序部分的运行时环境，所以每一个模块均可以独立开发，而且能够与其余部分的技术无关
  • 能够各自使用彻底不一样的前端框架，能够在 React 中开发一部分，在 Angular 中开发一部分，而后使用原生 JavaScript 开发其余部分或任何其余技术。
  • 只要每一个 iframe 来自同一个来源，消息传递也就至关直接和强大。参考文档 Window.postMessageAPI
• 缺点：
  • Bundle 的大小很是明显，由于可能最终会屡次发送相同的库，而且因为应用程序是分开的，因此在构建时也不能提取公共依赖关系。
  • 至于浏览器的支持，基本上不可能嵌套两层以上的 iframe（parent - > iframe - > iframe）。
  • 若是任何嵌套的框架须要可以滚动或具备 Form 表单域，那样的状况处理起来就会变得特别痛苦。

Option 3: 客户端 JavaScript 异步加载

function loadPage (element) {
  [].forEach.call(element.querySelectorAll('script'), function (nonExecutableScript) {
    var script = document.createElement("script");
    script.setAttribute("src", nonExecutableScript.src);
    script.setAttribute("type", "text/javascript");
    element.appendChild(script);
  });
}

document.querySelectorAll('.load-app').forEach(loadPage);
复制代码

<div class="load-app" data-url="header"></div>
<div class="load-app" data-url="products-list"></div>
<div class="load-app" data-url="cart"></div>
复制代码

简单来讲，这种方式就是在客户端浏览器经过 Ajax 加载应用程序，而后将不一样模块的内容插入到对应的 div 中，并且还必须手动克隆每一个 script 的标记才能使其工做。

须要注意的是，为了不 Javascript 和 CSS 加载顺序的问题，建议将其修改为相似于 Facebook bigpipe 的解决方案，返回一个 JSON 对象 { html: ..., css: [...], js: [...] } 再进行加载顺序的控制。

Option 4: WebComponents 整合全部功能模块

Web Components 是一个 Web 标准，因此像 Angular、React/Preact、Vue 或 Hyperapp 这样的主流 JavaScript 框架都支持它们。你能够将 Web Components 视为使用开放 Web 技术建立的可重用的用户界面小部件，也许会是 Web 组件化的将来。

Web Components 由如下四种技术组成（尽管每种技术均可以独立使用）：

• 自定义元素（Custom Elements）对外提供组件的标签，实现自定义标签：能够建立本身的自定义 HTML 标签和元素。每一个元素能够有本身的脚本和 CSS 样式。还包括生命周期回调，它们容许咱们定义正在加载的组件特定行为。
• HTML 模板（HTML <template>）定义组件的 HTML 模板能力：一种用于保存客户端内容的机制，该内容在页面加载时不被渲染，但能够在运行时使用 JavaScript 进行实例化。能够将一个模板视为正在被存储以供随后在文档中使用的一个内容片断。
• 影子 DOM（Shadow DOM）封装组件的内部结构，而且保持其独立性：容许咱们在 Web 组件中封装 JavaScript，CSS 和 HTML。在组件内部时，这些东西与主文档的 DOM 分离。
• HTML 导入（HTML Imports）解决组件组合和依赖加载：在微前端的上下文中，能够是包含咱们要使用的组件在服务器上的远程位置。

# src/index.js
class Header extends HTMLElement {
  attachedCallback() {
    ReactDOM.render(<App />, this.createShadowRoot());
  }
}
document.registerElement('microfrontends-header', Header);
复制代码

<body>
    <microfrontends-header></microfrontends-header>
    <microfrontends-products-list></microfrontends-products-list>
    <microfrontends-cart></microfrontends-cart>
</body>
复制代码

在微前端的实践当中：

• 每一个团队使用各自的技术栈建立他们的组件，并把它包装到自定义元素（Custom Element）中（如 <microfrontends-header></microfrontends-header>）。
• Web 组件就是应用程序中包含的组件的本地实现，如菜单，表单，日期选择器等。每一个组件都是独立开发的，主应用程序项目利用它们组装成最终的应用程序。
• 特定元素（标签名称，属性和事件）的 DOM 规范还能够充当跨团队之间的契约或公共 API。
• 建立可被导入到 Web 应用程序中的可重用组件，它们就像能够导入任何网页的用户界面小部件。

<link rel="import" href="/components/microfrontends/header.html">
<link rel="import" href="/components/microfrontends/products-list.html">
<link rel="import" href="/components/microfrontends/cart.html">
复制代码

• 优势
  • 代码的可读性变得很是清晰，组件资源内部高内聚，组件资源由自身加载控制，做用域独立。
  • 功能团队可使用组件及其功能，而没必要知道实现，他们只须要可以与 HTML DOM 进行交互。
  • 使用 PubSub 机制，组件能够发布消息，其余组件能够订阅特定的主题。幸运的是浏览器内置了这个功能。好比购物车能够在 window 订阅此事件并在应该刷新其数据时获得通知。
• 缺点
  • 惋惜的是，Web 组件规范跟服务器渲染无关。没有 JavaScript，就没有所谓的自定义元素。
  • 浏览器和框架的支持不够，须要更多的 polyfills 从而影响到用户页面的加载体验。
  • 咱们须要在整个 Web 应用程序上作出改变，把它们所有转换成 Web Components。
  • 社区不够活跃，Web Components 尚未真正流行起来，也许永远也不会。

不一样 App 模块之间如何交互？

# angularComponent.ts
const event = new CustomEvent('addToCart', { detail: item });
window.dispatchEvent(event);
复制代码

# reactComponent.js
componentDidMount() {
  window.addEventListener('addToCart', (event) => {
    this.setState({ products: [...this.state.products, event.detail] });
  }, false);
}
复制代码

• 得益于浏览器的原生 API，Custom Event 能够与其余任何技术和框架一块儿工做。好比，咱们能够将消息从 Angular 组件发送到 React 组件。其实这也是如今 API 之间广泛使用 JSON 进行通讯的缘由，即便没有人使用 NodeJS 做为服务器端。
• 可是，新的问题又出现了。咱们该如何测试这种跨模块之间的交互？须要编写相似于后端微服务之间的 Contract Testing 或 Integration Testing 吗？并无答案。

More Options...

• 组件库 - 根据主 App 的技术栈，不一样的组件和 App 模块拆分做为库的形式提供给主App，因此主 App 是由不一样组件组成的。可是组件库的升级将成为一个大麻烦，好比对 Header 组件进行了更改，那么若是已经有 50 个页面使用了 Header 组件该怎么办？必需要求每一页都升级它的 Header，并且升级过程当中用户还会在整个网站不一样页面上看到不一致的标题。而且，在两边还必须都使用相同的技术，好比 Header 组件中使用了 ClojureScript，而 Content 组件中又用了 Elm，那么该怎么办？构建工具就必须在编译时处理不一样的语言。
• 将 App 模块做为 React 黑盒组件分发给消费者模块 - 应用程序的状态彻底包含在组件中，API 只是经过 props 暴露出来。这种方式其实增长了应用程序之间的耦合，由于它迫使每一个人都使用 React，甚至会使用相同版本的 React，可是这彷佛也是一个比较好的折衷。
• Edge Side Includes(ESI)/Server Side Includes(SSI) - 经过特殊的文件后缀 (shtml,inc) 或简单的标记语言来对那些能够加速和不能加速的网页中的内容片段进行描述，将每一个网页划分红不一样的小部分分别赋予不一样的缓存控制策略。SSI / ESI 方法的缺点是，最慢的片断决定了整个页面的响应时间。

微前端的页面优化与实例

多模块页面加载问题与优化建议

• 使用 skeleton screen 响应式布局：如上图 LinkedIn 所作的那样，首先展示给用户一个页面的空白版本，而后在这个页面中逐渐加载和填充相应的信息。不然中间的信息流部分的内容最初是空白的，而后在 JavaScript 被加载和执行事后，信息流就会由于须要占用更多的空间而推进整个页面的布局。虽然咱们能够控制页面来固定中间部分的高度，但在响应式网站上，肯定一个确切的高度每每很难，并且不一样的屏幕尺寸可能会有所不一样。但更重要的问题是，这种高度尺寸的约定会让不一样团队之间产生紧密的联系，从而违背了微前端的初衷。
• 使用浏览器异步加载加快初始渲染：对于加载成本高且难以缓存的碎片，将其从初始渲染中排除是一个好主意。好比说 LinkedIn 首页的信息流就是一个很好的例子。
• 共享 UI 组件库保证视觉体验一致：在前端设计中，必须向用户呈现外观和感受一致的用户界面。建议能够创建一个共享组件库（包含 CSS、字体和 JavaScript）。将这些资源托管在 CDN，每一个微前端就能够在其 HTML 输出中引用它们的位置。每一个组件库的版本都正确地对资源进行版本控制，而每一个微前端都指定要使用的组件库的版本和显式更新依赖关系。
• 使用集中式服务（Router）来管理 URL：能够理解为前端的 Gateway，不一样的 URL 对应不一样应用程序所包含的内容。建议经过一个集中式的 URLs Router 来为应用程序提供一个 API 来注册他们本身的 URL，Router 将会位于 Web 应用程序的前面，根据不一样的用户请求指向不一样的 App 模块组合。

• 提取共同依赖做为 externals 加载：虽说不一样 App 模块之间不能直接共享相同的第三方模块，当咱们依然能够将经常使用的依赖好比 lodash、moment.js等公共库，或者跨多个团队共同使用的 react 和 react-dom。经过 Webpack 等构建工具就能够把打包的时候将这些共同模块排除掉，而只须要在 HTML <header> 中的 <script>中直接经过 CDN 加载 externals 依赖。

<script src="https://cdnjs.cloudflare.com/ajax/libs/react/16.2.0/react.min.js" crossorigin="anonymous"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/react/16.2.0/react-dom.min.js" crossorigin="anonymous"></script>
复制代码

微前端在 AEM（CMS）项目的应用

咱们在「三靠谱」（已和谐客户名称）的 Marketplace 项目当中也曾经探索过 AEM + React 混合开发的解决方案，其中就涉及到如何在 AEM 当中嵌入 React 组件，甚至将 AEM 组件又强行转化为 React 组件进行嵌套。如今回过头来其实也算是微前端的一种实践：

• AEM 仅仅包含网页内容，不包含 domain 相关的结构化数据。
• React 组件被托管在 AEM 组件当中，再经由 AEM 传递给组件所须要的属性，好比 IDs 或 APIs 的 URL 等等
• 后端微服务则包含 domain 结构化数据，由对应的 React 组件经过 Ajax 进行数据查询。

<div id="cms-container-1">
    <div id="react-input-container"></div>
    <script> ReactDOM.render(React.createElement(Input, { ...injectProps }), document.getElementById('react-input-container')); </script>
  </div>
  <div id="cms-container-2">
    <div id="react-button-container"></div>
    <script> ReactDOM.render(React.createElement(Button, {}), document.getElementById('react-button-container')); </script>
  </div>
复制代码

现成解决方案：Single-SPA “meta framework”

开源的 single-spa 自称为「元框架」，能够实如今一个页面将多个不一样的框架整合，甚至在切换的时候都不须要刷新页面（支持 React、Vue、Angular 一、Angular 二、Ember 等等）：

• Build micro frontends that coexist and can each be written with their own framework.
• Use multiple frameworks on the same page without refreshing the page (React, AngularJS, Angular, Ember, or whatever you're using)
• Write code using a new framework, without rewriting your existing app
• Lazy load code for improved initial load time.
• Hot reload entire chunks of your overall application (instead of individual files).

请看示例代码，所提供的 API 很是简单：

import * as singleSpa from 'single-spa';

const appName = 'app1';

const loadingFunction = () => import('./app1/app1.js');
const activityFunction = location => location.hash.startsWith('#/app1');

singleSpa.declareChildApplication(appName, loadingFunction, activityFunction);
singleSpa.start();
复制代码

# single-spa-examples.js

declareChildApplication('navbar', () => import('./navbar/navbar.app.js'), () => true);
declareChildApplication('home', () => import('./home/home.app.js'), () => location.hash === "" || location.hash === "#");
declareChildApplication('angular1', () => import('./angular1/angular1.app.js'), hashPrefix('/angular1'));
declareChildApplication('react', () => import('./react/react.app.js'), hashPrefix('/react'));
declareChildApplication('angular2', () => import('./angular2/angular2.app.js'), hashPrefix('/angular2'));
declareChildApplication('vue', () => import('src/vue/vue.app.js'), hashPrefix('/vue'));
declareChildApplication('svelte', () => import('src/svelte/svelte.app.js'), hashPrefix('/svelte'));
declareChildApplication('preact', () => import('src/preact/preact.app.js'), hashPrefix('/preact'));
declareChildApplication('iframe-vanilla-js', () => import('src/vanillajs/vanilla.app.js'), hashPrefix('/vanilla'));
declareChildApplication('inferno', () => import('src/inferno/inferno.app.js'), hashPrefix('/inferno'));
declareChildApplication('ember', () => loadEmberApp("ember-app", '/build/ember-app/assets/ember-app.js', '/build/ember-app/assets/vendor.js'), hashPrefix('/ember'));

start();
复制代码

总结与思考：微前端的优缺点

优势

• 敏捷性 - 独立开发和更快的部署周期：
  • 开发团队能够选择本身的技术并及时更新技术栈。
  • 一旦完成其中一项就能够部署，而没必要等待全部事情完毕。
• 下降错误和回归问题的风险，相互之间的依赖性急剧降低。
• 更简单快捷的测试，每个小的变化没必要再触碰整个应用程序。
• 更快交付客户价值，有助于持续集成、持续部署以及持续交付。
• 维护和 bugfix 很是简单，每一个团队都熟悉所维护特定的区域。

缺点

• 开发与部署环境分离
  • 本地须要一个更为复杂的开发环境。
  • 每一个 App 模块有一个孤立的部署周期。
  • 最终应用程序须要在同一个孤立的环境中运行。
• 复杂的集成
  • 须要考虑隔离 JS，避免 CSS 冲突，并考虑按需加载资源
  • 处理数据获取并考虑用户的初始化加载状态
  • 如何有效测试，微前端模块之间的 Contract Testing？
• 第三方模块重叠
  • 依赖冗余增长了管理的复杂性
  • 在团队之间共享公共资源的机制
• 影响最终用户的体验
  • 初始 Loading 时间可能会增长
  • HTML 会须要服务器端的渲染

持续思考…

• （变幻莫测）前端的技术选型？

  • 前端 JavaScript 框架工具穷出不穷，过几个月就要重写前端项目？好比最近又出来了声称要取代 Webpack（Parcel）和 Yarn（Turbo）的工具。伴随着前端框架的更新换代，若是整个项目一块儿升级/重构的话压力大、风险高，那不如拆分微前端直接支持多 framework，或者同一 framework 的不一样版本？

• 在 Mobile/Mobile Web 上的悖论

  • 受限于 Mobile 尺寸大小，单一页面所能展示的内容本就有限。
  • 既然已经分出了不一样的子页面，那何不如直接 Route 便可？

• 合理划分的边界：DDD（领域驱动开发）

  • 最大的挑战是搞清楚如何合理拆分应用程序。
  • 糟糕的设计可能成为开发和维护的噩梦。

• Don't use any of this if you don't need it

  • Do not use the ideas described here until it is needed, it will make things more complex.
  • If you are in a big company, those ideas could help you.

• 软件架构到底在解决什么问题？—— 跨团队沟通的问题

  • 在正常状况下，每一个团队拥有开发和维护其特性所需的一切，都应该有本身的能力来完成本身的特性，并最大限度地减小团队要求其余部门得到许可和/或帮助。
  • 当引入 library 或 framework 时的好处是只须要少数人讨论，而不用涉及超过 100 人的决策和他们的各类需求。这样一场大讨论不只会耗费时间和精力，并且会迫使咱们采用最不起眼的方法来选择 library，而不是选择专门针对每一个 team 的问题领域的方案。

  所谓架构，实际上是解决人的问题；所谓敏捷，实际上是解决沟通的问题；

参考资料

本次技术雷达「微前端」主题的宣讲 Slides 能够在个人博客找到：「技术雷达」之 Micro Frontends：微前端 - 将微服务理念扩展到前端开发 - 吕立青的博客

• 在作 Slides 以前所整理的 XMind 思惟导图：www.xmind.net/m/e3dv
• 本人所整理的全部关于「微前端」的资料：www.diigo.com/user/jimmyl…
• 平常挖宝：ThoughtWorks 邮件组搜索「microfrontend」关键字：inbox.google.com/u/1/search/…
• micro-frontends.org/
• medium.com/@tomsoderlu…
• medium.com/@_rchaves_/…
• www.agilechamps.com/microservic…
• allegro.tech/2016/03/Man…
• technologyconversations.com/2015/08/09/…
• technologyconversations.com/2015/08/09/…