【Spring Cloud总结】24.API Gateway简介

最近比较忙，新项目上线，好久没更了/(/ /●/ω/●/ /)/

接上篇《23.Hystrix Dashboard的使用（下）》  Spring Cloud版本为Finchley.SR2版

上面几篇我们介绍了Hystrix Dashboard以JSON、图形化界面的方式来显示单体应用或集群的API监控。
下面我们正式进入API Gateway即“API服务网关”，以及Spring Cloud的路由的处理控制组件“Zuul”的学习。

API Gateway翻译为中文的实际意思就是“API 网关”，那么什么是“API 网关”，它的存在又有什么意义呢？下面我们逐步为大家介绍。

注：下面的介绍中引用了软件大师Chris Richardsonde的《使用 API 网关构建微服务》文章中的部分内容，以便向大家解释什么是API Gateway。
http://blog.daocloud.io/microservices-2/ （译文）

一、为什么需要API Gateway？

例如下面是亚马逊的安卓应用的商品详情页面：

该页面处理基本的商品信息，还显示一下内容：

●购物车中的商品数量
●历史订单
●客户评论
●低库存预警
●送货选项
●各种推荐，包括经常与该商品一起购买的其它商品、购买该商品的客户购买的其它商品、购买该商品的客户看过的其它商品
●其它的购物选择

单体应用的情况下，很简单，客户端只需要发起一次服务请求，就可以获取多个需要的服务结果。
而在微服务的情况下，显示在产品页面的数据可能分布在不同的为微服务上，例如：

●购物车服务——购物车中的件数
●订单服务——历史订单
●目录服务——商品基本信息，如名称、图片和价格
●评论服务——客户的评论
●库存服务——低库存预警
●送货服务——送货选项、期限和费用，这些信息单独从送货方 API 获取
●推荐服务——推荐商品

这就意味着我们加载一个商品页面时，客户端要向至少7个微服务发送请求，并接收返回结果：

这种情况下，有以下三个问题：
1、对于客户端，它需要记录所有公开的服务URL地址，然后向这N个服务分别发送请求。
2、对于客户端，一些服务的协议对Web不一定是友好的，例如二进制RPC或AMQP 消息传递协议
3、它会使得微服务难以重构，想要更改系统拆分成服务的方式，例如合并两个服务，或者将一个服务拆分成两个或更多服务，这对于直接调用服务的客户端来说，无疑是困难的。

所以综合以上情况，在微服务架构下，客户端直接与服务器进行的方式很少在实际中使用。

所以，我们就需要一个前置服务，即网关，来解决上面的问题。

二、使用API Gateway构建微服务

怎么理解API Gateway？如果我们在N个微服务前，加一个前置服务，利用这个前置服务，来接收所有客户端的请求，然后将这些请求进行分发，然后将分发后的结果整合起来，以客户端匹配的服务协议，反馈给客户端，而客户端仅需要记住网关的服务URL地址即可，后面的服务整合或拆分，都有网关来处理，对于客户端来说，都是无感的。下面的图片就是在刚刚的架构前，加了一个API网关：

这里的API 网关就是一个服务器，也是进入系统的唯一节点。它将系统的内部架构给整合起来，然后暴露API给客户端，然后它可能还具备授权、监控、负载均衡、缓存、请求分片和管理、静态响应处理等功能。

API 网关有三大功能：
1、服务请求路由
2、服务请求组合
3、协议转换
客户端发起一个请求，在API网关会被路由到相关的微服务，然后大部分API都会将多个微服务合并成一个结果来处理一个请求，然后如果微服务内部使用的是非Web协议，API网关还可以进行一个协议转换。

当然，API网关也有它的优点和缺点，它的优点就是封装了应用程序的内部结构，客户端只需关心与网关交互。缺点也很明显，就是增加了一个必须开发、部署和维护的高可用组件，然后每次开发微服务新模块或更新端点，都需要更新API网关。

Spring Cloud全家桶中自然也为我们提供了微服务API网关组件，它就是Zuul，一个提供了动态路由、监控、弹性负载和安全功能的网关组件，下一篇我们来正式介绍Zuul。

参考：《51CTO学院Spring Cloud高级视频》
http://blog.daocloud.io/microservices-2/ 

转载请注明出处：https://blog.csdn.net/acmman/article/details/103226170