机房360首页
当前位置:首页 » 云计算资讯 » 部署微服务于容器云平台,API网关应如何选择?

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

来源:talkwithtrend 作者:汪照辉 王作敬 更新时间:2018/8/2 10:27:12

摘要:微服务越来越火,越来越多的公司开始采用微服务架构。今天还有人让我帮推荐好的微服务实施厂商。但采用微服务并不容易,实施微服务可能不可或缺的一个很重要的组件就是API 网关。

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

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

  API网关

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

1

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

  API网关的作用和价值

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

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

1

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

  集成以实现互联互通

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

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

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

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

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

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

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

  释放数据价值,促进行业发展

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

  监控分析业务趋势,助力智能决策

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

  协助构建开放平台,建立生态系统

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

  API网关要实现的能力

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

1

  API安全

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

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

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

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

  服务预处理

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

  服务编排

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

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

1

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

  服务注册

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

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

  API管理

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

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

  API网关部署

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

1

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

1

  API网关选择开源

  越来越多的企业采用微服务,越来越多的人认识到微服务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数据库,可以横向扩展(如下图)

1

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

1

  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网关,有兴趣可以搜索查阅相关资料。

  自研

  也有不少公司基于开源自研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网关层实现。

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

  商用

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

  责任编辑:DJ编辑

机房360微信公众号订阅
扫一扫,订阅更多数据中心资讯

本文地址:http://www.jifang360.com/news/201882/n5700105291.html 网友评论: 阅读次数:
版权声明:凡本站原创文章,未经授权,禁止转载,否则追究法律责任。
相关评论
正在加载评论列表...
评论表单加载中...
  • 我要分享
推荐图片