如何实现前端微服务化?

译者按: 微服务在后端开发中大行其道,其实对于越来越复杂的前端应用来说,微服务也是一种不错的选择。

原文: Micro frontends—a microservice approach to front-end web development

译者: Fundebug

为了保证可读性,本文采用意译而非直译。另外,本文版权归原作者所有,翻译仅用于学习。

对于网页应用,现代的开发方法使得前端部分变得越来越大,与之对应的后端反而变小。我们的网站Weld的代码中90%都是前端相关。我可以想象大多数现代的网页应用都类似。

网页应用一直在演化,网页开发的技术也在不断进步。现代的开发甚至依赖于在同一个项目中使用多个不同的框架。比如我们使用一些依赖于jQuery、AngularJS 1.x的旧的模块,和React、Vue里面的新模块。

单一框架无法应对大型网页应用

我们需要一种方法可以把一个大的项目拆分成很多个小的模块,让它们独自运行。

举个例子:

  • myapp.com:使用静态HTML技术构建的静态页面。
  • myapp.com/settings:使用AngularJS 1.x 构建的旧的设置页面。
  • myapp.com/dashboard:使用React构建的新的控制面板。

能够想象我们需要如下技术:

  • 一个共享的JavaScript代码库比如用于管理路由和用户会话,以及一些共享的CSS。当然要越少越好。
  • 一堆独立的模块,也就是微应用(‘mini-app’)。每一个使用各自的框架搭建,使用不同的代码库管理。
  • 一个可以将所有模块连接起来的发布系统,可以将整个服务运行。任何模块的更新都会触发服务的重启。

前端微服务化

正如大家想到的,那就是前端微服务化。像Spotify, Klarna, Zalando, UpworkAllegro都使用前端微服务化技术来构架他们的网页应用。

实现方案

我总结了一下几种实现方案:

  1. 我认为最好的方案是Single-SPA “meta framework”可以在一个页面将多个不同的框架整合,甚至在切换的时候都不需要刷新页面(这个是demo,支持React, Vue, Angular 1, Angular 2, etc)。可以看Bret Little的介绍
  2. 多个单一页面应用分管不同的URL。该方法使用了NPM/Bower来共享某些功能。
  3. 将微服务包装到IFrames中,然后使用一些库和Window.postMessageAPI来交互
  4. 不同的模块使用共享事件总线(比如,chrisdavies/eev)来交流。每一个模块使用独自开发,并处理所有模块间的交互事件。
  5. 使用Varnish Cache来整合不同的模块。
  6. 使用Web Components来作为一个整合层整合所哟模块。
  7. React部件黑盒技术

资源

更多

版权声明:
转载时请注明作者Fundebug以及本文地址:
https://blog.fundebug.com/2017/08/02/micro_frontend_development/
时间: 2024-11-06 23:14:32

如何实现前端微服务化?的相关文章

前端单页应用微服务化解决方案2 - Single-SPA

技术选型 经过各种技术调研我们最终选择的方案是基于 Single-SPA 来实现我们的前端微服务化. Single-SPA 一个用于前端微服务化的JavaScript前端解决方案 使用Single-SPA之后,你可以这样做: (兼容各种技术栈)在同一个页面中使用多种技术框架(React, Vue, AngularJS, Angular, Ember等任意技术框架),并且不需要刷新页面. (无需重构现有代码)使用新的技术框架编写代码,现有项目中的代码无需重构. (更优的性能)每个独立模块的代码可做

微服务化之服务拆分与服务发现

本文章为<互联网高并发微服务化架构实践>系列课程的第六篇 前五篇为: 微服务化的基石--持续集成 微服务的接入层设计与动静资源隔离 微服务化的数据库设计与读写分离 微服务化之无状态化与容器化 微服务化之缓存的设计 一.服务拆分的前提 说到微服务,服务拆分是绕不过去的话题,但是微服务不是说拆就能拆的,有很多的前提条件,需要完成前面几节所论述的部分. 首先要有一个持续集成的平台,使得服务在拆分的过程中,功能的一致性,这种一致性不能通过人的经验来,而需要经过大量的回归测试集,并且持续的拆分,持续的演

上云、微服务化和DevOps,少走弯路的办法

