软件开发除了在功能上满足需求以外,在性能上也要能满足需求。一些用户量大,对并发量要求高的软件,在开发前就要设计好架构,在服务器硬件和系统软件上,都要能支撑高并发的需求。
以京东为例,618大促,京东的网关承载了几十亿的流量和调用,在这种情况下,网关系统必须保证整个系统的稳定性和高可用,保证高性能和可靠,以支撑业务。这是一个非常复杂的问题,基于这种复杂问题,怎样做到很好地提高它的性能和稳定性、复杂技术之间怎么整合保证整体网关的高可用?
网关系统主要有两种:
第一种叫客户端网关主要用来接收一些客户端的请求,也就是软件的服务端;
第二种叫开放网关,主要是公司(比如京东)对于第三方合作伙伴提供接口。
这两种不同网关所使用的技术非常类似。
流量比较大的网关面临的难点包括:
第一,网关系统需要扛几十亿的流量调用,接口的平稳运行、每一个接口在后端服务之后的性能耗损都非常重要。比如我们使用了一个Redis集群,然后构建了两个机房,每一个机房都搭建了一个Redis集群,这样的话就能够很好地保证高可用。在面对一个瞬间流量的时候,我们采用了一些缓存技术,或者更前置的Nginx+lua+Redis技术,让这种大流量应用能够脱离开JVM的依赖。还有我们需要梳理各个接口,通过降级的策略把一些弱依赖的接口进行降级,从而保证核心应用的可用。
第二,网关系统其实就是一个把Http请求拓展到后端服务的过程。我们的网关承接了一千以上的后端服务接口,面对这种情况,怎样做到服务与服务之间相互不影响?架构层面怎样能够杜绝蝴蝶效应、防止雪崩?就是说当一个接口出现问题的时候,不至于影响到其他接口的健康运行。这个说起来简单,但实际却不然。
一千个以上的接口,每个接口性能都不一致,而且每个接口所依赖的外部资源、数据库缓存等都不一样,几乎每天都会出现各种各样的问题,我们怎样通过一些隔离技术、治理技术等,保证当这些接口出现问题的时候,不会影响到全局?
第三,我们对外暴露了一千个服务接口,所有接口的后面意味着几十个甚至上百个团队每天在不停地开发,每天都可能上线新的需求。面对这么复杂的情况,我们不可能每次后端服务器有任何修改,都需要有网关的修改或上线,这样网关会变得非常脆弱,稳定性极低。
我们采用了一个动态接入的技术,让后端的网关能够通过一种接入的协议进行无缝接入,之后通过一些动态代理的方式,直接让后端的接口,不管做任何修改或上线,都可以通过后端管理平台从网关上对外进行透传发布,很好地解决了我们网关所面临的依赖于后端接口服务的上线问题。
我们的微信
我们的微博