微服务6：通信之网关

微服务1：微服务及其演进史

微服务2：微服务全景架构 

微服务3：微服务拆分策略

微服务4：服务注册与发现

微服务5：服务注册与发现（实践篇）

1 概述
回顾下前面几篇关于微服务的介绍，我们可以了解到从单体系统到微服务，再到服务网格的演进过程。那单体系统和微服务相比，有哪些区别呢，下面是对功能性的对比?

微服务有诸多的有利条件，但是如果微服务的粒度比较细（按照业务功能拆分），则他们之间服务调用就会比较复杂，链路会比较长。 

  

比如上图中，我们按照职能将服务进行了拆分，这时候从不同的客户端（如Web、App、3rd）访问，就有可能访问不同的服务。而服务与服务之间又有上下游的协作，调用就变得错综复杂。

因此，在微服务架构体系下，服务间的通讯就显得非常重要。

你可能需要关注很多问题，包括不同的技术栈不同的开发语言之间的上下游交互，服务之间的注册与发现，请求认证，接入授权。

下游对上游进行调用的时候，上游怎么做负载均衡、故障注入、超时重复、熔断、降级、限流、ABTesting等，端到端之间如何实现监控和trace，这些都是微服务体系下需要去思考的问题。

要解决上面这些问题，微服务通信可以从三个方面进行讨论

2 服务之间的通信方式 
而微服务的通信，是在服务之间增加一个间接的中间层来完成服务间的通信过程。目前微服务的通信方式有以下三种：

1、基于网关的通信

2、基于RPC的通信

3、基于ServiceMesh的数据面（SideCar）的通信

接下来逐一介绍这三种通信方式的具体实现，本文先介绍基于网关的通信方式。 

2.1 基于网关的通信
 我们先看看，在没有网关的情况下，服务是怎么通信的？

  

如上图有3个客户端，在调用4个服务的接口。这种直连调用的方式有很多问题：客户端需要保存所有服务的地址，同时也需要实现一些系统级的容错策略。

比如负载均衡、超时重试、服务熔断等，非常复杂，并且难以维护。因为是在各客户端保存的服务地址，一旦某个服务端出现问题或者发生迁移，所有的客户端都需要修改并且升级。

另外如果再增加一个E svc，所有的客户端也需要升级。而且在某些场景下存在跨域请求的问题，每个服务都需要实现独立的身份和权限认证等等。

这些问题导致 服务间的通信过于复杂，对于开发和维护都不优化。

如果我们在客户端和服务端增加一层网关，所有请求都经过网关转发到对应的下游服务，客户端只需要保存网关的地址并且只和网关进行交互，这样就大大简化了客户端的开发。

  

如果需要访问用户服务，只需要构造右边这个请求发给网关，然后由网关将请求转发给对应的下游服务。

可以将网关简单理解为：路由转发+治理策略，治理策略是指和业务无关的一些通用策略，包括：负载均衡，安全认证，身份验证，系统容错等等

网关作为一个 API 架构层，用来保护、增强和控制对服务的访问。 

2.1.1 网关的主要功能
请求接入
1、为各种应用提供统一的服务接入

2、管理所有的接入请求：提供流量分流、代理转发、延迟、故障注入等能力

安全防护
用户认证、权限校验、黑白名单、请求过滤、防web攻击

治理策略
负载均衡、接口限流、超时重试、服务熔断、灰度发布、协议适配、流量监控、日志统计等

统一管理
1、提供配置管理工具

2、对所有服务进行统一管理

3、对中介策略进行统一管理

2.1.2 网关使用场景 
蓝绿部署
  

我们前面看到，在单体应用中，部署是一件比较麻烦的事情，每次的改动，都需要把整个应用程序都发布启动一次。而且系统规模越大，部署过程越复杂，时间越长。

而在微服务架构中，模块部署起来相对更快，更容易。你可以在短时间内对于同一个模块做多次部署，网关可以帮你实现蓝绿部署。

如图所示之前的用户服务版本是V1.0，然后部署V1.1版本，在网关上只需要做一个转发配置的修改，就可以迅速的将所有流量都流到新版本。 

灰度发布
 

 

类似金丝雀的理念，你对一次性升级版本感到担忧，可以先配置5%的流量达到新版本，让部分人试用一下，等线上观察一段时间后，可以逐步增加对新版本的流量百分比，最终实现百分之百切流。

负载均衡
  

此能力需要依赖服务注册和服务发现。 

服务熔断
 

网关还可以实现断路器的功能；如果某个下游忽然返回了大量错误，原因有可能是服务挂了或者网络问题或者服务器负载太高，如果此时继续给这个问题服务转发流量就可能会产生级联故障。

出问题的服务有可能产生雪崩，雪崩会沿着调用链向上传递，导致整个服务链都崩溃。

断路器可以停止向问题模块转发流量，在业务层面可以给用户返回一个服务降级之后的页面，开发人员就有相对充分的时间来定位和解决问题。 

2.1.3 开源网关
 

目前常见的开源网关按照语言大概分为上图的五种，如果按照使用数量和成熟度来划分的话，主流有4个，分别是 OpenResty、Kong、Zull和Spring Cloud。

