这篇文章主要是讲如何基于 golang 实现一个简单的网关。
转自： troy.wang/docs/golang/posts/golang-gateway/
整理：go语言钟文文档:www.topgoer.cn
启动两个后端 web 服务（代码）
这里使用命令行工具进行测试
具体代码
直接使用基础库 httputil 提供的NewSingleHostReverseProxy即可，返回的reverseProxy对象实现了serveHttp方法，因此可以直接作为 handler。
具体代码
director中定义回调函数，入参为*http.Request，决定如何构造向后端的请求，比如 host 是否向后传递，是否进行 url 重写，对于 header 的处理，后端 target 的选择等，都可以在这里完成。
director在这里具体做了：
modifyResponse中定义回调函数，入参为*http.Response，用于修改响应的信息，比如响应的 Body，响应的 Header 等信息。
最终依旧是返回一个ReverseProxy，然后将这个对象作为 handler 传入即可。
参考 2.2 中的NewSingleHostReverseProxy，只需要实现一个类似的、支持多 targets 的方法即可，具体实现见后面。
作为一个网关服务，在上面 2.3 的基础上，需要支持必要的负载均衡策略，比如：
随便 random 一个整数作为索引，然后取对应的地址即可，实现比较简单。
具体代码
使用curIndex进行累加计数，一旦超过 rss 数组的长度，则重置。
具体代码
轮询带权重，如果使用计数递减的方式，如果权重是5,1,1那么后端 rs 依次为a,a,a,a,a,b,c,a,a,a,a…，其中 a 后端会瞬间压力过大；参考 nginx 内部的加权轮询，或者应该称之为平滑加权轮询，思路是：
后端真实节点包含三个权重：
操作步骤：
具体代码
一致性 hash 算法，主要是用于分布式 cache 热点/命中问题；这里用于基于某 key 的 hash 值，路由到固定后端，但是只能是基本满足流量绑定，一旦后端目标节点故障，会自动平移到环上最近的那么个节点。
实现：
具体代码
每一种不同的负载均衡算法，只需要实现添加以及获取的接口即可。
然后使用工厂方法，根据传入的参数，决定使用哪种负载均衡策略。
具体代码
作为网关，中间件必不可少，这类包括请求响应的模式，一般称作洋葱模式，每一层都是中间件，一层层进去，然后一层层出来。
中间件的实现一般有两种，一种是使用数组，然后配合 index 计数；一种是链式调用。
具体代码
在前面的学习中，我们使用Spring Cloud实现微服务的架构基本成型，大致是这样的：
我们使用Spring Cloud Netflix中的Eureka实现了服务注册中心以及服务注册与发现；而服务间通过Ribbon或Feign实现服务的消费以及负载均衡；为了使得服务集群更为健壮，使用Hystrix的熔断机制 来避免在微服务架构中个别服务出现异常时引起的故障蔓延。
在该架构中，我们的服务集群包括：内部服务Service A和Service B，他们都会注册与订阅服务至Eureka Server，而Open Servc时一个对外的服务，通过负载均衡公开至服务调用方。我们把焦点聚集在对外服务这块，这种实现方式是否合理，有没有更好的实现方式呢？
这种架构不足之处：
对于上面的问题，最好的解决方法是——服务网关。
为了解决上面的问题，我们需要将权限控制这样的东西从我们的服务单元中抽离出去，而最适合这些逻辑的地方就是处于对外访问最前端的地方，我们需要一个更加强大的负载均衡器——服务网关。
服务网关是微服务架构中不可或缺的的部分。通过服务网关统一向外系统提供REST API的过程中，除了具备服务路由、负载均衡之外，它还具备了权限控制等功能。Spring Cloud NetFlix中的Zuul就具备这样的功能。
Zuul是NetFlix开源的微服务网关，它可以和Eureka、Ribbon、Hystrix等组件配合使用。Zuul的核心是一些列的过滤器，这些过滤器可以完成以下功能。
Spring Cloud对Zuul进行了整合与增强。目前，Zuul使用的默认HTTP客户端是Apache HTTP Client，也可以使用使用其他的。
使用Zuul之后的架构如图所示：
从图中可以看出，客户端请求微服务时，先经过Zuul之后再请求，这样就可以将一些类似于校验的业务逻辑放到zuul中去完成，而微服务本身只需要关注自己的业务逻辑即可。
首先新建一个gateway模块，并且导入相关的依赖
然后再编写启动类增加@EnableZuulProxy注解。
接着编写application.yml文件，并添加路由规则
然后启动测试，发现可以通过zuul访问到商品微服务地址
在上面的配置中，我们通过路由规则的配置，访问到了商品微服务。但是如果商品微服务的地址发生变化，我们要修改配置问题。所以，我们应该通过走Eureka注册中心来获取地址。首先，我们需要添加Eureka依赖。
然后修改application.yml配置文件，将自己注册到注册中心。
随后，通过测试发现可以通过zuul访问商品微服务，一切正常。
过滤器是Zuul的重要组件。在我们的一般的单体应用中，也会使用过滤器过滤请求，或者完成相关的权限配置等，例如shiro框架就是用过滤器管理权限的。Zuul中的过滤器名为ZuulFilter：
ZuulFilter是一个抽象类，其实现类需要实现4个方法：
过滤器的执行流程如图所示：
需求：通过编写过滤器实现用户是否登录的检查
实现：通过判断请求中是否有token，如果有认为就是已经登录的，如果没有就认为时非法请求，响应401.
接下来，我们需要编写一个UserLoginZuulFilter，逻辑如下：
随后，我们打开浏览器进行测试，可以看到过滤器已经生效：
