微服务和前端的关系

一、微服务和前端的关系

微服务是后端架构，前端如vue框架使用微服务和其他语言类似，分为前端团队和后端开发相互开发对接即可。

推荐一个开源项目。采用vue3作为前端框架。

MateCloud基于Spring Cloud Alibaba推出的微服务快速开发平台，集成Nacos 2.0.3、Sentinel 1.8.2、Jetcache等诸多中间件。前端采用Vue3.2.4、Vite 2.5.1、Ant-Design-Vue 2.2.6、TypeScript的大型中后台解决方案。其中前端4.0.8-M2版本正在发布，实现了系统管理的基础功能，主要包括菜单管理、用户管理、角色管理、部门管理、日志管理、客户端管理等功能。正持续更新中，欢迎体验。

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

什么是微前端

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

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

微服务是面向服务架构（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

三、前后端分离微服务架构如何设计

前端开发人员专注业务的页面呈现，非常注重用户体验度，也是与各种角色打交道最多的。

如果前后端职责划分很清楚的话，后端更多开发工作在于业务接口设计、业务逻辑处理以及数据的持久化存储，并提供详细的接口设计文档给前端开发人员使用。

2、业务 API接口开发：根据根据需求文档进行业务接口开发

4、接口对接：与前端开发人员接口对接

5、前后端联调测试：包括页面展示以及接口数据

h5、 css、 nodejs/ vue/ angular/ react、 webpack、 hbuilder/ vscode等

SpringCloud/ Springboot、 SpringMVC、 ORM框架、数据库、缓存框架（ Redis， Codis, Memcached等），大数据框架（ Hadoop/ Spark/ hive/ Hbase/ Storm/ ES/ Kafka）等等

最好选择成熟稳定，易上手、开发效率高的技术，因为实际项目开发时间是有限的，开发人员没有多少精力放在学习和深度研究技术上。

后端开发提供接口设计文档，详细写明每个接口的请求地址、请求参数、响应参数等等；一般采用 REST风格以 JSON格式提供数据。

一个接口设计的好坏，直接影响到前后端的一些沟通协调问题。

依笔者的经验来看，如果后端接口不稳定，会导致前端开发人员反复修改页面数据呈现。常常出现后端开发说这是前端问题，前端开发说是后端问题，来回扯皮，沟通效率低下。

一个接口的业务容量大小，往往代表前后端工作量的大小。

如果一个接口的业务容量太小，前端需要分阶段处理的事情就多，尤其是对多个接口 Ajax异步处理；

如果一个接口的业务容量太大，那么业务耦合性高，万一需求变更，后端程序改动大，不利于程序的扩展。

不能老是按照传统WEB（ js/h5/css/后端代码放在一个工程）开发思维去看待前后端分离

以前传统 WEB开发，开发人员从需求到设计到开发基本上是一个人。

而前后端分离后，前端只负责页面呈现，后端更注重业务逻辑处理以及数据的持久化，双发都有自己的侧重点，工作量上有私心。

第一定律： Communication dictates design（组织沟通方式会通过系统设计表达出来）

第二定律： There is never enough time to do something right, but there is always enough time to do it over（时间再多一件事情也不可能做得美，但总有时间做完一件事情）

第三定律： There is a homomorphism from the linear graph of a system to the linear graph of its design organization（线型系统和线型组织架构间有潜在的异质同态特性）

第四定律： The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems（大的系统组织总是比小系统更倾向于分解）

前后端分离后，拆分的服务会带来线上部署以及如何监控运维的复杂性。

总体来说，前后分离所带来的好处还是更明显的。一个成熟的前后端分离的团队，文档化约定，前后端职责分离、接口约定都是做得比较好的