微应用和微服务有什么区别

一、微应用和微服务有什么区别

1、微应用与微服务是分布式系统与面向服务架构中两种关键概念。微应用，将单一应用拆解为多个独立组件，每个组件专注特定功能或业务领域，具备独立部署与扩展能力，侧重于前端实现，构建灵活、可组合界面。

2、微服务架构则将大型应用分解为多个小型、自治服务，每个服务运行独立进程，通过轻量级通信机制交互，聚焦特定业务功能，实现系统高可维护性、伸缩性与灵活性。微服务目标在于提升系统管理便捷性。

3、微应用与微服务关系密切，微应用常作为基于微服务架构的前端界面层。通过调用多个微服务，微应用实现复杂用户交互与业务流程，利用微服务提供数据与执行业务逻辑，以此提供丰富用户体验。

4、采用微服务架构，后端系统拆分多个独立服务，不同团队可独立开发与维护服务。微应用集成这些微服务，实现前端界面、路由与用户体验管理。

5、综上，微应用是前端组织方式，微服务是后端架构风格。微应用借助微服务的灵活性与独立性，构建分布式、可扩展系统。微服务提供后端服务拆分与自治性，微应用调用这些微服务构建功能丰富界面。

二、探索微前端的三种技术方案

什么是微前端

首先我们应该先知道什么是微服务

首先我们应该先知道什么是微服务

微服务是面向服务架构（SOA）的一种变体，把应用程序设计成一系列松耦合的细粒度服务，并通过轻量级的通信协议组织起来，具体地，将应用构建成一组小型服务。这些服务都能够独立部署、独立扩展，每个服务都具有稳固的模块边界，甚至允许使用不同的编程语言来编写不同服务，也可以由不同的团队来管理。

那么以微服务来类比，微前端也可以采用这种架构思想，将一个前端应用拆解成多个微应用，可独立开发、测试、部署，呈现给用户的是一个产品，内部原理实则是多个应用的集成或者内聚。

每个团队可以根据自己的技术栈来进行开发，各团队之间互不干扰，节省团队之间的技术沟通成本

即使各团队使用相同技术栈，彼此也不应该共享变量和状态

利用前缀的方式来区分不同项目之间CSS、BrowserAPI、WebEvent、Cookies或LocalStorage之间的冲突

使用浏览器事件进行通信，而不是构建一个全局的PubSub系统。如果你真的需要构建一个跨团队的API，尽量让它简单

即使JavaScript失败或尚未执行，Web应用程序的功能仍应有效。可以使用通用渲染和渐进增强来提高用户的感知性能

灵活性：技术栈无关，每个微应用可以是不同的技术栈

渐进性：增量升级，便于项目扩展和重构

独立性：每个微应用之间状态隔离，运行时状态不共享

敏捷性：独立开发、独立部署，部署完之后主框架自动完成同步更新

直接在需要插入的地方，使用iframe将所需要呈现的业务页面url插入即可，src的路径可以是当前项目也可以是其他项目的。这种方式在PC端的效果还算中肯，移动端呈现的效果不佳。iframe的优点是简单易用，没有什么学习成本，缺点也显而易见，seo不友好、适配的空间有局限性、可能发生多次请求产生性能问题。

以vue-cli搭建的项目举例，在multi-page模式下构建应用，每个page应该有一个对应的JavaScript入口文件，我们把每一个需要松耦合的项目当成一个子项目即新创建一个page，并且新增一个相应的入口文件page.main.js，在vue.config.js文件下做如下配置：

如上面代码所示，vue项目中配置了两个page，index和demo，对应的有两个main.js入口文件，当然public里也有对应的两个html文件，如图：

使用multi-page的方式实现微前端的思路是，将一个vue项目分化成若干不同的子项目，每个项目作为一个单页应用

这种方案也没有什么学习成本，只需要根据实际情况创建不同的page

在实际开发中，总体的架构方面是固定的，各个团队在不同的page下独立开发不同的模块，互不影响，团队之间唯一的交集可能是在修改vue.config.js文件的相关配置产生

