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

2020-05-22 00:00:00 微服 团队 应用程序 模块 组件

文章大纲

本文共计约 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>;

相关文章