新轮子 Mooa:使用 mooa 微服务化 Angular 应用

本文涉及的产品
服务治理 MSE Sentinel/OpenSergo,Agent数量 不受限
简介:

Angular 基于 Component 的思想,可以让其在一个页面上同时运行多个 Angular 应用;可以在一个 DOM 节点下,存在多个 Angular 应用,即类似于下面的形式:

 
  1. <app-home _nghost-c3="" ng-version="5.2.8">

  2.  <app-help _nghost-c0="" ng-version="5.2.2" style="display:block;"><div _ngcontent-c0=""></div></app-help>

  3.  <app-app1 _nghost-c0="" ng-version="5.2.3" style="display:none;"><nav _ngcontent-c0="" class="navbar"></div></app-app1>

  4.  <app-app2 _nghost-c0="" ng-version="5.2.2" style="display:none;"><nav _ngcontent-c0="" class="navbar"></div></app-app2>

  5. </app-home>

可这一样一来,难免需要做以下的一些额外的工作:

  • 创建子应用项目模板,以统一 Angular 版本

  • 构建时,删除子应用的依赖

  • 修改第三方模块

而在这其中最麻烦的就是第三方模块冲突问题。思来想去,在三月中旬,我在 Mooa 中添加了一个 iframe 模式。

Mooa

Mooa 是一个为 Angular 服务的微前端框架,它是一个基于 single-spa,针对 IE 10 及 IFRAME 优化的微前端解决方案。

Mooa 框架与 Single-SPA 不一样的是,Mooa 采用的是 Master-Slave 架构,即主-从式设计。

对于 Web 页面来说,它可以同时存在两个到多个的 Angular 应用:其中的一个 Angular 应用作为主工程存在,剩下的则是子应用模块。

  • 主工程,负责加载其它应用,及用户权限管理等核心控制功能。

  • 子应用,负责不同模块的具体业务代码。

在这种模式下,则由主工程来控制整个系统的行为,子应用则做出一些对应的响应。

iframe 微服务架构设计

在这里,总的设计思想和之前的《如何解构单体前端应用——前端应用的微服务式拆分》中介绍是一致的:

ae1e0e705b908527d53c757b5ee9b04f554261b2

Mooa 架构

主要过程如下:

  • 主工程在运行的时候,会去服务器获取最新的应用配置。

  • 主工程在获取到配置后,将一一创建应用,并为应用绑定生命周期。

  • 当主工程监测到路由变化的时候,将寻找是否有对应的路由匹配到应用。

  • 当匹配对对应应用时,则创建或显示相应应用的 iframe,并隐藏其它子应用的 iframe。

其加载形式与之前的 Component 模式并没有太大的区别:

776254d4a19b703a5be97491ef9531d9f0e17ca2

Mooa Component 加载

而为了控制不同的 iframe 需要做到这么几件事:

  1. 为不同的子应用分配 ID

  2. 在子应用中进行 hook,以通知主应用:子应用已加载

  3. 在子应用中创建对应的事件监听,来响应主应用的 URL 变化事件

  4. 在主应用中监听子程序的路由跳转等需求

因为大部分的代码可以与之前的 Mooa 复用,于是我便在 Mooa 中实现了相应的功能。

微前端框架 Mooa 的特制 iframe 模式

iframe 可以创建一个全新的独立的宿主环境,这意味着我们的 Angular 应用之间可以相互独立运行,我们唯一要做的是:建立一个通讯机制

它可以不修改子应用代码的情况下,可以直接使用。与此同时,它在一般的 iframe 模式进行了优化。使用普通的 iframe 模式,意味着:我们需要加载大量的重复组件,即使经过 Tree-Shaking 优化,它也将带来大量的重复内容。如果子应用过多,那么它在初始化应用的时候,体验可能就没有那么友好。但是与此相比,在初始化应用的时候,加载所有的依赖在主程序上,也不是一种很友好的体验。

于是,我就在想能不能创建一个更友好地 IFrame 模式,在里面对应用及依赖进行处理。如下,就是最后生成的页面的 iframe 代码:

 
  1. <app-home _nghost-c2="" ng-version="5.2.8">

  2.  <iframe frameborder="" width="100%" height="100%" src="http://localhost:4200/assets/iframe.html" id="help_206547" style="display:block;"></iframe>

  3.  <iframe frameborder="" width="100%" height="100%" src="http://localhost:4200/assets/iframe.html" id="app_235458 style="display:none;"></iframe>

  4. </app-home>

