探索原味 API Gateway 模式
探索原味 API Gateway 模式
当前技术背景下，大多数应用程序的能力都建立在 APIs（Application Programing Interface）之上。而 API Gateway 组件则是应用程序与API 间流量的单一出入口。而 API Gateway 背后的服务的架构对于API 使用者来说是毫无感知的。同时，API Gateway 为 API 的流量提高了安全保障、减少服务下线时间、通过类似 LoadBalancer 的工具来提高流量的稳定性，也增加了对下层服务的保护。
和《探索 BFF 模式》文章的逻辑类似。还是从寻找 API Gateway 模式出现的源头开始，渐进式的去了解这个模式解决问题的方式和逻辑。不过，API Gateway 模式与 BFF 模式相比，出现的年代更加久远，是否能找到源头我自己也拿不准。不过，不管是最终是否能找到，我也需要尝试一下。
寻找 API Gateway 模式的起源
一开始，和分析 BFF 模式一样，先设法找到 API Gateway 的起源时间的方式来缩小范围。以之前的成功经验为参考，我还是先从技术雷达(www.thoughtworks.com/search?q=&c… API Gateway 组成的新的词组。它们分别是：（以出现时间为倒序）
ESBs in API Gateway's clothing **[Techniques] Oct 28, 2020
Kong API Gateway**[Techniques] Nov 30, 2017
Amazon API Gateway****[Platform]**** Apr 05, 2016**
Overambitious API gateways **[Platform] Nov 10, 2015
我不但没找到 API Gateways 的源头，反而增加了很多新的技术词汇，我们还是把视野重新聚焦到 API Gateway 模式上。接着换了另外几个方法和维度的尝试。比如：通过Google 趋势搜索 API Gateway 关键字热度趋势；通过其他比较出名的大型技术博客网站等等。最终得到的消息里面都没有真正需要的API Gateway 模式源头的头绪。不过别放弃，既然没办法从源头去了解这个模式，我换种思路。找到被大多数人认可的定义也能帮助我们很好的去理解这个模式。
模式的标准化定义
直接在 Google 搜索 API Gateway Pattern ，映入眼帘的第一条就是 100%匹配关键字的条目（_microservices.io/patterns/ap… API Gateway Pattern 都指向了我们刚刚看到的第一条结果。比如：
Microsoft（docs.microsoft.com/en-us/dotne…
Manning（freecontent.manning.com/the-api-gat…
通过交叉验证的方式，我可以确这个结果就是我们想找到的大多数人认可的定义。通过模式的适用场景，我们可以比较容易的理解模式的优劣势，以及以后在什么情况下应该使用到它。
API Gateway 模式的适用场景
通过了解使用模式的场景来反推出问题，可以使我们在遇到问题后更好的使用模式。从文章介绍信息中可以得到如下使用场景：
基于微服务架构设计的系统
通过 REST API 的方式暴露业务能力给第三方使用
在上述两个场景中，可能会遇到如下的这些问题：
问题一：微服务提供的 API 的粒度通常与客户端的需求不同。微服务通常提供细粒度的 API，这意味着客户端需要与多个服务进行交互。
问题二：不同的客户端需要不同的数据。
问题三：不同类型的客户端的网络性能是不同的，所以需要的数据格式与压缩方式是不同的
问题四：当服务实例的数量及其位置（主机+端口）动态变化或者微服务其他的变化，会影响客户端的使用。
问题五：服务使用的通信协议和方式可能对客户端不友好，比如使用例如 Protobuf、thrift 等
这些问题都是如何被 API Gateway 模式解决的呢？
如上图所示，API Gateway 模式是在客户端与服务应用端之间添加了一个叫做 API Gateway 的新组件。那么，这个新组件是通过什么能力来解决问题的：
提供统一的入口对外提供服务
问题一
问题四
为不同客户端提供不同格式的REST API
问题二
问题三
问题五
在 API Gateway 将数据转换为客户端友好的格式
问题五
附加：在 API Gateway 增加对后端的保护与能力统一建设
鉴权处理
服务发现
负载均衡
熔断
限流
等等
虽然，API Gateway 组件是微服务系统对外提供服务的大门，可以帮我们解决非常多的问题。一个事物往往具有两面性，它同样也有缺点：
增加的系统复杂性：API Gateway是另一个必须开发、部署和管理的移动部分。增加了整个系统需要维护的成本和系统的故障发生可疑点。但是，往往现在的云平台都提供类似的 API Gateway 的基础组件，故障风险和维护成本已经被降低到可以忽略不记。
增加了响应时间：API Gateway 在服务与客户端之间增加了一层，所以通信时间难免会受到影响而增加延迟。不过，这个影响非常之小，在大部分场景下可以忽略不记。除非，你在 API Gateway 上做了一些自定义的高耗时操作（非常不建议）。
有的朋友可能会很好奇，API Gateway 模式的特征看起来与《探索原味 BFF 模式》中的 BFF 提到的特征看起来方向类似。只是好像 API Gateway 模式处理API 请求的方式没有那么的有针对性。
API Gateway 与 BFF 的关系
没错，从这两个模式出现的时间点上，我们就能看出其中的端倪。实际上，BFF 其实本身就是 API Gateway 模式的一种演进式的派生。API Gateway 模式出现的时间比较早，我们可以不严谨的认为，是在 12 年左右出现的。当时，我们在生活中或工作中与软件系统进行互动的终端还主要是 PC 上的浏览器。所以，原来的 API Gateway 模式只是将不同设备的 API 数据格式和简单进行了适配和区分。远远没有达到需要单独进行提供服务的必要性。
在近几年的移动设备的发展中，我们生活中PC Web 端交互所占比重逐渐下降，移动设备的交互变得越来越重要；同时，IOS 与 Android 系统在众多的移动设备操作系统中脱颖而出，已然成为移动设备的两大主要操作系统。在此大背景之下，15 年的 SoundCloud 公司便面临了当时的情况，API 提供的服务越来越需要针对性和特殊的优化。于是，API Gateway 模式得到了进一步的发展，由 BFF 模式接过大旗，继续发挥着API Gateway 模式的能力。
结论
通过本篇博客与《探索原味 BFF 模式》一起充分了解了，近十年后端服务为客户端提供服务方式的逐步演进。总结来看，后端服务通过在架构上增加分层的方式来应对客户端越来越分化的需求。如下图所示：
同时，我们可以发现，软件架构模式并不是一成不变的。随着科技的进步，需求的变化，模式也会随着时代进行演进和发展。但是，这个模式处理问题的方式和思路是不变的。借用《演进式架构》书中的一段话来描述这个情况。“和生态系统一样，软件开发体系实现了平衡，开发人员能够理解这个体系并为其添砖加瓦。然而，这种平衡是动态的，随着新事物的不断出现，平衡不断被打破和重建。想象一个脚踏独轮车，手里还拿着盒子的人。他是动态的，因为他需要不断调整来保持挺立；他又是平衡的，因为他保持着身体平衡。在软件开发体系中，每一项创新或新实践都可能打破现状，迫使系统重新建立平衡。就好比我们不断将更多盒子抛向骑独轮车的人，迫使他不断寻求新的平衡。”
作者：云逸Dean
链接：https://juejin.cn/post/7024830938634780708