网关系统主要有两种：

第一种叫客户端网关主要用来接收一些客户端的请求，也就是APP的服务端。

第二种叫开放网关，主要是公司（比如京东）对于第三方合作伙伴提供接口。

这两种不同网关所使用的技术非常类似。

流量比较大的网关面临的难点包括：

第一，网关系统需要扛几十亿的流量调用，接口的平稳运行、每一个接口在后端服务之后的性能耗损都非常重要。比如我们使用了一个Redis集群，然后构建了两个机房，每一个机房都搭建了一个Redis集群，这样的话就能够很好地保证高可用。在面对一个瞬间流量的时候，我们采用了一些缓存技术，或者更前置的Nginx+lua+Redis技术，让这种大流量应用能够脱离开JVM的依赖。还有我们需要梳理各个接口，通过降级的策略把一些弱依赖的接口进行降级，从而保证核心应用的可用。

第二，网关系统其实就是一个把Http请求拓展到后端服务的过程。我们的网关承接了一千以上的后端服务接口，面对这种情况，怎样做到服务与服务之间相互不影响？架构层面怎样能够杜绝蝴蝶效应、防止雪崩？就是说当一个接口出现问题的时候，不至于影响到其他接口的健康运行。这个说起来简单，但实际却不然。
一千个以上的接口，每个接口性能都不一致，而且每个接口所依赖的外部资源、数据库缓存等都不一样，几乎每天都会出现各种各样的问题，我们怎样通过一些隔离技术、治理技术等，保证当这些接口出现问题的时候，不会影响到全局？

第三，我们对外暴露了一千个服务接口，所有接口的后面意味着几十个甚至上百个团队每天在不停地开发，每天都可能上线新的需求。面对这么复杂的情况，我们不可能每次后端服务器有任何修改，都需要有网关的修改或上线，这样网关会变得非常脆弱，稳定性极低。

我们采用了一个动态接入的技术，让后端的网关能够通过一种接入的协议进行无缝接入，之后通过一些动态代理的方式，直接让后端的接口，不管做任何修改或上线，都可以通过后端管理平台从网关上对外进行透传发布，很好地解决了我们网关所面临的依赖于后端接口服务的上线问题。

网关的四个技术方向：

第一，统一接入。就是前端（包括APP或其他来源）的流量，能够都在统一网络层进行接入。这一层所面临的问题是：高性能透传、高并发接入、高可效性，以及当前端流量来了之后，怎样能够进行一个负载的往后端的转发。

第二，流量管控，主要指流量治理部分。面对海量流量，我们怎样通过一些防刷技术，保障网关不被大流量冲垮；以及怎样通过一些像限流、降级、熔断等技术，对网关进行全方位保护。

第三，协议适配。就是前文提到的，网关会透传后端上千个服务，而这些服务一定不是每一个都需要网关去开发配置的。我们通过一个协议适配的转换，让后端的各种服务通过我们指定的协议、通过http的方式从网关开放出去，当然网关不单单是http协议，还有一些TCP的。京东内部的协议相对比较统一，有Http的restful的协议，也有JSF的接口，JSF是京东内部自研的一个框架，一个RPC调用框架，和double是类似的，然后基于注册发现的一个rpc框架。

第四，安全防护。这一部分对于网络来说非常重要，因为网关是整个公司对外的一个出口，在这一层我们要做一些防刷，比如防清洗一些恶意流量、做一些黑名单，当有一些恶意流量的话，通过限制IP等限制手段把它拒绝在整个网关之外，防止这些恶意流量把网关冲垮。

以上只是应对高并发量的一个方面。要做到更好的应对高并发，还有很多方面的工作需要做。我们下次再接着聊这个话题。