网关使用场景
Open API
企业需要将自身数据、能力作为开发平台开放，向外提供；比如微博、阿里、微博的开发平台、微信开放平台；
微服务网关
企业内部公网API网关
上述的微服务架构对企业来说有可能实施上是困难的，企业有很多遗留系统，要全部抽取为微服务改动太大，对企业来说成本太高。但是由于不同系统间存在大量的API服务互相调用，因此需要对系统间服务调用进行管理，清晰地看到各系统调用关系，对系统间调用进行监控等。
企业内部API网关可以解决这些问题，我们可以认为如果没有大规模的实施微服务架构，那么对企业来说微服务网关就是企业的API服务管理平台。
本质上也属于Open API，但是单独剥离出来是因为其业务优先级和面向客户都不一样，还是建议隔离出来；
什么是服务网关
服务网关＝路由转发＋过滤器
路由转发：接收外界一切请求，转发到后端微服务上
过滤器：在服务网关可以做一系列横切功能，例如权限校验、限流以及监控；
为什么需要服务网关
以权限校验为例，横切位置可以写在3个位置
- 每个服务自己实现一遍
- 每个服务引用公共的写好的权限校验jar包
- 在网关处进行权限校验
第一种方式缺点明显，相对来说第二种方式会好一点，但存在2点问题，打包部署的jar变大了，尤其是使用docker景象部署的，jar越小越好，另个问题是由于引入的权限校验是一个公共服务，后续升级维护难度较大，牵扯较广，公共服务越多升级难度越大；
所以需要网关服务。
整体流程
用户请求直接到服务网关，网关做智能路由转发（包括服务发现和负载均衡）到service，service响应返回给网关，网关再返回给用户
引入网关注意点
增加了网关，多了一层路由转发，性能会下降一点，但下降的不多，通常服务网关的宿主机器性能很好，而且网关转发service都是走内网，速度很快；
网关单点问题，在网络调用过程中一定会存在一个单点，网关、nginx、dns服务器等，为了防止网关单点，在网关前面加一台nginx。但是这样的部署会导致一次请求转发两次，更推荐的方式是网关服务单点部署在一台机器性能极好的服务器上，zuul和nginx性能比较，实质上差不太多；
问题
服务间调用走网关吗？
不走，直接从注册中心获取ip+端口直接调用
若有收获，就点个赞吧
0 人点赞
