API Gateway简介

API Gateway,服务网关

Chris Richardson 微服务系列 使用API网关构建微服务

http://blog.daocloud.io/microservices-2/

「Chris Richardson 微服务系列」使用 API 网关构建微服务

它是POJO IN ACTION的作者,世界十大架构师之一,这是中文译文,原文在这里

https://www.nginx.com/blog/building-microservices-using-an-api-gateway/#rd?
sukey=fa67fe3435f5c4be6421e18baad6a2d40a99d952ea34ddbdbd8de1d300544a8e37b45ad97ffee186e8d6fdbc549

我们现在要做一个安卓的客户端,然后这是亚马逊的商品详情和购物车页面,三个页面大概包括了这些功能,

订单历史,评论,推荐信息,还有物流信息

在微服务里面,我们对微服务的划分是非常细粒度的,那这些功能点是不是会分不到不同的微服务里面去,

比如说订单历史,他用的是订单服务去查的,订单历史,商品的基本信息呢,他用的是目录服务,我会分布到

这么多的服务里面去,假设我是直接通信的话,是不是很无语,购物车的服务IP和端口,物流的IP和端口,

我们每个IP和端口都得知道,这是其中的几个页面,得知道这么多的服务和端口,整个应用可能涉及到上百个微服务,

这边都得硬编码,客户端是不是会很累,这是第一个问题,第二个问题是,举个例子,这个微服务我可能用的不是HTTP

REST API,就是画的API,假设我用的不是REST,我用的是其他的协议,就是WEB不友好,还有一格问题是,微服务难以

重构,我们知道微服务的划分往往是动态的,两个合起来更加的合理,就是需求在不断地变换的,我们一直在解决

软件危机,一直都会出现,一直都存在,那这个时候我们又得改

在这边加一个这个东西,这个叫API GateWay,就是服务网关,就是用户请求的时候呢,

就不用这样搞了,都经过我吧,我可以知道,每个微服务是在哪里,你只要知道我的API GateWay的

端口就OK了,至于你这里用的不是HTTP协议,用的是swift,那没有关系,我这边也会做一些办法,

我这边继承一个swift客户端,我跟他通信,对于暴露在外面的,他就是做一个请求的聚合,这边就分析了

API GateWay的优点和缺点,优点就很多了,就是客户端解放了客户端的编码,假设重构调整也是很方便的,

第二个是API GateWay的缺点,缺点是既然增加了一个组件,我们就要额外的开发和维护,增加了组件是不是要

考虑他的高可用

Router and Filter: Zuul

https://cloud.spring.io/spring-cloud-netflix/reference/html/#_router_and_filter_zuul

实现了比较好的API Gateway,Netflix API网关,网关就是Gateway,但是他没有提到Zuul,其实Netflix网关

就是指的Zuul,我们简单的提了一些API Gateway