前端微服务设计

近些年，前端发展呈百家争鸣式发展，框架层出不穷，版本更是迭代不穷，难免会出现前端项目技术栈不统一、所用框架版本不统一的情况。

如若某些项目，没有新的功能加入，又能线上稳定运行，但其技术栈却用的是 vue1.0，为了将其结合到新应用中去而对其重构，成本会很高。然而，微服务可以帮我们解决这个问题。

在既不重写原有系统的基础之下，又可以抽出人力来开发新的业务。其不仅仅对于业务人员来说是一个相当吸引力的特性，对于技术人员来说，不重写旧的业务，能在一些新技术上做挑战，也是一件很有意思的事情。

除此之外，在这两三年里，移动应用出现了一种趋势，用户不想装那么多应用。而往往一家大的商业公司，会提供一系列的应用。这些应用也从某种程度上，反应了这家公司的组织架构。然而，在用户的眼里他们就是一家公司，他们就只应该有一个产品。相似的，这种趋势也在桌面 Web 出现。聚合成为了一个技术趋势，体现在前端的聚合就是微服务化架构。

理想的前端微服务化，应该是符合如下几个特点：

路由分发式微前端，即通过设置路由，将不同的业务分发到不同的、独立前端应用上。其通常可以通过 HTTP 服务器的反向代理来实现，又或者是应用框架自带的路由来解决。

就当前而言，通过路由分发式的微前端架构应该是采用最多、最易采用的 “微前端” 方案。但是这种方式看上去更像是多个前端应用的聚合，即我们只是将这些不同的前端应用拼凑到一起，使他们看起来像是一个完整的整体。但是，它们并不是一个完整的整体，每次用户从 A 应用到 B 应用的时候，往往需要刷新一下页面。

通常可通过 nginx 配置反向代理，来进行路由分发，从而实现前端微服务。

它适用于以下场景：

iframe 可以创建一个全新的独立的宿主环境，这意味着我们的前端应用之间可以相互独立运行。

采用 iframe 有几个重要的前提：

即何时加载、卸载应用，如何监听应用事件等。

不论是基于 Web Components 的 Angular，或者是 VirtualDOM 的 React 等，现有的前端框架都离不开基本的 HTML 元素 DOM。

那么，我们只需要：

第一个问题，创建 DOM 是一个容易解决的问题。而第二个问题，则一点儿不容易，特别是移除 DOM 和相应应用的监听。当我们拥有一个不同的技术栈时，我们就需要有针对性设计出一套这样的逻辑。现有的框架有single-spa、qiankun、mooa等

常见的方式有：

其次，采用这种方式还有一个限制，那就是：规范！ 规范！ 规范！。在采用这种方案时，我们需要：

Web Components 组件可以拥有自己独立的 Scripts 和 Styles，以及对应的用于单独部署组件的域名。然而它并没有想象中的那么美好，要直接使用纯 Web Components 来构建前端应用的难度有：

现有的微前端框架有single-spa、qiankun、mooa。其均是在前端框架之上设计通讯、加载机制来实现的。

首先启动Nacos，按照上篇文章的步骤，启动Nacos服务和项目，访问Nacos的web页面。确保项目中的服务都注册到注册中心当中了。在application.yml同级目录下添加bootstrap.yml，在Spring boot项目中bootstrap.yml会比application.yml优先初始化，所以我们需要在bootstrap.yml中引入Nacos官方指定的配置文件即可（上篇文章中已经把Nacos作为配置中心的配置写入了application.yml，现在只需要把它从applicaiton.yml中剪切出来即可， 其中的spring:application:name会作为Nacos中新增配置时的Data ID，需要留意 ），再新增属性gorup进行分组测试，如下图

接着打开Nacos的服务的web页面，打开配置管理->配置列表，点击右侧新增按钮，进行新增。

Data ID： bootstrap.yml配置文件中spring:application:name对应的名称 ；

Group：指定分组（便于不同环境下的项目配置管理，因为笔者这里属于测试，所以填写的是和上文中的配置文件中group对应的test一致）；

描述：针对于该配置的描述；

配置格式：配置文件的格式，要和Data ID中的后缀格式一致（这里笔者用的是yml，那么下面就选择yaml，注意该位置也可以选择properties，但是必须和上面bootstrap.yml文件中的file-extension的值相匹配）；

配置内容：具体的配置内容（这里笔者将项目中的application.yml中的配置全部拷贝至其中）；

测试启动consumer服务，在application.yml中为空的时候，项目启动端口还是如Nacos配置中的9011，说明项目依赖Nacos的配置中心成功，其他服务如法炮制即可：

新增一个测试Controller，然后加上@RefreshScope注解，表明该Controller中的配置数据为自动刷新 。

编辑Nacos中的配置文件consumer新增相关参数type: test，访问Controller，返回test。效果如下图：

将Nacos中consumer.yml文件的type: test修改为type: prod，在不重启项目的情况下重新访问对应的controller，效果如下图：

因为Dubbo是属于各个服务之间都要公用的依赖，所以将其引入cloud-common当中，详细的版本可以去 mvnrepository 搜索合适自己项目的

引入依赖后需要编写消费者服务中的配置文件，将Dubbo服务注册至Nacos，新增如下内容，其中subscribed-services指的是生产者服务，prot：-1指的是端口随机，registry:address:指的是Dubbo对应的注册中心那这里就应该设置为Nacos

接下来新增接口服务，项目类型为Maven项目，在项目中新增一个接口。并在cloud-provider（生产者）和cloud-consumer（消费者）pom.xml文件中都引入该模块

在生产者实际服务中实现该接口对应的方法

在服务消费者的Controller中引入该Service，并在该Service上加入@Reference注解，注意在引入jar包的时候选择带有Dubbo的，不要使用Jdk原生的

编写消费者服务中测试Dubbo调用的接口，进行测试，测试结果如下图：

微服务架构搭建熔断有三种方式。

第一种：

1、引入pom.xml依赖：

2、在启动类上加上注解：@EnableHystrix

3、声明接口：

第二种

1、引入熔断依赖

2、Feign自带熔断，需要手动打开

3、定义Fallback类实现feign接口

第三种

1、引入熔断依赖

2、Feign自带熔断，需要手动打开

3、定义一个熔断工厂类实现FallbackFactory接口，并定义好需要熔断处理的Feign接口泛型。

---