微服务架构网关接口设计

近年来微服务架构盛行，我司也利用spring cloud实践微服务。使用的也是spring cloud很经典的架构，zuul充当网关路由，configserver作为静态配置中心，feign作为远程调用http client 等，反正都是官网文档能找到的组件，我们都在用。使用基础的功能自然是没有问题，但是我们也会针对进行深度定制，完成我们特有的功能，例如我们定制zuul网关，路由时针对部分request中的数据，这个在通用模式下是做不到，因为zuul基础的功能是路由,通过链接将请求分发给哪个微服务的哪个方法进行处理，下面我们就以一个接口限流的案例，来一步步的教大家网关接口的设计方案与深度定制zuul网关的过程。

背景

1. 微服务需要暴露接口给第三方使用，但是此接口是二次封装的产物，封装了一个按次付费的接口，所有不能随便调用，需要限制调用方调用的次数。
2. 基础的应用框架正如前言所说使用spring cloud 全家桶。

基础设计

1. 为了更好的兼容性和扩展性，我们决定在后台配置需要被网关特殊处理的接口。例如此接口名称叫做接口A,他的访问链接是什么。都需要被记录。
2. 网关接口需要被怎样的处理？验签（1）？解密（2）？限流（3）？都可以。我们将这些被网关允许的特殊操作，做成一个个原子，然后随意组合成某一类接口的具体的功能。比如说我们的某一类的接口的功能是限流+验签，那么我们原子组合就是（1，3），我们称这种方案为方案A，具体要怎么处理这个组合可以根据大家自己的设计，我这边建议是与或操作，利用计算机擅长的二进制来处理。
3. 我们通过第一步有了接口A,我们通过第二部有了方案A,然后将他们融合在一起，拼成的语义就是：当网关发现了被访问的链接是特殊接口A所描述的，那么就要找到这个接口的特殊配置，也就是方案A,在网关进行特殊处理就行了。
4. 网关改怎么进行特殊处理呢？属性zuul的朋友应该都知道他是怎么运行的,不熟悉的同学可以看一下我的另外一篇文章Zuul 源码分析,zuul分为诸多类型的filter,他们都是ZuulFilter的实例，所以你只要写一个ZuulFilter的,并且把它做成Bean(@Component注解注释或者通过配置文件配置等)，就能被Zuul察觉到，但是能不能执行，还得看ZuulFilter中的shouldFilter方法结果是否返回true,这种设计也给我们很大的灵活性和扩展性，也给我们通过代码操作我们写的这个filter是否执行成为可能，并且这种设计和我之前提到的与或操作是天然的结合在一起，无缝衔接，特别好用！我们可以通过自定义pre类型的filter，将一些前置的逻辑，比如方案A是验签和限流的功能做掉。
5. 功能验证完了，我们就剩下路由了。也就是我们的route类型的过滤器。因为我们要实现验签和接口限流等功能，所有避免不了就是多一些非业务的参数，但是业务系统不需要这些，所以我们就要通过网关层面就要过滤掉。Zuul网关有两个主要的route类型的过滤器，如果通过服务名称路由，会从consul或者eureka中获取到这个服务名称对应的服务的信息，然后通过软负载均衡robbin，路由到具体的服务发起请求，这个filter叫做RibbonRoutingFilter,如果你指定了访问服务的URL，那么久不会走到这个RibbonRoutingFilter,你走的就是SimpleHostRoutingFilter,它里面就是直接通过apache http client 发起来请求。这两个默认的route类型的过滤器都不能满足我们传递部分数据到后端微服务的场景，所以我们就得自定义一个route类型的过滤器，我们要做的就是两点，第一点，将后端微服务真真需要的数据传给他们，第二点就是在运行时不要访问到其他的route类型的过滤器，防止被接口被执行两次。

结语

基本上实现跟着上面的步骤来就没啥特别大的问题了，自己写一个route类型的filter也不是特别难的事情，基本上把SimpleHostRoutingFilter重写一些就行，大部分代码不需要改动，只要在传递request时，消息体换成服务端真正需要的数据，并且注意content-length的设定就可以。另外怎么防止不会有其他的route类型的filter访问到，这就得看其他的route类型的filter的shouldFilter方法是怎么样的，想方设法把他们变成false就行了。我们再解决问题的同时也要思考框架级代码的设计，扩展性如此只好，即使没有现成的解决方案，但是我们自己稍作改动就会支持。不得不说，这些大神们写的代码，真的值得我们好好学习啊。