部署微服务于容器云平台，API网关应如何选择？

微服务越来越火，越来越多的公司开始采用微服务架构。今天还有人让我帮推荐好的微服务实施厂商。但采用微服务并不容易，实施微服务可能不可或缺的一个很重要的组件就是API 网关。微服务若要部署于容器云平台，API网关的实现能力、部署方式、产品选择等就显得至关重要。

网关，顾名思义，网络关口，担负着安全检查、认证授权、路由分发、流量控制、熔断保护等重要的职责。API网关，那就是API的网络关口、通道，是整个微服务平台的咽喉，API请求应答必经之路。为了利用容器云弹性伸缩等特性，结合微服务的优点，部署微服务于容器云平台，则API网关的实施部署则会显得更复杂些。

一、API网关

API网关(API Gateway)是一个服务器，是调用服务的唯一节点和请求应答出入口。API Gateway封装内部系统的架构，并且提供API给各个客户端。通常情况下它还需要实现其他功能，如认证授权、访问控制、路由、负载均衡、缓存、日志、限流限额、转换、映射、过滤、熔断、注册、服务编排、API管理、监控、统计分析等等。

从API网关的能力来看，我们可以理解其重要性。一夫当关，万夫莫开。API网关就承担这么一个重要的职责。其不但是整个服务系统的安全屏障，也承担着很多服务治理的能力。所以实现或者选择一个好的API网关，是建设容器云和微服务体系中一个至关重要的事项。这也决定了API网关的部署，要尽可能的减少接触面，确保安全。

二、API网关的作用和价值

现在有很多人也在鼓吹API经济，建立OpenAPI，为合作伙伴或客户提供云端API服务，根据服务的次数来收取一定的费用。这个我们暂不讨论，不过要采用微服务架构，API网关组件是不可或缺的。

很多人对于微服务API网关也都有比较深入的介绍。一个重要的原因是客户端和微服务通信、微服务重构、协议转换等的需要，所以我们需要一个API网关来承担这样的一个角色。

API网关提供集成能力，统一对外的接口，保护开放的应用，加速应用开发，也实现数据价值，监控分析业务趋势，协助构建开放平台等。

1. 集成以实现互连互通

API是系统间集成和企业间整个业务生态系统集成的接口，不管微服务架构或者ESB架构，一个很重要的价值就是实现系统或服务的集成，实现数据、服务共享，盘活整个公司的资源，同时减少重复的投资和建设。

2. 提供统一对外接口以实现标准化、规范化

当实现新的业务应用时或者需要集成不同系统或者服务之间的功能，调用不同服务提供的能力时，利用API网关可以让用户在不感知服务边缘的情况下，利用统一的接口编排组装服务。对于一个公司内部不同的服务，由于历史原因提供的接口可能有不小的差异，通过API网关可以消除这种差异，统一对外提供标准化的接口，比如Restful接口。 当内部服务更新时，也可以通过API网关进行适配转换，对客户端透明，不需要调用方进行调整。

3. 保护开放的应用以实现安全

在我们看来，API网关最重要的能力是其安全能力。减少对外暴露的服务可以增加系统安全性。实现授权认证、访问控制、防范威胁和OWASP漏洞、通过SSO和统一身份管理来等提高安全性，为应用程序、移动和IoT提供端到端的安全机制。也可能需要在API网关实现流量控制、限额、过滤、熔断、服务优先级控制、负载均衡等机制来保护应用服务的安全。不管private API或者OpenAPI， 其安全性都是一个时刻都需要认真面对的课题。

4. 简化应用和服务的开发以提升效率

在API网关层实现这些安全机制，不但提高安全性，也简化了应用服务的开发。使开发人员专注于业务应用、业务服务的研发，不再考虑基础能力基础组件，提升开发部署的效率，从而提升收益率。通过对 API服务的分类分级，简化和控制开发人员对数据和服务的访问;服务的开放和共享，可以构建更大范围内的协作和开发人员生态体系。加快业务服务业务应用的交付。

5. 释放数据价值，促进行业发展