以上是示例效果，存在两个page页面home和demo，从home跳转到demo，也可以从demo跳转回home。根据自己的场景，可以使用window.location.href或者window.location.replace在子应用间做跳转。

qiankun是蚂蚁金服技术团队基于single-spa开发的微前端框架，整体比较方便，提供基座应用，只需将各个微应用注册在基座后，便可以实现微前端架构，基座应用的运行不影响微应用，可以独立开发部署。

在主应用（基座）中注册微应用并启动：

微应用不需要额外安装任何其他依赖即可接入qiankun主应用，但是要在微应用中做以下两项操作：

微应用需要在自己的入口js（如main.js）(通常就是你配置的webpack的entryjs)导出bootstrap、mount、unmount三个生命周期钩子，以供主应用在适当的时机调用

以上是示例效果，两个微应用存在于主应用中，主应用就像是一个宿主环境的浏览器，每个微应用内部的切换就像iframe一样自然

#Micro-frontendArchitecturesonAWS

三、微前端qiankun手把手实践

遇到公司的巨石项目时不要慌，微前端或许是一个很好的很提案，很多小伙伴的公司或许都有自己的微前端的解决方案，如果没有，希望这篇文章能帮到你，下次再做公司巨石项目开发时，你可以尝试一下，让你公司的项目代码不再像个庞然大物，维护起来也可以心情舒畅，不至于打开项目代码瑟瑟发抖，如果你刚好还没了解微前端，那这篇文章你一定值得你看完

这里我们主要是分享由蚂蚁团队开源的qiankun，一个目前比较成熟的微前端的解决方案。笔者保姆心，多出来的废话请谅解

微前端的概念值的是将一个大型项目拆分成多个子项目，每个子项目各自独立，互不影响，又互相关联。我们举一个例子，假设说你们公司需要做一个医疗相关的后台系统，假设这个后台系统中需要实现科、教、研三个模块。首页好比如下图这样

点击各自的模块进入系统后的功能都已尽相同，这种情况下不管你用的是vue还是react，这个项目最终的代码量都是会比较庞大的，庞大的项目体积给我们带来的困扰一个是运行速度慢（说ssr的同学同统一当做杠精处理），打包速度慢，打开项目看着代码头皮发麻（我不相信只有我会这么觉得...），那么，试想一下，如果我们能把科、教、研，模块，各写成一个项目，再像个办法把这三个项目都整合成一个项目，那么开始起来岂不是快乐??3？好了你理解微前端概念主要是干什么的了

那么微前端架构的核心价值是什么呢：

技术栈无关\主框架不限制接入应用的技术栈，微应用具备完全自主权

独立开发、独立部署\微应用仓库独立，前后端可独立开发，部署完成后主框架自动完成同步更新

增量升级\在面对各种复杂场景时，我们通常很难对一个已经存在的系统做全量的技术栈升级或重构，而微前端是一种非常好的实施渐进式重构的手段和策略

独立运行时\每个微应用之间状态隔离，运行时状态不共享

如果能做到这几点，嘿嘿嘿，想想就开心不是吗

前面说到，将多个大模块分割成独立的应用，那么如何将多个子应用再整合起来，这里我们就用qiankun来实践一波

动手之前，我们先假设我们有一个base项目，作为主应用，一个m-react作为子应用，另一个m-vue作为另一个子应用。\

这里的base我用的脚手架npxcreate-react-appbase创建的一个react默认18版本的项目作为要整合资源的主项目，这里17,18无所谓

create-react-appm-react创建的react17版本做为子应用（注意react的版本，这里使用最新的18版本会有个别问题，我还在努力看react18的文档，暴风哭泣...）

vuecreatem-vue创建的vue3的项目最为子应用，你要是用习惯了vue2也没关系，自己知道哪里可以改webpack的配置就行

好了，一主二子三个项目创建好了，接下来就是如何实现将m-react和m-vue整合到base中。（前面提到微前端跟技术栈是没有关系的哈）

第一步来到base下，先安装一个路由和乾坤，

