最近一段时间一直在思考api网关该如何设计。前段时间也按照个人对于网关的理解写了个gateway,但是总感觉不尽如人意。周末坐高铁回家，带了一本spring cloud的微服务书（买来一直没有时间看）。重点看了zuul的章节，了解了它的设计思路，现总结如下。

网关应有的功能

• 参数校验

• 鉴权

• 限流

• 服务路由

• 负载均衡

• api服务列表的动态维护

• …

这几个功能对于api来说都很必要，不作一一解释。重点说一下下面两个：

1. 鉴权

   直观的理解是对于访问接口api的权限认证。一般的设计，将其独立出来作为一个独立的服务进行部署。那么，为什么将其放在网关中，而不是作为独立的服务被相应的api服务进行调用？我们现在业务架构中，就是将鉴权作为独立的服务，被相应的api服务调用,因为我们没有网关。鉴权一般情况下与业务相关的api服务关系不太高。将其分开，则能更好的开发业务相关的api服务，尤其是在开发调试阶段，我是身有感触。鉴权放在网关中，集中处理可以更好的限制后续的接口的请求流量等作用…

2. api服务的列表的动态维护

   api服务的列表，即api服务提供者的服务器信息，因为频繁的上下线，或者单机出现故障，都会使单个api服务中服务器列表信息发生改变，那么如何维护呢？我们在使用nginx作为网关负载均衡器的情况下，即手动是维护nginx的配置。那么当微服务多了，则这个是运维的噩梦的开始，在我之前开发的api网关gateway中，是使用数据库表来维护，但是依然半自动化或者是人工来管理。那么如何自动维护呢？或者说能否自动维护？答案是肯定的，zuul借助注册中心来帮其维护api服务的动态列表。这个设计可以说是的相当的精妙。zuul 也将其作为一个api服务注册到注册中心，然后拉取api 服务的所有api服务器信息，通过默认的路由规则即可以完成网关的一大半功能。 这一转变可以说是将网关开发的技术难度大大降低。因为与服务相关的服务trace,服务治理，限流等等功能都可以转驾到注册中心。这个设计可以说太巧妙了…

通过以上的介绍，zuul网关剩余功能开发，可谓之简单，不再一一详述了。它的这个设计思路让我想起了，大学的数学分析老师，给我们讲的一个故事：

烧开水的步骤如下：

1. 刷水壶
2. 水壶灌满水
3. 放在煤气灶上
4. 打开煤气灶
5. 水开关上煤气灶

现在你有一个灌满了水的水壶，请问如何烧开水？

老师给的答案是将水壶的水倒掉，然后调用烧开水的程序。
所以有时候换个角度思考问题，思路就开阔了…