AI课工场|微服务前端之微前端

分而治之是利用微件拆分来达到工程拆分治理的思路，可以解决业务快速扩张、开发维护困难等问题。对于一个完整的产品来说，前端可视化层、后端服务层是必备的。
在后端，我们将原来的单体式应用拆分成了不同的微服务模块，微服务与微服务之间通过服务注册等进行通信和调用，共同对前端提供服务。而在前端，主要是通过后端接口获取数据，展示不同的内容给到用户，有web端、h5端等形式。在以前的开发方案中， web端、h5端都是由独立开发和维护，而实际上它们的业务逻辑基本一致，只是UI风格差异比较大，那么我们是不是可以把“共用”的部分抽离出来呢，这样可以避免重复开发与维护，极大的提高开发效率，这就是微前端的思想。
抽离出来的方案有两种，即物理抽离、逻辑抽离。对于物理抽离来说，就是把共用的模块放在一起，前端是通过common文件夹进行引用，后端则是通过jar包、lib库进行引用。这会带来一个问题是随着业务变得越来越复杂，共用模块内容会越来越多，从而导致开发寻找到相应的内容会很困难，开发速度、构建速度、部署速度也会越来越慢，等到上线后，线上出现故障，排错也比较困难。所以物理隔离不是长期方案，长期方案来说就是逻辑隔离，将整体业务进行拆分，共用（比如子业务工程之间的路由注册、路由切换）逻辑拆离出来，子业务之间单独成一个工程进行开发。
事实上，微前端架构整体思路和微服务架构演变一致。在以前的单体式前端、单体式后端应用中，前端请求的分发路由是通过框架来完成的，即框架将路由指定到对应的组件或内部服务中，微前端就是把以前的应用内的组件调用拆分成了更细的应用间的组件调用，通过路由来找到对应的应用，再由应用分发到对应的组件；后端请求把内部之间的函数调用变成了远程调用。
所以微前端不过是把用于服务器端的思想用在了浏览器端，将web应用由单一的单体应用拆分为多个微前端应用聚合而成的应用，应用与应用之间可以独立开发、独立运行、独立部署。
目前在业内有这几种方式可以实现微前端：
路由分发式，即使用http服务器的路由重定向应用；
Iframe式，即通过组合多个独立应用，子应用与子应用之间设计通讯、加载机制；
通用中心路由基座式，即子应用与子应用之间技术栈可以不一样，可以是Augular、React、Vue中的任何一种，完全独立，互不依赖，子应用与子应用之间的通信由基座工程进行管理；
特定中心路由基座式，即子应用与子应用之间的技术栈必须一致，子应用可以使用基座的能力进行通信。
在这些微服务前端方案中，业务可以根据自己的特点来选择最适合的方案。目前最通用、最契合微服务思想的便是通用中心路由基座式了，我们也简单的介绍一下这种微前端方案。在具体实现上一般包含四个部分：动态路由、动态配置、子应用接口设计、复用方案设计。
在动态路由方案中，一般拆分成基座路由和子应用路由，用户请求先打到基座路由，然后加载子应用入口文件，动态注册子工程路由即可，整个的流程如下，非常简单。在动态配置方案中，要解决的是基座工程如何知道子应用的资源路径，从而加载js、css资源，通过在配置文件中标识业务线的key、资源地址的value ，在从基座到子应用切换时拉取配置信息即可。在子应用的接口设计中，暴露给注册给基座应用的对象即可。在复用方案设计中，把子应用相同的依赖，如框架基本库、业务组件等全都放在基座工程，这样子应用的代码中主要导入这个库就可以了。
【AI课工场|微服务前端之微前端】
分页标题
本文插图
通过将前端应用拆分成微前端应用，整个业务的可维护性得到了提高，实现了关联部分高内聚、不关联部分低耦合。子应用可以独立开发、独立部署、独立上线，互不影响，子应用的构建、部署速度也提高了很多，减少了等待时间，加快了上线时间，提高了开发效率。
通过本文的介绍，想必你对微服务的思想更加了解了吧？它是一种软件架构设计思想，存在于前端、后端服务中，结合实际业务场景，进行合理的架构设计、服务拆分，必定会更好的提高开发效率。