其中 Zull 和Spring Cloud 是用java 实现，前两种是用Nginx+Lua实现的，其中，OpenResty 是一个基于Nginx+Lua实现的一个高性能web 平台，它集成了大量的第三方模块和lua库，用于方便的搭建高性能扩展性强的web 应用服务或者网关，

Kong 是一个基于OpenResty实现的一个高性能可扩展的API网关。从性能上来说：Kong的性能是最好的，其次分别是OpenResty、Spring Cloud 和Zuul。 

2.1.4 Nginx介绍
大家熟悉的Nginx是用C语言实现的一个开源、跨平台、高性能的HTTP和反向代理Web服务器，具有高度模块化、扩展性强、轻量级、资源消耗少、高并发、高性能等特点。

Nginx进程模型

  

 

Nginx是一个多进程模型，包含一个master 进程和多个worker 进程。

master 进程主要负责接收外部信号，向各个worker 进程发送信号，监控worker 进程的状态。当worker 进程异常退出后，服务不会中断的。master 进程会迅速拉起新的worker 进程来工作。基本的网络事件比如读写，都是在worker 进程来实现。

多个worker 进程是相互独立的，他们共同竞争来自客户端的请求，一个请求只能在一个worker 中进行处理。 

 

Nginx网络模型

首先，master 进程会listen socket，然后再fork出多个worker 进程，每个worker 进程都可以去accept 这个socket。
Nginx 提供了一把共享accept mutex锁来保证只有一个worker 进程可以把这个请求accept 成功。当这个worker 进程accept 连接成功之后，就可以进行请求的解析读取。

大概数据流：master 先 fork 多个worker 进程，然后当有client 来的时候，client 会连接到一个worker 进程里面，发送消息request。worker 进程再去读取、解析并处理，最终把response 返回给客户端。 

那么大家可以想一下这个问题，Nginx 采用了一个多worker 的方式来处理请求，每个worker 里面其实是只有一个主线程，那么它是怎么实现高并发的呢？

答案是采用异步非阻塞的方式；什么是异步非阻塞？

举个例子，当worker 收到一个来自client request 时，就会有一个worker 进程去处理它。但这个worker 进程并不是全程处理，worker 会处理到请求可能会发生阻塞的地方。比如它向后端服务器转发的这个request，并等待请求的返回，

worker 进程不会同步的等待，而是注册一个事件，如果下游返回了，再继续处理这个事件。如果有新的请求再进来，它就可以很快按照这种方式再进行处理。这其实就是非阻塞和IO多路复用。

一旦服务端返回了，就会触发worker 刚才注册的回调事件，worker 才会继续接手这个request。  

2.2 Zuul实战

 

业内主要的网关有如下几种：
1、zuul：是Netflix开源的微服务网关，可以和Eureka,Ribbon,Hystrix等组件配合使用，Zuul提供了动态路由、监控、弹性负载和安全功能。

2、kong: 由Mashape公司开源的，基于OpenResty（Nginx+Lua）的 API gateway。

3、Nginx + Lua：高性能的HTTP和反向代理服务器，Lua作为脚本语言，为Nginx提供执行程序，可以高并发、非阻塞的处理各种请求

下面我们以Zuul为案例，来测试下网关的使用。

2.2.1 配置路由规则
新建一个spring-clouid项目，导入Maven 依赖：
配置yaml文件：

server:
   port: 1002
 spring:
   application:
     name: zuul-proxy # 服务的名称
 eureka:
   instance:
     hostname: localhost
   client:
     service-url:  # 这边就保证了注册到 eureka-service 这个注册中心去
       defaultZone: http://localhost:1000/eureka/
 
 #自定义路由映射
 zuul:
   routes: #路由规则
     key-v1:  #自定义key
       path: /proxy/**   # 匹配路径，/proxy/ 会路由到 zuul-proxy服务
       serviceId: zuul-proxy
       url: http://${eureka.instance.hostname}:${server.port}/zuulservice/api/v1.0/  # 只要路径匹配，就转到这个服务对应路径下

Application中启动网关代理：

接口实现： 
 
 查看效果，proxy路由成功了：

 

   

2.2.2 测试负载均衡
我们在添加一个端口为1003的服务，跟端口为1002做zuul-proxy服务做负载均衡，这时候先修改 zuul-proxy 的yaml配置。  

zuul:
   routes: # 路由规则
     key-v1:  # 自定义key
       path: /proxy/**   # 匹配路径，/proxy/ 会路由到 zuul-proxy服务
       serviceId: zuul-proxy
 ribbon:
   eureka:
     enabled: true # 允许Ribbon使用Eureka
 zuul-proxy:
   ribbon:
     listOfServers: localhost:1002,localhost:1003 # 这边需要建立两个服务 1002,1003，在这两个服务间做负载均衡

创建一个module，命名zuul-client，增加注册依赖 



配置zuul-client的yaml文件：
 
 
 
 

补充一个接口，注意返回的信息不一样： 

 



 
 


网关 zuul-proxy 和 服务zuul-client都启动起来，可以看到如下的效果：