本文源码:GitHub·点这里 || GitEE·点这里git
客户端与各个业务子系统的通讯必须经过一个统一的外观对象进行,外观模式提供一个高层次的接口,使得子系统更易于使用:github
简单说一下外观模式,网关和这个模式很像,可是比外观模式复杂,模式,结构,原则这些都是通用的,在各类架构或组件中使用。算法
微服务网关从感受上,很像是:拦截器+路由+过滤器,拦截请求,系列基础处理,路由转发到指定服务。spring
服务网关在整个架构体系上也是一个服务器,做为请求的惟一入口,与外观模式十分相似,在网关层处理全部的非业务功能,为客户端提供定制的API,在网关层一般会执行以下操做:如权限校验、监控、负载均衡、缓存、日志、限流、等等。数据库
这里对比经常使用的请求服务管理模式,和网关模式,如图:segmentfault
常规模式缓存
在没有网关的状况下,微服务架构会在业务层服务上提供一个API服务,用来接收参数,例如Client-API,一般会根据系统模块划分多个API,例如,运营系统,用户系统等。安全
该模式下的缺点很是明显,每一个Client-API都须要实现一套非业务服务,代码冗余,当系统膨胀以后,维护成本极高,适用于轻量级系统架构。服务器
网关模式网络
在业务服务层上,添加一层网关控制,在服务网关中能够完成一系列的横切非业务功能:
网关服务层要执行不少非业务流程,做为系统的服务端惟一入口,承受全部服务的路由转发,安全,限流,缓存,日志,监控,熔断降级等功能,网关服务不只要作到高可用,还要避免出现性能瓶颈。
在大型复杂的系统中,一般会对网关作分层管理,把一类业务规划到一个网关下,避免网关过于臃肿,方便维护和管理:
总网关:通用经常使用来作路由转发功能;
模块网关:分类的业务服务聚合网关,对这类服务的作非业务性操做,最后请求转发到具体服务上,在数据类平台上,一般对数据通道(流入流出)作一层独立的服务网关;对数据分析类服务作一层独立网关;基本是根据服务的使用状况来划分,这样避免单层服务网关过于复杂的状况。
服务发现
网关应该有服务发现功能,经过统一注册中心,获取服务列表,这样才能执行统一代理服务和路由转发功能。
路由请求
植入网关层服务以后,客户端不知道本身请求的是哪一个具体的服务,只须要把请求转发给网关,网关放行以后会把请求路由到指定业务服务上。
负载均衡
网关链接的服务实例多是集群模式存在,因此网关还能够对各个服务实例上执行负载均衡策略,常见的策略就是服务轮询或者按权重路由。
定制开发例如:权限校验,日志集成,接口限流,等相关功能,须要和数据库交互,能够作成独立服务,在服务中实现具体的处理逻辑,网关层直接调用便可。
Zuul网关主要提供动态路由,监控,弹性,安全管控等功能。在分布式的微服务系统中,系统被拆为了多个微服务模块,经过zuul网关对用户的请求进行路由,转发到具体的后微服务模块中,Netflix开源的一个基于JVM路由和服务端的负载均衡器。
Tyk是一个开源的、轻量级的、快速可伸缩的API网关,支持配额和速度限制,支持认证和数据分析,支持多用户多组织。基于go语言编写,在Java架构系统中使用不多。
Kong是一款基于Nginx+Lua编写的高可用,可扩展的开源网关项目,由Mashape公司开放。核心是实现数据库抽象,路由和插件管理,插件能够存在于单独的代码库中,而且能够在几行代码中注入到请求生命周期的任何位置。提供易于使用的RESTfulAPI来操做和配置API管理,而且能够水平扩展多个Kong服务器,经过前置的负载均衡配置把请求均匀地分发到各个Server,来应对高并发的网络请求。
GitHub·地址 https://github.com/cicadasmile/husky-spring-cloud GitEE·地址 https://gitee.com/cicadasmile/husky-spring-cloud
推荐阅读:微服务架构