网关常用功能
统一接入：为各种无线应用提供统一接入服务；

高性能、高并发、高可靠性；

负载均衡，容灾切换（异地多活）。

安全防护：和安全部合作，IP黑名单，URL黑名单；

风防控制，防恶意攻击等。

协议适配：前端系统（http、http2）后端业务系统（RPC）；

长、短链接支持；

根据前端请求路由至相应的SOA服务并执行，返回结果给前端。

流量管控：服务降级；熔断；路由（异地多活中的应用）。

上图是在异地多活中网关的位置。在异地多活中，网关可能需要开发一个filter，它主要是做用户分片的路由。比如一个用户在上海帮助北京的朋友下单，应该通过网关路由分片到北京的机房，在北京的机房中把所有服务调用或者数据落地等等全部做完。所以网关在异地多活中也是相当重要的。

Spring Cloud Zuul
SpringCloud Zuul通过与Spring Cloud Eureka进行整合，将自身注册到Eureka Server中，与Eureka，Ribbon，Hystrix等整合，同时从Eureka中获得了所有其它微服务的实例信息。

首先一个http请求进来之后，一定会经过Zuul的Servlet，也可能会经过Zuul Filter Runner。Runner是统管所有Filter链的顺序或者数据的交互，Filter Runner主要是管理整个Zuul的生命周期。

用户请求进来后会有很多信息，通过Request Context的上下文在Zuul的生命周期中进行传递。

FilterLoader是当Zuul启动的时候会从本地或从动态Filter里的指定目录将Filter进行装载。

如图所示，Zuul除了自定义Filter之外，主要分为四种Filter类型。一种是“pre” Filters（易处理Filter），一种是“routing” Filters，就是服务路由的Filter。还有一种“post” Filters，以及“error” Filters。只要任何一个环节或者自定义的Filters出现异常之后，都会带着Request Context上下文信息直接跳到“error” Filters。如果全部流程跑完之后都没有一个error的话，肯定会调用到内部服务。

请求转发
当注解为@EnableZuulProxy时，测试转发。通过访问⽹网关的URL: http://localhost:8041/api-url/sc/order/1

可以正常地把请求的url转发到http://localhost:8000/sc/order/2

默认路由规则
说明默认情况下，Zuul会代理理所有注册到Eureka Server的微服务，并且Zuul的路由规则如下：

http://ZUUL_HOST:ZUUL_PORT/微服务在Eureka上的serviceId/**

会被转发到serviceId对应的微服务。

http://localhost:8040/sc-zuul-first-provider/sc/order/2

网关的负载均衡
http://localhost:8040/sc-zuul-first-provider/sc/order/2

通过网关访问服务提供者，负载均衡打出对应的日志

为什么要自研网关
1.网关配置实时生效，配置灰度，回滚等。

2.网关的性能，特别是防刷，限流，WAF等。

3.动态Filter，目前Zuul可以做到动态Filter，Filter配置下发，实时动态Filter。

4.对网关的监控，告警，流量调拨，网关集群。

5.流程审计，增加Dsboard便捷的操作。

基于Netty的GW架构和Zuul的设计差不多，但是在细节方面比如Filter面的处理方式、基于Netty的高性能网关入口以及Request Context的上下文处理，都有不同的地方。

对外的GW最好的方式就是以轻量的client端引入到GW-server中。因为包括服务治理等一定是由服务治理内部的一些服务注册与发现进行处理，client主要是做一个转发或者一些简单功能处理。

这样做的好处就是，当网关和服务治理框架升级的时候，两者之间的耦合就相当低了，网关随着版本的迭代可以自行升级。至于内部的REST服务或RPC服务只是通过client端做一个薄薄的转发，这样就可以做到解耦。

Filter只需要做单一职责。如上图所示，Filter有一个抽象的接口，当Filter启动的时候会对数据进行一些处理。还有一个抽象的Filter主要是做一些每个Filter本身数据的CRUD。

Filter数据的CRUD

每个Fliter有自己的缓存数据，缓存数据的CRUD通过观察者模式按key更新。

网关设计原则
1.每个Filter基于责任链，只做专一的一件事。

2.每个Filter有各自独立的数据。

3.损耗性能的Filter顺序往后放。

4.启动读取配置顺序，先远端，若远端失败，则读取本地。

5.集群网关，要注意数据的diff和灰度。