现在我们希望当点击vue应用时，能访问m-vue应用，点击react应用时能访问m-react应用

这时就需要将这两个子应用都注册到base中，在base>src中创建registerApps.js文件

因为代码中有注释，就不进行一一讲解含义了，相信你能明白的

注册好了这两个子应用之后，我们将registerApps.js文件引入到base>src>index.js中

再次启动base项目，点击vue应用效果：

路由来到了但是现在在报错，因为我们的m-vue应用还没有启动，所以现在在base中注册m-vue是不生效的，那么我们先来m-vue应用中开发点东西

因为我们在base中注册的vue应用端口号是8080，而vue脚手架默认启动的端口号就是8080，所以刚刚刚好，但是如果你想修改端口号的话，就要改掉上文中entry:'//localhost:8080',??//子应用的访问地址处的端口，并且修改m-vue应用中的配置，在m-vue项目根目录下创建vue.config.js并写下

m-vue的配置项注释里面都有解释了，那么接下，qiankun需要我们要做的就是在m-vue这个子应用中导出相应的生命周期钩子

这里我们已经提前去装好vue-router并且配好了两个简单的页面(没装的自己装一下)，关于路由的配置我们不去做过多的阐述了，相信你自己，这里直接放上路由的代码吧（页面自行创建哈）

好的，子应用本身的运行时没有问题的，再来到base应用的启动界面看看

俨然已经可以看到在base主应用中，控制告诉了我们，当前这个m-vue的子应用已经挂载了。

这里需要解释一下:\子应用中的三个生命周期bootstrap,mount,unmount都是qiankun内定的，我们只需要暴露出来这三个这样名称的函数，它们便会和主应用中的生命周期整合在一起生效

好了，还没完，我们需要挂载vue应用到base中，在我们不断的点击页面切换子应用的过程中就涉及到了子应用的挂载和卸载，那么我们需要在qiankun的生命周期mount中，来实现子应用自己的挂载，接下来修改main.js

并且修改路由配置文件，删除多余部分

ok！没有问题，那么再来运行base主应用看看

一样ok！此时可以轻叹一声奶思！！

这样我们就已经成功的将m-vue子应用成功的整合到了base主应用中了，那么接下来我们继续将另一个m-react子应用也整合到base中

来到m-react项目中，同样的第一步，我们需要先修改m-react子应用（或者称微应用）的配置文件，修改react配置文件的方式有很多，要么执行npmruneject暴露出webpack的配置，但是这样暴露出来的配置文件太多，我们选择一个轻便点的，安装插件npmi@rescripts/cli-D，并在m-react根目录创建.rescriptsrc.js配置文件

这里的配置和vue中的配置相同不一样的知识语法而已，语法是插件决定的，我们不做过多阐述

另外react项目，我们希望它能运行在3001端口，在react中要修改项目运行的端口号和vue差别较大，我们需要在m-react根目录下创建.env文件

最后，因为我们使用插件rescripts重写了项目配置，所以我们需要将package.json中的项目启动命令修改成这样

完成这些工作后，启动m-react应用你可以看到：

m-react应用单独运行没有问题，那么我们再来看看base主应用中的效果

我猜你已经知道了问题在哪里了，我们还没有导出子应用中的三个生命周期呢！搞定它

这里的执行逻辑和vue中的一样，我们直接看主应用中的效果吧：

这是个题外话，问个问题\ReactDOM.unmountComponentAtNode()在react17中存在这样一个卸载函数，更新到18版本后这里这个卸载函数没了，所以文章开始就强调了注意版本，有知道18版本中怎么写的小伙伴欢迎指点一下

它也成功出现了，你现在分别去点击vue应用和react应用试试，两个子应用的切换没有问题，这就大功告成了！！

现在页面上这两个nav导航的样式居然会随着应用的切换而变化位置，这个问题也是微前端设计中最常见的问题，主应用和子应用样式冲突

那么这里qiankun当中目前采取的解决方案是一个css-module式的通过加前缀的方式来隔离样式

我们只需要在base主应用中的registerApps.js文件中修改