微服务网关和服务发现调用整理

本文为个人整理笔记，个人理解使用。不保证准确性，仅供参考。

SOA中的ESB 理解为 ESB（服务器软件）是对各个子系统间相互调用的集中调用点（集中管理）。

微服务各个业务功能组件化，且服务之间是可以互相调用的，如GRPC。（服务注册知道地址就可以了，分散管理）。对于外部也有一个api服务网关（参考这里很清晰）。

服务网关=路由转发+过滤器

1、路由转发：接收一切外界请求，转发到后端的微服务上去；

2、过滤器：在服务网关中可以完成一系列的横切功能，例如权限校验、限流以及监控等，这些都可以通过过滤器完成（其实路由转发也是通过过滤器实现的）。

为什么需要服务网关

上述所说的横切功能（以权限校验为例）可以写在三个位置：

每个服务自己实现一遍

写到一个公共的服务中，然后其他所有服务都依赖这个服务

写到服务网关的前置过滤器中，所有请求过来进行权限校验

第一种，缺点太明显，基本不用；

第二种，相较于第一点好很多，代码开发不会冗余，但是有两个缺点：

由于每个服务引入了这个公共服务，那么相当于在每个服务中都引入了相同的权限校验的代码，使得每个服务的jar包大小无故增加了一些，尤其是对于使用docker镜像进行部署的场景，jar越小越好；

由于每个服务都引入了这个公共服务，那么我们后续升级这个服务可能就比较困难，而且公共服务的功能越多，升级就越难，而且假设我们改变了公共服务中的权限校验的方式，想让所有的服务都去使用新的权限校验方式，我们就需要将之前所有的服务都重新引包，编译部署。

而服务网关恰好可以解决这样的问题：

将权限校验的逻辑写在网关的过滤器中，后端服务不需要关注权限校验的代码，所以服务的jar包中也不会引入权限校验的逻辑，不会增加jar包大小；

如果想修改权限校验的逻辑，只需要修改网关中的权限校验过滤器即可，而不需要升级所有已存在的微服务。

所以，需要服务网关！！！

网关之后的内网之间调用都不走网关（网关找微服务和RPC服务之间都依赖注册中心找到实际地址）

调用链路demo：nginx（性能超好的，单点）=》网关*n（鉴权，日志，限流，路由转发，负载均衡。如openResty，Zuul，Kong）=》open.service*n（聚合网关：查询聚合，熔断，超时）=》service

内部请求一般不走网关，否则压力太大。聚合网关一般是各自语言各自实现接口聚合（比如同时查订单服务和地址服务只需要查一个API就可以全部查出来，聚合网关使用RPC来查这两个底层服务的接口）。聚合网关到内部的service属于内部通信了，一般是RPC形式。网关到聚合网关一般是REST API形式。当然聚合网关不是必须的，网关也可以直接与service进行REST API调用。service之间的调用一般也是RPC。聚合服务/网关 和RPC服务 都依赖注册中心找实际的服务（集群）IP地址。

以kong与consul为例来分析调用过程：根据路由找到服务名，然后到注册中心（同一服务可能注册了集群，LB给出一个）查出服务地址ip:port。这就是服务发现。然后实际的服务地址返回响应内容。

路由：

网关中还有个概念叫路由，一个请求过来了根据路由规则分析出是请求的哪个服务。然后跟注册中心说：这个XX服务有木有？没有？那404！有？服务下有几个实例，都告诉我我自己找一个或者你告诉我一个能用的。然后把请求往某个服务实例脸上一甩，快去办，办好了上报结果！拿到结果后再回手一抛，搞定！

不说其他的，你就直接访问吧，那你每个微服务都需要配一个域名去访问。。。

如果没有网关一个请求过来了该哪个服务下的哪个实例处理？注册中心会一脸懵逼：别问我，这事不归我管。

demo1:

kong服务注册

demo2:

请求调用流程

1、kong添加路由

2、添加服务

根据路由找到服务名

3、consul服务发现

根据服务名找到服务地址

4、服务注册（中间流程）

其实在RPC的体系中，注册中心其实是可以缺失的

注册中心在RPC整个体系中担任的角色是比较重要的，但也是比较微妙的，它维护了所有服务提供者的所暴露服务的信息,最最核心的信息就是IP+端口号，服务消费者会在调用服务的时候去注册中心上去询问它远程调用服务的端口和IP地址，注册中心返回它所需要的信息，服务消费者拿着服务的IP+端口号，如果获取到多个IP的时候，再根据负载策略去远程调用服务，其实最最简单的注册中心的职责就是如此，注册中心的最核心的职责也是如此

但是，其实在RPC的体系中，注册中心其实是可以缺失的，因为假如服务消费者知道服务提供者的地址，就可以直接调用，不需要向注册中心去查询服务提供的地址，这是远程调用最最原生的调用方法，这种直接调用的策略有好有坏，好处就是直接，整个流程简单易懂，且容易维护，坏处也是很明显，就是不灵活，假如服务的地址改变了，我们需要手动修改服务提供的地址，不能动态的实时的去获取服务的实时地址，当然也就达不到服务治理的效果了

注册中心的职责是很明确的，简而言之：

1）服务提供者向其发送它提供的服务的一些基本信息

2）服务消费者来订阅服务

3）服务提供者实例下线的时候，实时通知服务消费者某个服务下线

当然还有一些服务治理的功能，比如：

1）服务审核，这是服务治理最最简单的操作了，因为某个服务提供者上线之后，都是需要审核的，如果不审核，可能会造成很多不必要的麻烦，有可能有些开发小新，不小心把开发环境的服务向线上服务注册，如果不审核，直接通过的话，就会造成线上接口调用线下服务的尴尬局面

2）负载策略的记录，比如默认是随机加权策略，如果管理者希望改成加权轮询的策略，需要通知服务消费者，访问策略的改变

3）手动改变某个服务的访问权重，比如某个服务默认负重是50，（最大100）的时候，但是此时这个服务实例所在的机器压力不大的时候，而其他该服务实例压力很大的时候，可以适当的增加该服务的访问权重，但是又不想让该服务下线，修改它的权重，所以我们可以在注册中心修改它的负重，然后通知服务消费者，这样就可以动态的修改负重了

4）一些持久化的操作，因为注册中心是无状态的，假如某个注册中心实例重启之后，以前的一些审核信息，修改的访问策略信息就会消失，这样就会需要用户重新一一审核，这是很麻烦的，所以需要将这些信息落地，持久化到硬盘，然后每次重启注册中心实例的时候，去读取这些信息

---

ODP 思路整理

服务名：XXX。 HTTP 服务。

在API网关中配置  集群列表（集群拥有独立域名/L5），访问域名则访问该集群。如测试域名 集群，正式域名集群。=》访问域名/URI  先到网关

集群中配置整个网关路由的转发规则，如/转发到后端组A1，如A服务的80端口，/XX转发到后端组B1，是B服务的80端口。服务配置  各自配置负载均衡策略，健康检查和服务熔断等等。=》网关根据路由找到绑定路由的    后端配置组，后端配置组绑定了具体服务（兑换代码）

A服务和B服务是自己起的，CICD部署，单服务是个集群，如A服务分配3个docker 虚拟机器。=》具体服务是个集群，LB在配置组设置

ODP就是服务集群的概念。写一个服务（HTTP，GRPC...）搭建成多台机器的集群，用网关路由来访问控制这些服务集群，至于最终具体调用哪台机器IP和端口由配置的LB策略负责。