对,两个 iframe 的 src 是一样的,但是它表现出来的确实是两个不同的 iframe 应用。那个 iframe.html 里面其实是没有内容的:

 
  1. <!doctype html>

  2. <html lang="en">

  3. <head>

  4.  <meta charset="utf-8">

  5.  <title>App1</title>

  6.  <base href="/">

  7.  <meta name="viewport" content="width=device-width,initial-scale=1">

  8.  <link rel="icon" type="image/x-icon" href="favicon.ico">

  9. </head>

  10. <body>

  11. </body>

  12. </html>

(PS:详细的代码可以见 https://github.com/phodal/mooa)

只是为了创建 iframe 的需要而存在的,对于一个 Angular 应用来说,是不是一个 iframe 的区别并不大。但是,对于我们而言,区别就大了。我们可以使用自己的方式来控制这个 IFrame,以及我们所要加载的内容。如:

  • 共同 Style Guide 中的 CSS 样式。如,在使用 iframe 集成时,移除不需要的

  • 去除不需要重复加载的 JavaScript。如,打包时不需要的 zone.min.js、polyfill.js 等等

注意:对于一些共用 UI 组件而言,仍然需要重复加载。这也就是 iframe 模式下的问题。

微前端框架 Mooa iframe 通讯机制

为了在主工程与子工程通讯,我们需要做到这么一些事件策略:

发布主应用事件

由于,我们使用 Mooa 来控制 iframe 加载。这就意味着我们可以通过 document.getElementById 来获取到 iframe,随后通过 iframeEl.contentWindow 来发布事件,如下:

 
  1. let iframeEl: any = document.getElementById(iframeId)

  2. if (iframeEl && iframeEl.contentWindow) {

  3.  iframeEl.contentWindow.mooa.option = window.mooa.option

  4.  iframeEl.contentWindow.dispatchEvent(

  5.  new CustomEvent(MOOA_EVENT.ROUTING_CHANGE, { detail: eventArgs })

  6.  )

  7. }

这样,子应用就不需要修改代码,就可以直接接收对应的事件响应。

监听子应用事件

由于,我们也希望能直接在主工程中处理子程序的事件,并且不修改原有的代码。因此,我们也使用同样的方式来在子应用中监听主应用的事件:

 
  1. iframeEl.contentWindow.addEventListener(MOOA_EVENT.ROUTING_NAVIGATE, function(event: CustomEvent) {

  2.  if (event.detail) {

  3.  navigateAppByName(event.detail)

  4.  }

  5. })

示例

同样的我们仍以 Mooa 框架作为示例,我们只需要在创建 mooa 实例时,配置使用 iframe 模式即可:

 
  1. this.mooa = new Mooa({

  2.  mode: 'iframe',

  3.  debug: false,

  4.  parentElement: 'app-home',

  5.  urlPrefix: 'app',

  6.  switchMode: 'coexist',

  7.  preload: true,

  8.  includeZone: true

  9. });

  10. ...

  11. that.mooa.registerApplicationByLink('help', '/assets/help', mooaRouter.matchRoute('help'));

  12. that.mooa.registerApplicationByLink('app1', '/assets/app1', mooaRouter.matchRoute('app1'));

  13. this.mooa.start();

  14. ...

  15. this.router.events.subscribe((event: any) => {

  16.  if (event instanceof NavigationEnd) {

  17.  that.mooa.reRouter(event);

  18.  }

  19. });

子程序则直接使用:https://github.com/phodal/mooa-boilerplate 就可以了。

98900183430e863c672c2ce828f5c083ddece29a

GitHub 地址:https://github.com/phodal/mooa


原文发布时间:2018年04月18日

作者:phodal_

本文来源:CSDN  如需转载请联系原作者

目录
相关文章
|
21天前
|
Kubernetes 开发者 Docker
构建高效微服务架构:Docker与Kubernetes的协同应用
【5月更文挑战第30天】 在当今软件开发领域,微服务架构已成为实现系统模块化、提升可维护性及扩展性的关键策略。本文深入探讨了如何通过Docker容器化技术和Kubernetes集群管理,共同构建一个既高效又可靠的后端微服务环境。我们将剖析Docker和Kubernetes的核心功能,以及它们如何相辅相成,支撑起现代化的云原生应用程序部署和管理。文章还将提供具体实践案例,帮助开发者理解将理论应用于实际开发过程中的步骤和考虑因素。
|
1月前
|
JavaScript 前端开发 架构师
Angular进阶:理解RxJS在Angular应用中的高效运用
RxJS(Reactive Extensions for JavaScript)是JavaScript的一个响应式编程库,特别适用于处理异步数据流。
32 0
|
1月前
|
JavaScript 前端开发
Angular.js 应用中数据模式的删除操作实现
Angular.js 应用中数据模式的删除操作实现
43 0
|
5天前
|
设计模式 消息中间件 运维
微服务架构在后端开发中的应用与挑战
微服务架构作为一种现代软件开发方法,带来了灵活性、可扩展性和高效性,但同时也引发了诸如复杂性管理、数据一致性等新的挑战。本文深入探讨了微服务架构在后端开发中的应用场景,以及应对这些挑战的策略。
16 0
|
8天前
|
监控 负载均衡 持续交付
深入理解微服务架构及其在现代后端开发中的应用
本文将深入探讨微服务架构的核心概念、设计原则和实施挑战,并分析其在现代后端开发中的实际应用。通过比较传统单体应用与微服务的优劣,揭示微服务如何助力于系统的可扩展性、灵活性和持续部署。此外,文章还将讨论微服务实施过程中的常见问题及解决方案,为后端开发者提供实践指导。
|
10天前
|
消息中间件 存储 监控
通过将大型应用拆分成一系列小型、独立的服务,微服务架构为后端开发带来了更高的灵活性、可扩展性和可维护性
【6月更文挑战第10天】本文探讨了构建高效微服务架构的后端开发最佳实践。微服务的核心原则是服务独立、去中心化、自治和轻量级通信,优势在于可扩展性、独立性、技术灵活性和团队协作。实践中,应注意服务的拆分粒度,选择合适的通信协议(如RESTful、RPC、消息队列),处理数据一致性与分布式事务,实施服务治理和监控,以及确保安全性与权限控制。未来,微服务将结合服务网格、容器化和云原生技术,持续发展和优化。
16 0
|
12天前
|
存储 运维 监控
软件设计不是 CRUD:像搭积木一样搭建应用系统(下)——微服务化系统的搭建
【6月更文挑战第8天】微服务架构现为构建复杂应用的主流方法,通过拆分小型独立服务实现灵活组合。服务划分依据业务功能,通信常采用HTTP API或RPC,强调接口简洁、稳定和可扩展。数据管理需保证一致性,示例代码展示了服务间交互。实际搭建还需考虑部署、监控、日志及分布式事务处理等挑战。微服务是一个持续演进的过程,要求开发团队有深厚技术基础和协作能力。它提升了软件的灵活性、可扩展性和可靠性,随着技术进步,微服务架构将持续发展。
37 0
|
20天前
|
Kubernetes Cloud Native 开发者
构建高效云原生应用:Kubernetes与微服务架构的融合
【5月更文挑战第31天】 在数字化转型和技术迭代的大潮中,企业对于敏捷、可扩展的IT基础设施需求日益增长。云原生技术以其独特的优势成为推动这一进程的关键力量。本文深入探讨了如何通过结合Kubernetes容器编排和微服务架构来构建和维护高效、可靠的云原生应用。我们将剖析这种技术整合的必要性,揭示其背后的原理,并讨论在实际部署过程中可能遇到的挑战及解决方案。通过案例分析和最佳实践的分享,旨在为开发者和架构师提供一套行之有效的云原生应用构建指南。
|
20天前
|
存储 消息中间件 运维
单体应用与微服务的优缺点
单体应用(monolith application)就是将应用程序的所有功能都打包成一个独立的单元,可以是 JAR、WAR、EAR 或其它归档格式。
29 0
|
20天前
|
敏捷开发 Kubernetes Cloud Native
构建高效云原生应用:容器化与微服务架构的融合
【5月更文挑战第31天】 随着云计算技术的不断演进,云原生应用已成为企业数字化转型的核心。本文深入探讨了如何通过容器化技术和微服务架构的有效结合,构建高效、弹性和可扩展的云原生应用。我们将分析容器化的基本概念、优势以及它如何促进微服务架构的实施,同时提供策略和最佳实践,帮助企业实现敏捷开发和持续部署,优化资源利用,并提高系统的可靠性。

热门文章

最新文章