一、网关服务

1、网关模式

网关作为架构的最外层服务，用来对立拦挡各个端口的申请，辨认申请合法性，拦挡异样动作，并提供路由和负载能力，爱护业务服务；这种策略与外观模式殊途同归。

网关服务和门面类服务有局部的逻辑类似，网关服务的拦挡偏重解决通用的策略和路由负载，而不同的门面聚合服务偏重场景分类，例如常见的几种门面服务：

• Facade：服务产品凋谢的端口申请，例如Web，App，小程序等；
• Admin：通常服务于外部的管理系统，例如Crm，BI报表，控制台等；
• Third：聚合第三方的对接服务，例如短信，风控，动作埋点等；

不同的门面服务中，也会存在特定的拦挡策略，如果把Facade、Admin、Third等校验都集成在网关中，很显然会减轻网关服务的累赘，不利于架构的稳固。

2、Gateway组件

如果微服务架构接触较早的话，初期网关中常采纳的是Zuul组件，起初SpringCloud才公布Gateway组件，是以后罕用选型。

• 申请拦挡：网关作为API申请的凋谢入口，实现申请的拦挡、辨认校验等是根底能力；
• 定制策略：除惯例身份辨认，依据服务场景设计相应的拦挡逻辑，尽量拦挡异样申请；
• 服务路由：申请通过拦挡后转发到具体的业务服务，这里存在两个外围动作路由和负载；

作为微服务架构中罕用的选型组件，上面从应用细节中详细分析Gateway网关的应用形式，与其余组件的对接流程和模式。

Nacos作为微服务的注册和配置核心，曾经是当下罕用的组件，并且Nacos也提供Gateway组件的整合案例，首先就是把网关服务注册到Nacos：

spring:  cloud:    nacos:      config:        server-addr: 127.0.0.1:8848      discovery:        server-addr: 127.0.0.1:8848

Nacos治理网关服务注册和相干配置文件，在我的项目中通常与nacos共用一套MySQL库，用来治理网关的服务路由数据，是当下比拟常见的解决方案。

3、网关拦挡

GlobalFilter：网关中的全局过滤器，拦挡通过网关的所有申请，通过相应的校验策略，判断申请是否须要执行：

@Order(-1)@Componentpublic class GatewayFilter implements GlobalFilter {    @Override    public Mono<Void> filter(ServerWebExchange exchange, GatewayFilterChain chain) {        ServerHttpRequest request = exchange.getRequest();        return chain.filter(exchange);    }}

通常在网关中会执行一些必要共性拦挡，例如：IP黑白名单，Token身份令牌，在申请中获取对应参数，执行相干服务的校验办法即可。

4、动静路由

4.1 路由定义

在服务路由的实现上，存在简单的逻辑和策略，来适配各种场景；路由的概念如何定义，能够查阅Gateway组件的源码RouteDefinition对象，构造波及到几个外围的属性：路由、断言、过滤、元数据：

• Route路由：由ID、转发Uri、断言、过滤、元数据组成；
• Predicate断言：判断申请和路由是否匹配；
• Filter过滤：能够对申请动作进行批改，例如参数；
• Metadata元数据：装载路由服务的元信息；

@Validatedpublic class RouteDefinition {    private String id;    @NotNull    private URI uri;    @NotEmpty    @Valid    private List<PredicateDefinition> predicates = new ArrayList<>();    @Valid    private List<FilterDefinition> filters = new ArrayList<>();    private Map<String, Object> metadata = new HashMap<>();}

通常把这些路由放在nacos库的config_route数据表中，围绕上述路由对象的构造，治理对应的表数据即可：

对于转发的指标uri也有不同的配置，这里抉择lb://服务注册名的模式，即把申请负载平衡调配到路由对应的服务节点，补充阐明一下Nacos组件外部采纳Ribbon负载算法，能够参考相干的文档。

4.2 治理路由

在路由的治理上有两个外围接口：Locator加载和Writer增删，并且还提供了聚合的Repository接口：

