通常情况下， API 网关要做很多工作，它作为一个系统的后端总入口，承载着所有服务的组合路由转换等工作，除此之外，我们一般也会把安全，限流，缓存，日志，监控，重试，熔断等放到 API 网关来做，那么可以试想在高并发的情况下，这里可能会出现一个性能瓶颈。
另外，如果没有开源项目的支撑前提下，自己来做这样一套东西，是非常大的一个工作量，而且还要做 API 网关本身的高可用等，如果一旦做不好，有可能最先挂掉的不是你的其他服务，而就是这个API网关。
这个时候，通常我们会去找一些开源的 API 网关项目，博主已经给你找好了，目前社区的关于 API Gataway 的项目有以下这些：
Tyk：Tyk是一个开放源码的API网关，它是快速、可扩展和现代的。Tyk提供了一个API管理平台，其中包括API网关、API分析、开发人员门户和API管理面板。Try 是一个基于Go实现的网关服务。
Kong：Kong是一个可扩展的开放源码API Layer(也称为API网关或API中间件)。Kong 在任何RESTful API的前面运行，通过插件扩展，它提供了超越核心平台的额外功能和服务。
Orange：和Kong类似也是基于OpenResty的一个API网关程序，是由国人开发的，学姐也是贡献者之一。
Netflix zuul：Zuul是一种提供动态路由、监视、弹性、安全性等功能的边缘服务。Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。
apiaxle: Nodejs 实现的一个 API 网关。
api-umbrella: Ruby 实现的一个 API 网关。
我们来说说上面的这些开源项目适不适合作为 API 网关来供我们使用。
拿单节点网关来说，这种网关相当于是处于 Web 层和 Service 之间，用来聚合服务的?注意，我们需要的是聚合服务，而以上这些开源项目都不具备这个功能，我说的聚合具体指的是开箱即用。我们要想使用这些服务需要来自己对API网关过一些扩展或者是开发一些插件，这个时候问题就来了。扩展Tyk我需要会Go语言，扩展Kong我需要会写lua脚本，使用 zuul 还得会Java，这对于开发人员来说是不太现实的，那么这个时候怎么办?
有些同学可能会说 ASP.NET Core 可以使用 Ocelot，说得没错，我们可以通过引入Ocelot来处理API聚合服务这一块的业务，但是，这中间有一个问题，就像我在上面说的一样，这很容易造成性能问题，另外一方面，Ocelot的功能相比上面的那些开源项目来说功能要弱很多，具体体现在哪些方面呢?
除了最重要的高性能的IO模型和集群方案外， 比如会经常使用的 Dashboard 功能，这个对于运维来说是非常重要的，另外还有日志，监控，安全，服务发现，版本控制等。
但是上面的这些 API 网关缺少什么功能呢? 比如超时，熔断，重试，聚合查询等。
