微服务网关的基础职能——路由

微服务网关的基础职能——路由

网关（Gateway）这个词我们应该都很熟悉了，它在计算机科学中，尤其是计算机网络中十分常见，主要是用来表示位于内部区域边缘，与外界进行交互的某个物理或逻辑设备，比如你家里的路由器就属于家庭内网与互联网之间的网关。

在微服务环境中，网关是微服务集群中必不可少的设施之一。

微服务中网关的首要职责，就是以统一的地址对外提供服务，将外部访问这个地址的流量，根据适当的规则路由到内部集群中正确的服务节点之上。也正是因为这样，微服务中的网关，也常被称为“服务网关”或者“API 网关”。

网关 = 路由器（基础职能） + 过滤器（可选职能）

网络层次与协议

负载均衡器与服务网关的区别在于，网关必须能够识别流量中的特征。这意味着网关能够支持的网络层次、通讯协议的数量，将会直接限制后端服务节点能够选择的服务通讯方式：

• 如果服务集群只提供如 Etcd 这类直接基于 TCP 访问的服务，那就可以只部署四层网关，以 TCP 报文中的源地址、目标地址为特征进行路由；
• 如果服务集群要提供 HTTP 服务的话，就必须部署一个七层网关，根据 HTTP 的 URL、Header 等信息为特征进行路由；
• 如果服务集群要提供更上层的 WebSocket、SOAP 等服务，那就必须要求网关同样能够支持这些上层协议，才能从中提取到特征。

这里是一段基于 SpringCloud 实现的 Fenix’s Bootstore中，用到的 Netflix Zuul 网关的配置。Zuul 是 HTTP 网关，“/restful/accounts/”和“/restful/pay/”是 HTTP 中 URL 的特征，而配置中的“serviceId”就是路由的目标服务。

routes:
    account:
      path: /restful/accounts/**
      serviceId: account
      stripPrefix: false
      sensitiveHeaders: "*"

    payment:
      path: /restful/pay/**
      serviceId: payment
      stripPrefix: false
      sensitiveHeaders: "*"

**最后呢，我还想给你一个提醒：现在，围绕微服务的各种技术都处于快速发展期，我其实并不提倡你针对每一种框架本身，去记忆配置的细节，也就是你并不需要去纠结前面给出的这些配置的确切写法、每个指令的含义。因为如果你从根本上理解了网关的原理，那你参考一下技术手册，很容易就能够将前面给出的这些信息改写成 Kubernetes Ingress Controller、Istio VirtualServer 或者是其他服务网关所需的配置形式。**OK， 我们再来了解下服务网关的另一个能够支持路由的重要因素：性能与可用性。

性能与可用性

性能与可用性是网关的一大关注点。因为网关是所有服务对外的总出口，是流量必经之地，所以网关的路由性能是全局的、系统性的，如果某个服务经过网关路由会有 10 毫秒的性能损失，就意味着整个系统所有服务的性能都会降低 10 毫秒。

网关的性能与它的工作模式和自身实现都有关系，但毫无疑问，工作模式是最主要的。如果网关能够采用三角传输模式（DSR，即数据链路层负载均衡模式），原理上就决定了性能一定会比代理模式来的强（DSR、代理等都是负载均衡的基础知识，你可以去回顾复习一下）。

不过，因为今天 REST 和 JSON-RPC 等基于 HTTP 协议的接口形式，在对外部提供的服务中占绝对主流的地位，所以我们这里所讨论的服务网关默认都必须支持七层路由，这样通常就默认无法转发，只能采用代理模式。

那么在这个前提约束下，网关的性能就主要取决于它们是如何代理网络请求的，也就是它们的网络 I/O 模型了。

网络 I/O 的基础知识

在套接字接口的抽象下，网络 I/O 的本质其实是 Socket 的读取，Socket 在操作系统接口中被抽象为了数据流，而网络 I/O 就可以理解为是对流的操作。

对于每一次网络访问，从远程主机返回的数据会先存放到操作系统内核的缓冲区中，然后再从内核的缓冲区，复制到应用程序的地址空间，所以当一次网络请求发生后，就会按顺序经历“等待数据从远程主机到达缓冲区”和“将数据从缓冲区拷贝到应用程序地址空间”两个阶段。

同步就是指调用端发出请求之后，在得到结果之前必须一直等待，与之相对的就是异步，在发出调用请求之后将立即返回，不会马上得到处理结果，这个结果将通过状态变化和回调来通知给调用者。而阻塞和非阻塞 I/O 针对请求处理的过程，就是指在收到调用请求、返回结果之前，当前处理线程是否会被挂起。

网关的可用性考量

另外，由于网关具有唯一性，它不像之前讲服务发现时的那些注册中心一样，可以直接做个集群，随便访问哪一台都可以解决问题。所以针对这个情况，在网关的可用性方面，我们应该考虑到以下几点：

• 网关应尽可能轻量。尽管网关作为服务集群统一的出入口，可以很方便地做安全、认证、授权、限流、监控等功能，但在给网关附加这些能力时，我们还是要仔细权衡，取得功能性与可用性之间的平衡，不然过度增加网关的职责是很危险的。
• 网关选型时，应该尽可能选择较成熟的产品实现。比如 Nginx Ingress Controller、KONG、Zuul 等等这些经受过长期考验的产品，我们不能一味只考虑性能，选择最新的产品，毕竟性能与可用性之间的平衡也需要做好权衡。
• 在需要高可用的生产环境中，应当考虑在网关之前部署负载均衡器或者等价路由器（ECMP），让那些更成熟健壮的（往往是硬件物理设备）的设施去充当整个系统的入口地址，这样网关就可以很方便地设置多路扩展了。

小结

这节课我们主要探讨的话题是网关，但我只给你介绍了网关的路由职能，其他可以在网关上实现的限流、容错、安全、认证等等的过滤职能，在课程中都有专门的讲解，所以这里我们就不展开了。那么在路由方面，因为现在我们所讨论的服务网关默认都必须支持七层路由，通常就默认无法转发，只能采用代理模式。因此你要掌握这样一个核心知识点：**在必须支持七层路由的前提下，网关的性能主要取决于它们是如何代理网络请求的，也就是说，你要了解它们的网络 I/O 模型。**现在，在学习了典型的网络 I/O 模型的工作原理之后，希望你在后面的学习或者实践过程当中，看到网关的 I/O 模型，你就能够对它的特点与性能有个大致的判断。