此文已由作者张亮授权网易云社区发布. 欢迎访问网易云社区,了解更多网易技术产品运营经验. 如果说一个项目的发展历程就像一段未知的旅程,那<云原生应用架构实践>就像一张地图,基于前人的探索标明了在这段旅途中将会碰到的障碍,并注明了越过这些障碍的方法. 最近,利用碎片化的时间把团队写的<云原生应用架构实践>通读了一遍. 作为一个解决方案架构师,我感觉收获很多,主要是对云原生架构有了一个系统的认识,并了解了一个从无到有.从小到大的项目,在整个成长过程中可能碰到的问题,以及解决这些问题的思

微服务化

很多传统企业看着互联网公司都进行着微服务化,因此也想享受微服务化带来的好处便对自己的系统进行改造,但微服务化 多“微”才是最优?有哪些拆分的原则? 架构原则 使用成熟的技术,不需要最先进最好的技术,要是自己人能够掌控的,不然出现莫名的问题,一两天都可能解决不了,你就等着被拿来“祭天”吧. 至少有一个冗余的实例,可水平扩展,确保一个实用多个负载,挂掉一个仍然能够正常运行,这里就要保证服务应用的无状态性. 确保数据中心能在地理上隔离,实现异地多活容灾,实现三城两地式物理布署,即使一个城市停电仍可提供

微服务化的感想

随着系统的代码越来越庞大,模块的增多,系统很难跟随业务的发展.想着做一些系统上的重构,但重构过程,既需要保证业务的开发,也需要保证重构工作的顺利进行,为此引进了微服务的框架架构. 近期的cps系统在进行一系列的重构工作中,我有幸也参与进来了.首先进行的是用户模块的微服务化,分多期进行,难度从简到难,一步一步将用户相关的代码抽离出来,进行独立部署.项目中如果涉及到用户相关的调用,第一期,使用jar包方式使用maven依赖的方式来进行调用,二期,将服务化,将服务相关的方面,使用独立部署,调用方式,使

业务初期野蛮生长阶段,微服务化比较麻烦

谈谈后端业务系统的微服务化改造 本文所提倡的微服务,是结合作者所在team自身业务特点来说的,适合自身的场景,是建立在团队人员素质到了,有成熟的基础设施和框架.中间件辅助,流程也规范,包括CI.敏捷等,团队都做好了准确去做这个转变,有足够的能力来实施,微服务化也就是水到渠成的事了. 相反,小团队在前期或者野蛮生长时期,不宜选择微服务,不但影响效率还带来额外的复杂度.成长型或者大公司,有成熟的流程.规范.基础设施.平台等,要想在整条交付链路上加速,就需要投入更多的资源保障微服务化,一切自动化了,能

网易容器云平台的微服务化实践(一)

作者:冯常健来自: 网易云-共创云上精彩世界 摘要:网易云容器平台期望能给实施了微服务架构的团队提供完整的解决方案和闭环的用户体验,为此从 2016 年开始,我们容器服务团队内部率先开始进行 dogfooding 实践,看看容器云平台能不能支撑得起容器服务本身的微服务架构,这是一次很有趣的尝试. 一旦决定做微服务架构,有很多现实问题摆在面前,比如技术选型.业务拆分问题.高可用.服务通信.服务发现和治理.集群容错.配置管理.数据一致性问题.康威定律.分布式调用跟踪.CI/CD.微服务测试,以及调度

微服务化的不同阶段kuberneter的不同玩法

作为容器集群管理技术竞争的大赢家,Kubernetes已经和微服务紧密联系,采用Kubernetes的企业往往都开始了微服务架构的探索.然而不同企业不同阶段的微服务实践面临的问题千差万别,注定要在技术路线上产生分叉.如何选择适合自己的技术,是每一个践行微服务的团队面临的第一个问题.网易云是Kubernetes的第一批重度用户,在不同业务场景下解决了很多挑战,在本文中,网易云首席解决方案架构师刘超梳理了基于Kubernetes构建微服务体系的进阶之路. 微服务化的必要性 一个产品的发展,通常可分为

FreeWheel业务系统微服务化过程经验分享

2016 年下半年开始,FreeWheel 开始将其业务系统从 Rails 单体应用逐步迁移到微服务,同时技术栈从 Rails 改为 Golang,两年之后,整个迁移接近尾声,FreeWheel 业务系统技术团队对外分享了它们在微服务化过程中的经验. 原有架构的问题 FreeWheel 是一家为客户提供数字视频广告管理技术和服务的公司.其业务端产品需要对接客户,提供视频广告投放优化界面,类似于 Web ERP,该业务系统采用 Rails 技术栈开发,其架构是一个典型的三层架构. 这个系统经过近十