数据永远都是有价值的，其价值的大小在于怎么去使用它。基于微服务的API服务提供了一种实现数据价值的方式，由API网关来管理这些API服务，是这些API服务不但可以自己用，也可以实现额外收益。同时又为其他企业提供了节省成本的方式，从而实现战略双赢。

6. 监控分析业务趋势，助力智能决策

API网关还要承担API的监控和管理职责。哪些API服务调用的多，哪些API服务调用的少，谁调用的多，以及高峰流量时刻、平均流量、响应时间等等都是需要监控和统计分析的。这些数据将有助于我们对API服务进行运维或重构，有助于我们做出合理决策。更为智能决策提供必须的数据支持。

7. 协助构建开放平台，建立生态系统

开放、合作越来越向各个层面扩展和延伸。大到全球化、地球村，小到团队协作，你已经无法单打独斗。封闭只会束缚自己。所以对企业来说，也是需要逐步构建和合作伙伴的生态系统，构建自己的开放平台以融入这个生态。API 网关是其关键的一环。

三、API网关要实现的能力

那么API网关要实现哪些能力?通常情况下，需要考虑下面这些能力：

1. API安全

安全第一，就像我们的社会交通一样，第一要保证安全，然后才是快速通过。这也是在实现或选择API网关时首先要考虑的问题。

安全涉及的问题也比较多，API网关层通常要实现身份统一认证，可对接统一认证中心、权限中心，实现授权认证、访问控制等功能。

为了最小化延迟，API网关要尽可能的薄。安全的前提下实现快速通过。不能堵塞，所以需要尽可能的减少延迟。

另外考虑采用安全传输，防止数据包被其他人篡改、伪造，防止非公共数据被其他人窃听。可能还需要考虑服务基础设施安全以及第三方应用/内容安全。

2. 服务预处理

路由、过滤、流控、限额、熔断、转换、优先级、负载均衡……我们在《微服务之服务治理》一文中有过讨论，这里就不再赘述。主要的服务治理策略，防止服务不可用。

3. 服务编排

使用API网关层构建组合服务——业务服务，这涉及到API网关的开发能力，也就是服务编排能力，大部分开源的API网关是不支持的。我们在《容器云之服务编排设计》一文中也讨论过。不过有个问题需要考虑，采用微服务架构，服务部署时可能部署多个服务实例，是每个服务实例都在注册中心注册，还是所有的服务实例只注册一个服务?这是我们曾经遇到的问题。

如果采用商用的API网关产品，基本上都有服务编排和服务注册能力，可以利用API网关的服务注册能力，在API网关层实现服务注册，而不用在每个微服务代码里实现服务注册。这样既可以在API网关层实现服务的编排，也可以充分利用容器云的负载均衡和弹性伸缩等特性，微服务实例不需要注册到注册中心，每个微服务(一到多个微服务实例)仅在注册中心注册一次。

这样，也简化了微服务开发，更多的关注微服务业务实现，把服务的注册、编排、流控等等都交给API网关层去实现。

4. 服务注册

API网关层提供服务编排能力，编排的服务也需要注册到注册中心，成为一个新的服务。API网关需要提供服务注册的能力。

我们遇到过这样一个问题：一个服务分别部署于容器云平台和虚拟机，分别注册于容器云平台内部注册中心和容器云平台外部注册中心，如何实现这个服务的调用?这是我们一个开发团队面临的问题。一方面希望利用容器云平台的便捷的持续集成持续部署特性，另一方面也不太相信容器云平台的可靠性和稳定性，所以希望在虚拟机环境同时备份。同样面临着多服务实例的问题，弹性伸缩的问题。如果在服务Client端实现负载均衡，明显要复杂很多。虚拟机和容器云平台如果都部署网关服务，也比较麻烦。最好的方式就是通过统一的API网关，实现路由配置，也可实现流量分配，这样一个API入口可以路由到不同的服务或服务实例(虚拟机或容器云平台上)。在API网关层通过配置来实现，API网关作为一个独立的组件来部署。比如Nginx plus其支持eureka、consul、etcd、等服务注册机制，作为整个平台独立的一个API网关独立部署。

5. API管理