1. 尽量做到和服务治理框架解耦，易于接入，易于升级。
   
   我们知道在微服务架构风格中，一个大应用被拆分成为了多个小的服务系统提供出来，这些小的系统他们可以自成体系，也就是说这些小系统可以拥有自己的数据库，框架甚至语言等，这些小系统通常以提供 Rest Api 风格的接口来被 H5, Android, IOS 以及第三方应用程序调用。

但是在UI上进行展示的时候，我们通常需要在一个界面上展示很多数据，这些数据可能来自于不同的微服务中，举个例子。

在一个电商系统中，查看一个商品详情页，这个商品详情页包含商品的标题，价格，库存，评论等，这些数据对于后端来说可能是位于不同的微服务系统之中，可能我后台的系统是这样来拆分我的服务的：

产品服务 - 负责提供商品的标题，描述，规格等。
价格服务 - 负责对产品进行定价，价格策略计算，促销价等。
库存服务 - 负责产品库存。
评价服务 - 负责用户对商品的评论，回复等。
现在，商品详情页需要从这些微服务中拉取相应的信息，问题来了？

问题
由于我们使用的服务系统架构，所以没办法像传统单体应用一样依靠数据库的 join 查询来得到最终结果，那么如何才能访问各个服务呢？

按照微服务设计的指导原则，我们的微服务可能存在下面的问题：

服务使用了多种协议，因为不同的协议有不同的应场景用，比如可能同时使用 HTTP, AMQP, gRPC 等。
服务的划分可能随着时间而变化。
服务的实例或者Host+端口可能会动态的变化。
那么，对于前端的UI需求也可能会有以下几种：

粗粒度的API，而微服务通常提供的细粒度的API，对于UI来说如果要调用细粒度的api可能需要调用很多次，这是个不小的问题。
不同的客户端设备可能需要不同的数据。Web,H5,APP
不同设备的网络性能，对于多个api来说，这个访问需要转移的服务端会快得多
以上，就是我们构建微服务的过程中可能会遇到的问题。那么如何解决呢？

这种情况下，我们就需要一个今天要讲的这个东西， API 网关（API Gataway）。

API 网关
下面是百度上针对于 API 网关的介绍：

API网关是一个服务器，是系统的唯一入口。从面向对象设计的角度看，它与外观模式类似。API网关封装了系统内部架构，为每个客户端提供一个定制的API。它可能还具有其它职责，如身份验证、监控、负载均衡、缓存、请求分片与管理、静态响应处理。
API网关方式的核心要点是，所有的客户端和消费端都通过统一的网关接入微服务，在网关层处理所有的非业务功能。通常，网关也是提供REST/HTTP的访问API。服务端通过API-GW注册和管理服务。

Chris Richardson 在他的博客中把 API 网关划分为以下两种：

单节点 API 网关
Backends for frontends 网关
单节点网关

单节点的 API网关为每个客户端提供不同的API，而不是提供一种万能风格的API。

这个网关和微软在 eShop 项目中推荐的网关是一致的。

更多详细信息我会在下文进行说明。

Backends for frontends 网关

这种模式是针对不同的客户端来实现一个不同的API网关。

落地方案
我一直在寻思一种最佳的 API 网关的落地方案，以上两种 API 网关有什么问题呢？

通常情况下， API 网关要做很多工作，它作为一个系统的后端总入口，承载着所有服务的组合路由转换等工作，除此之外，我们一般也会把安全，限流，缓存，日志，监控，重试，熔断等放到 API 网关来做，那么可以试想在高并发的情况下，这里可能会出现一个性能瓶颈。

另外，如果没有开源项目的支撑前提下，自己来做这样一套东西，是非常大的一个工作量，而且还要做 API 网关本身的高可用等，如果一旦做不好，有可能最先挂掉的不是你的其他服务，而就是这个API网关。

这个时候，通常我们会去找一些开源的 API 网关项目，博主已经给你找好了，目前社区的关于 API Gataway 的项目有以下这些：

Tyk：Tyk是一个开放源码的API网关，它是快速、可扩展和现代的。Tyk提供了一个API管理平台，其中包括API网关、API分析、开发人员门户和API管理面板。Try 是一个基于Go实现的网关服务。

Kong：Kong是一个可扩展的开放源码API Layer(也称为API网关或API中间件)。Kong 在任何RESTful API的前面运行，通过插件扩展，它提供了超越核心平台的额外功能和服务。

