最近一段时间一直在思考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. 水开关上煤气灶

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

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

Logo

权威|前沿|技术|干货|国内首个API全生命周期开发者社区

更多推荐