public interface RouteDefinitionLocator {    // 获取路由列表    Flux<RouteDefinition> getRouteDefinitions();}public interface RouteDefinitionWriter {    // 保留路由    Mono<Void> save(Mono<RouteDefinition> route);    // 删除路由    Mono<Void> delete(Mono<String> routeId);}public interface RouteDefinitionRepository extends RouteDefinitionLocator, RouteDefinitionWriter{}

这样通过定义路由治理组件，实现上述聚合接口，实现路由数据从数据表加载到利用的过程：

@Componentpublic class RouteFactory implements RouteDefinitionRepository {    @Resource    private RouteService routeService ;    // 加载全副路由    @Override    public Flux<RouteDefinition> getRouteDefinitions() {        return Flux.fromIterable(routeService.getRouteDefinitions());    }}

RouteService则是路由治理的服务类，治理配置数据以及实体对象与路由定义对象的转换：

@Servicepublic class RouteServiceImpl implements RouteService {    // 数据库路由实体，转换为网关路由的定义对象    private RouteDefinition buildRoute (ConfigRoute configRoute){        RouteDefinition routeDefinition = new RouteDefinition () ;        // 根底        routeDefinition.setId(configRoute.getRouteId());        routeDefinition.setOrder(configRoute.getOrders());        routeDefinition.setUri(URI.create(configRoute.getUri()));        // 断言        routeDefinition.setPredicates(JSONUtil.parseArray(configRoute.getPredicates()).toList(PredicateDefinition.class));        // 过滤        routeDefinition.setFilters(JSONUtil.parseArray(configRoute.getFilters()).toList(FilterDefinition.class));        return routeDefinition ;    }}

通过上述流程即可将路由信息长久化存储在数据库，如果服务节点很少，也能够间接在nacos的配置文件中治理。

4.3 匹配模式

Predicate断言其实就是一个匹配规定的设定，查阅PredicateDefinition相干源码可知，有Host、Path、Time等多种模式，通过上述数据可知本文采纳的是门路匹配，

因为采纳门路匹配的形式，会把/服务名拼接在uri起始地位，所以在配置过滤规定的时候设置StripPrefix去掉该路由标识。

申请进入网关之后，首先进入全局拦截器执行校验策略，测验通过之后匹配相干路由的服务，匹配胜利之后进行过滤操作，最终将申请转发到相应的服务，这就是申请在网关中要执行的外围流程。

二、注册与配置

Nacos在整个微服务体系中，提供服务注册与配置管理两个外围能力，通常在代码工程中只保留外围的bootstrap配置文件即可，能够极大简化工程中的配置并且进步相干数据的安全性。

1、服务注册

Nacos反对基于DNS和基于RPC的服务发现，并提供对服务的实时健康检查，阻止向非衰弱的主机或服务实例发送申请：

在服务的注册列表中能够查看注册信息，实例数衰弱数等，并且能够删除注册服务；在详情中能够查看具体实例信息，能够对服务实例进行动静高低线和相干配置编辑。

2、配置文件

通常会采纳namespace命名空间的治理，隔离开不同的服务的注册与配置，能够在nacos库中tenant_info查看，个别会存在如下几个分类：

这是最常见的命名空间，gateway网关比拟独立，seate事务的配置比较复杂，serve业务服务具备大量的公共配置，通常采纳如下的策略：

• application.yml：所有服务的公共配置，例如mybatis；
• dev||pro.yml：环境隔离配置，不同环境设置不同的中间件地址；
• serve.yml：服务的个性化配置，比方连贯的库，参数等；

spring:  application:    name: facade  profiles:    active: dev,facade  cloud:    nacos:      config:        prefix: application        file-extension: yml        server-addr: 127.0.0.1:8848      discovery:        server-addr: 127.0.0.1:8848

服务通过上述profiles参数会辨认和加载对应的配置文件，在这种管理模式中，环境的差别只在dev||pro.yml配置文件中保护即可，其余配置会绝对稳固许多。

三、服务间调用

1、Feign组件

Feign组件是申明式、模板化的HTTP客户端，能够让服务之间的调用变得更简略优雅，通常将服务提供Feign接口在独立的代码包中治理，不便被其余服务依赖应用：

/** * 指定服务名称 */@FeignClient(name = "account")@Componentpublic interface FeignService {    /**     * 服务的API接口     */    @RequestMapping(value = "/user/profile/{paramId}", method = RequestMethod.GET)    Rep<Entity> getById(@PathVariable("paramId") String paramId);}public class Rep<T> {    // 响应编码    private int code;    // 语义形容    private String msg;    // 返回数据    private T data;}

通常会把Feign接口的响应格局做包装，实现返参构造对立治理，有利于调用端的辨认，这里就波及到泛型数据的解决问题。

2、响应解码

通过继承ResponseEntityDecoder类，实现自定义的Feign接口响应数据处理，例如返参格调，数据转换等：

/** * 配置解码 */@Configurationpublic class FeignConfig {    @Bean    @Primary    public Decoder feignDecoder(ObjectFactory<HttpMessageConverters> feignHttpConverter) {        return new OptionalDecoder(                new FeignDecode(new SpringDecoder(feignHttpConverter)));    }}/** * 定义解码 */public class FeignDecode extends ResponseEntityDecoder {    public FeignDecode(Decoder decoder) {        super(decoder);    }    @Override    public Object decode(Response response, Type type) {        if (!type.getTypeName().startsWith(Rep.class.getName())) {            throw new RuntimeException("响应格局异样");        }        try {            return super.decode(response, type);        } catch (IOException e) {            throw new RuntimeException(e.getMessage());        }    }}

3、申请解析

采纳注解形式就轻松实现服务间的通信申请，查阅Feign组件的源码能够了解封装逻辑，其内在是把接口调用转换成HTTP申请：

• FeignClientBuilder：不采纳注解的形式间接构建Feign申请的客户端，该类有助于了解@FeignClient注解原理；
• FeignClientsRegistrar：即我的项目中采纳@FeignClient注解形式，该API中形容了注解的解析形式和服务申请的构建逻辑；

微服务工程的架构是一项简单和继续的过程，其中波及到的组件也非常繁冗，本文只是选取Gateway、Nacos、Feign三个根底组件做简略的总结，在其逻辑的了解上须要围绕该组件的外围性能和我的项目应用的API作为切入点，时常查阅源码和官网文档。

四、参考源码

利用仓库：https://gitee.com/cicadasmile/butte-flyer-parent组件封装：https://gitee.com/cicadasmile/butte-frame-parent