通常情况下， API网关层需要考虑实现对API生命周期的管理、配置、监控等能力，也就是API管理的能力。API也可分为private API和 Open API。我们在讨论微服务阶段模型中提到生态级，就是提供OpenAPI与合作伙伴等共同构建服务生态系统。

商用API的管理产品通常包括API网关、API开发 工具 、管理控制台等组件，提供API开发、配置、部署、监控、更新等整个API生命周期管理。开源的API网关通常比较简单。提供API网关的基础能力或者仅API网关实施框架。

6. API网关部署

采用微服务部署于容器云平台，API网关作为重要的基础组件，其部署也需要认真考虑。前期的文章中我们也讨论过，就目前阶段而言，采用容器云也不是所有组件都容器化部署，在都热衷于讨论去中心化的今天也不是没有中心，所以我们建议采用中心化非容器化部署，采用双机集群多活高可用模式部署，不要采用主备模式，也不要单机部署，虽然商用的产品处理能力足够强，也要避免可能单点故障，单点瓶颈问题，难以扩展的问题。

在负载压力大的需求下，可以考虑分渠道部署方式，比如Web、手机App、PC App等分别部署API网关。

四、API 网关选择

1. 开源

越来越多的企业采用微服务，越来越多的人认识到微服务API网关的重要性，API网关的发展和完善也越来越好。很多开源的产品功能也很强大，足以满足大部分企业的部署需求。基于这些开源产品，可以定制扩展一些功能，更好的满足业务需求。