Orange：和Kong类似也是基于OpenResty的一个API网关程序，是由国人开发的，学姐也是贡献者之一。

Netflix zuul：Zuul是一种提供动态路由、监视、弹性、安全性等功能的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。

apiaxle: Nodejs 实现的一个 API 网关。

api-umbrella: Ruby 实现的一个 API 网关。

我们来说说上面的这些开源项目适不适合作为 API 网关来供我们使用。

拿单节点网关来说，这种网关相当于是处于 Web 层和 Service 之间，用来聚合服务的？注意，我们需要的是聚合服务，而以上这些开源项目都不具备这个功能，我说的聚合具体指的是开箱即用。我们要想使用这些服务需要来自己对API网关过一些扩展或者是开发一些插件，这个时候问题就来了。扩展Tyk我需要会Go语言，扩展Kong我需要会写lua脚本，使用 zuul 还得会Java，这对于开发人员来说是不太现实的，那么这个时候怎么办？

有些同学可能会说 ASP.NET Core 可以使用 Ocelot，说得没错，我们可以通过引入Ocelot来处理API聚合服务这一块的业务，但是，这中间有一个问题，就像我在上面说的一样，这很容易造成性能问题，另外一方面，Ocelot的功能相比上面的那些开源项目来说功能要弱很多，具体体现在哪些方面呢？

除了最重要的高性能的IO模型和集群方案外， 比如会经常使用的 Dashboard 功能，这个对于运维来说是非常重要的，另外还有日志，监控，安全，服务发现，版本控制等。

但是上面的这些 API 网关缺少什么功能呢？ 比如超时，熔断，重试，聚合查询等。

注意：以下内容的这些想法全是我个人对于 API 网关的理解而诞生的，如有错误还请指正。

聪明的同学可能想出来了，怎么办呢？ 我们可以充分来结合两者的优势来在我们的 ASP.NET Core 应用程序中实现一个“双重网关”。

下面是我画的一个 API 网关在微服务架构中的一个作用图：

应该大部分同学都可以看懂，我就简单解释一下。

OpenResty Api Gateway
从左至右 HTTP 请求先由DNS在拿到第一手流量后负载均衡到基于 OpenResty 的 API Gataway 网关集群，在这个流程我们可以使用像 Kong,Orage,Tyk 这些开源的支持高并发高访问量 API 网关程序在做第一层流量的防护，在这一级我们可以做一些像身份认证，安全，监控，日志，流控等策略。除了这些我们还可以做一些服务的发现和注册（这个要看不同网关的支持程度），接口的版本控制，路由重写等。

Aggr Api Gateway
然后再由这些 API 网关把请求再负载到不同的 Aggr Api Gateway，在这里我们做聚合服务这个操作，具体体现也就是图中的黄色区域是需要由各个语言的开发人员来需要写代码实现的。具体流程也就是我们可以引入像 Ocelot 这种和语言相关的 API 网关开源项目，然后通过 NuGet 包引入之后通过 Json配置+聚合代码的方式来整合后端的各个微服务提供聚合查询等操作。这期间对于有需求的接口，我们可以应用超时，缓存，熔断，重试等策略。

从 Aggr Api Gateway 到后端微服务集群这中间就属于内部的通讯了，我们可以使用对内部友好的通讯协议比如 gRPC 或者 AMQP 等，然后进行 RPC调用提高通讯性能。

注意：Aggr Api Gateway 这个网关对于一些接口来说的话并不是必须的，也可以由后端微服务直接提供REST API给第一层网关使用。

以上，就是我理解的 API 网关在整个微服务架构中的一个地位，承上启下，还是非常的重要。

广告
我们知道，在 API 网关的后端是微服务的集群，那么除了聚合查询之外有时候我们有时候需要做一些跨不同服务的操作，比如一次电商系统的下单操作，可以会设计到产品、价格、库存等一系列跨微服务操作，在中间我们一般会采用集成事件(EventBus)来进行通讯这种解决方案，在这个过程中我们不仅仅的是需要通讯，那么这些操作还需要保证事务一致性，而一般分布式系统中的事务我们追求的是最终一致性。

如果是在 .NET Core 中，我们可以使用博主开源的 EventBus + 分布式事务 解决方案 CAP。

GitHub：https://github.com/dotnetcore/CAP

CAP 介绍：
http://www.cnblogs.com/savorboard/p/cap.html