共计 1818 个字符，预计需要花费 5 分钟才能阅读完成。
背景
咱们都晓得，在微服务架构格调里，一个利用会被拆分成多个小的服务零碎，并且这些小零碎都能够自成体系，能够领有本人的数据库、框架语言等。它们通常都能够提供接口来被各种应用程序调用。
然而在 UI 上进行展现的时候，咱们通常须要在一个界面上展现很多数据，这些数据可能来自于不同的微服务中。
打个比方：要查看一个电商平台的商品详情页，这个商品详情页包含题目、价格、库存、评估等等，这些数据可能在不同的微服务零碎之中，如下所示：
• 产品 – 负责提供商品的题目，形容，规格等。
• 价格 – 负责对产品进行定价，价格策略计算，促销价等。
• 库存 – 负责产品库存。
• 评估 – 负责用户对商品的评论，回复等。
当初，商品详情页须要从这些微服务中拉取相应的信息，问题来了？
因为用的是多个服务零碎的架构，所以依附单个数据库的 join 查问后果不可行，那么该怎么拜访各个服务呢？
依照微服务设计的领导准则，咱们的微服务可能存在上面的问题：
• 服务应用了多种协定，因为不同的协定有不同的应场景用，比方可能同时应用 HTTP, AMQP, gRPC 等。
• 服务的划分可能随着工夫而变动。
• 服务的实例或者 Host+ 端口可能会动静的变动。
那么，对于前端的 UI 需要也可能会有以下几种：
• 粗粒度的 API，而微服务通常提供的细粒度的 API，对于 UI 来说如果要调用细粒度的 api 可能须要调用很屡次，这是个不小的问题。
• 不同的客户端设施可能须要不同的数据。Web,H5,APP
• 不同设施的网络性能，对于多个 api 来说，这个拜访须要转移的服务端会快得多
那么如何解决呢？
这种状况下，咱们就须要一个明天要讲的这个货色，API 网关（API Gataway）。
API 网关
上面是百度上针对于 API 网关的介绍：
API 网关是一个服务器，是零碎的惟一入口。从面向对象设计的角度看，它与外观模式相似。API 网关封装了零碎外部架构，为每个客户端提供一个定制的 API。它可能还具备其它职责，如身份验证、监控、负载平衡、缓存、申请分片与治理、动态响应解决。
API 网关形式的外围要点是，所有的客户端和生产端都通过对立的网关接入微服务，在网关层解决所有的非业务性能。通常，网关也是提供 REST/HTTP 的拜访 API。服务端通过 API-GW 注册和治理服务。
Chris Richardson 在他的博客中把 API 网关划分为以下两种：
• 单节点 API 网关
• Backends for frontends 网关
单节点网关
单节点的 API 网关为每个客户端提供不同的 API，而不是提供一种万能格调的 API。
这个网关和微软在 eShop 我的项目中举荐的网关是统一的。
Backends for frontends 网关
这种模式是针对不同的客户端来实现一个不同的 API 网关。
落地计划
以上两种 API 网关有什么问题呢？
通常状况下，API 网关要做很多工作，它作为一个零碎的后端总入口，承载着所有服务的组合路由转换等工作，除此之外，咱们个别也会把平安，限流，缓存，日志，监控，重试，熔断等放到 API 网关来做，那么能够试想在高并发的状况下，这里可能会呈现一个性能瓶颈。
另外，如果没有开源我的项目的撑持前提下，本人来做这样一套货色，是十分大的一个工作量，而且还要做 API 网关自身的高可用等，如果一旦做不好，有可能最先挂掉的不是你的其余服务，而就是这个 API 网关。
这个时候，通常咱们会去找一些开源的 API 网关我的项目，博主曾经给你找好了，目前社区的对于 API Gataway 的我的项目有以下这些：
Goku：Goku 是一个可扩大的开放源码 API Layer(也称为 API 网关或 API 中间件)。开箱即用，全界面配置，操作简略，通过插件扩大，它提供了超过外围平台的额定性能和服务。
Orange：基于 OpenResty 的一个 API 网关程序，同样是由国人开发的。
Netflix zuul：Zuul 是一种提供动静路由、监督、弹性、安全性等性能的边缘服务。Zuul 是 Netflix 出品的一个基于 JVM 路由和服务端的负载均衡器。
apiaxle: Nodejs 实现的一个 API 网关。
api-umbrella: Ruby 实现的一个 API 网关。
总结
通过本文咱们理解到了什么是 API 网关以及 API 网关的作用和其在微服务架构中所处的位置。而后咱们理解到了 API 网关的一些开源我的项目以及博主介绍的落地计划，在理论的实际中还是多心愿大家可能多多思考总结，这样咱们才可能变得更加弱小。
翻译：Eolinker
起源：www.eolinker.com