• Tyk(https://tyk.io/)是一个开放源码的API网关、面板和API管理平台，由Tyk公司开发和支持。Try 是一个基于 Go 实现的网关服务。包括Tyk API Gateway,Tyk Dashboard, Tyk Developer Portal, Tyk Pump, Tyk Identity Broker等组件。Tyk开源API Gateway对实际上的请求管理做了重大的提升：路由、访问控制、数据转换、日志等等。Tyk可以完全独立运行，只需要有效的 Redis 数据库，可以横向扩展(如下图)

• Kong(https://getkong.org/)是一个可扩展的开源微服务API网关，Kong 在任何RESTful API的前面运行，通过插件扩展，它提供了超越核心平台的额外功能和服务。它基于nginx 上进行的开发。Kong部署于可靠的技术之上，比如NGINX和Apache Cassandra或者PostgreSQL，提供易用的RESTful API来操作和配置应用服务。



• Zuul是Netflix出品的一个基于JVM路由和服务端的负载均衡器。它的主要功能有：认证、动态路由、监视、弹性、压力测试、金丝雀测试、负载削减、安全、静态响应处理和主动/主动交换管理。被用来作为上Spring Cloud的API网关组件，可以和spring cloud的各个组件结合使用。
• Spring Cloud Gateway是构建于Spring Frameworks 5, Factor项目和Spring Boot 2.0之上的可编程路由器。能够匹配任何请求属性的路由，熔断、过滤、服务发现集成、限流、转换等能力。它采用反应式编程，比较新，我们尝试用但由于时间紧，难以学习这么多新的技术，最后不得不依旧采用zuul暂时方案。
• NGINX或NGINX Plus提供一个成熟的、可扩展的、高性能web服务器和反向代理，它们均容易部署、配置和二次开发。Nginx可以结合 Lua 脚本实现一个API网关能力，NGINX Plus可以管理授权、权限控制、负载均衡、缓存并提供应用健康检查和监控等。

还有很多其他的一些开源API网关，有兴趣可以搜索查阅相关资料。

2. 自研

也有不少公司基于开源自研API网关，或者在实现微服务时使用类似SpringCloud Netflix Zuul等来实现微服务网关。这里涉及到微服务网关或者API网关的部署问题、以及服务间交互问题、网关要实现的能力问题等等。比如是集中式部署或是sidecar方式部署?不同的公司可能采用不同的方案。从我们视角来看，集中式部署应该会更合适些，特别是如果想基于容器云平台构建服务中台，更好的支撑业务应用，集中式非容器化部署更好。

API gateway 的实现方式有很多种，对于大多数应用，API Gateway的性能和可扩展性也是非常重要的。因此，创建一个支持同步、非阻塞I/O的API Gateway是有意义的。已经有不同的技术可以用来实现一个可扩展的API Gateway。在JVM上，采用基于NIO技术的框架，如Netty，Vertx，Spring Reactor或者JBoss Undertow。Node.js是一个非JVM的流行平台，它是一个在Chrome的JavaScript引擎基础上建立的平台。Spring Cloud Gateway就是基于Spring Ractor的实现。

API网关自研难度还是有的，要实现生产可用的微服务网关，需要考虑实现众多的功能。比如SpringCloud的相关组件包括：Zuul、Ribbon、EureKa、Fein、Hystrix等。其中Zuul就是一个类似APIGateway的组件，但仅有zuul远远不够。Ribbon是客户端负载均衡工具，Eureka用于注册和发现服务，Hystrix可以实现微服务的断路服务，用于服务降级。Fein可以作为一个Rest服务的提供者，可以供内部服务之间相互调用。包括但不限于所有这些能力都需要在API网关层实现。

要实现这些能力，技术力量要求就比较高，投入也不小，后期更新和运维都是需要考虑的，所以不太适合传统企业。传统企业更适合商用的方案。

3. 商用

商用的API网关产品也非常多，根据Partner 全生命周期API管理魔力象限，处于领导地位的产品有Google Apigee，CA API Management，IBM API Management，Axway， Mulesoft，TIBCO Mashary， Redhat 3Scale等。大部分都是美国的公司，国内这块需求似乎不明确，或者没有认识到其重要性，所以相关人员也很少，很难联系到。商用产品成本还是比较高，适合大的传统企业。Axway API Management等产品功能很强很完整，超出大部分公司的需求，所以这些商用的产品适合大的跨国公司或有众多分支机构的企业。小公司用起来有些浪费。

• Axway(https://www.axway.com/cn/node/2691)专业做API网关产品，中国团队响应非常敏捷，而且很nice，很热心。这个要给赞，五星好评!
• Apigee(http://apigee.com/) 目前算是最流行的一款API管理产品，国内似乎没有，在和Pivatal交流时他们提到pivotal的容器云产品内置支持Apigee。
• CA API Management(https://www.ca.com/us/products/api-management.html)也是一款功能特别强大的产品，和Apigee不相上下，不过我多次联系过CA 全球，CA API Management中国团队，网站留言等，得到过一次回复后就没有进一步的响应，产品很好，服务却很差，不得不给差评。
• 原来TIBCO有款API Exchange Gateway产品，是基于SOA服务的服务网关产品，不过产品相对功能简单，有很大局限性，目前TIBCO重点在推TIBCO Mashary, https://www.mashery.com/api-management， 这是TIBCO收购的产品，目前似乎还不支持on premises部署，这点有局限性，不过据说很快就可以支持。希望TIBCO能推出更好更适合不同需求更人性化的产品。也希望TIBCO中国团队好好努力。
• 3Scale API management(https://access.redhat.com/documentation/en-us/red_hat_3scale/)也是Redhat 收购的产品，我也是联系多次没有进一步响应。非常遗憾，至少服务不得不给差评。

产品的详细信息可以查阅网站相关资料深入了解。另外也可以考虑开源产品的企业版，比如Nginx Plus，Tyk专业版，Kong企业版等。

五、结论

对于传统企业，在采用API网关时，可以遵循基础设施平台外购、业务应用自研的原则。不必要花费大量的人力和财力来自研基础设施平台，外购成熟的产品是比较合适的方式。然后集中技术力量研发新业务应用和支持新业务。除非有足够的人力财力，并且想做行业内推广，以此来获取收益，可以考虑自研基础设施平台，不过这样和一家软件公司也没太大区别，成本投入也将非常大。如果基于开源做一些封装修改也是可以，但不会有众多的客户的实际环境验证，不会有商用产品的安全和稳定。如果没有足够强的技术实力，一旦遇到复杂的技术问题，就可能影响到实际业务。所以不同的公司不同的实际情况，可以选择合适的方式。