IT大视野
数码世界 P.84基于API网关的微服务组合策略研究
吴润  武汉大学计算机学院
摘要：随着微服务体系架构的出现，越来越多的大型应用程序开始采用微服务的方式来部署和运行，传统的单体架构应用被拆分为多个功能独立的微服务。微服务架构解决了单体架构扩展性和维护性差的问题，但多个微服务如何有效地进行协同组合工作成了新的问题，微服务组合也成为了微服务架构中不可忽视的研究重点。本文分析了微服务组合所面临的问题，并对当前微服务组合研究现状进行了介绍，，最后重点分析了基于API 网关的微服务组合策略。
关键词：微服务架构 API网关 微服务组合
1引言
随着企业级应用程序规模的不断扩张，应用的更新、部署以及维护工作变得越来越繁重，以单体架构方式构建的应用越来越难以为继，而微服务架构的出现为大型应用程序开辟了另一条通道，而云计算、容器虚拟化、基础设施自动化等技术的不断涌现，更是为微服务架构的发展提供了良好的基础。微服务架构通过对应用进行分析，将原本单体应用中庞大冗杂的功能模块分解成体量小，功能明确并且耦合度低的多个微
服务，这些微服务相互协同完成工作。
微服务通常具备以下特点：
单一职责。在面向对象程序设计中，我们提倡高内聚、低耦合，同理，每个微服务在服务架构层面都遵循单一职责原则，每个单独的微服务都负责特定的业务逻辑。
相互独立。在传统的单体架构应用中，所有的功能模块代码都糅合在一起，修改某个功能模块很可能会影响到另一个功能模块，在修改过后，还需要进行重新集成，通过测试还要进行统一打包，再部署到相应的服务器环境中。因此，在单体应用中，功能模块的开发、测试和部署过程都会互相产生影响，而微服务架构中，每个微服务都是独立的业务单元，有着独立的代码库，并且可以单独测试和部署。
轻量级的通信方式。微服务之间通常通过轻量级的通信机制进行通信，这些轻量级的通信方式通常是与语言和平台完全无关的。也正因为如此，不同的微服务甚至可以使用不同的语言进行开发，增加了灵活性。
在微服务架构中，微服务都是一些功能单一、相互独立的功能单元，其功能有限，如果需要实现某种复杂功能，则需要对已有的微服务进行适当组合，相互协作以实现各种多样化的功能需求。因此，可以将不同功能，易于执行且简单的微服务通过某种组合策略集成在一起实现强大的功能。
2微服务组合相关概念
2.1 web服务组合
提到微服务架构，就不得不提到面向服务架构（SOA），两者在某些方面有着不少相似之处，在SOA中，服务也是通过某种组合方式来相互协同完成某个具体功能。在web服务组合策略中，通常分为两种方式，一种称为编排方式（choreography），编排方式可以看做是一种消息驱动方式，实现方案大多是异步的，监听业务事件的web服务会主动获取消息，进行处理，然后发布自己的消息；另一种方式称为编制方式（ochestration），编制方式的实现方案大多是同步的，这种设计方式中往往有一个流程控制服务，该服务接收请求，并按照业务逻辑调用各个web服务，最后完成任务。以上两种服务组合方式都有对应的标准支持，分别是BPEL4WS（Business Process Execution Language for Web Services）和WS-CDL (Web Service Choreography Definition Language)，BPEL4WS适合用于服务编制，此标准主要用于组织内部的业务流程管理，而且很多BPM产品基于此规范实现，WS-CDL是专门的web服务编排标准。
2.2微服务组合
与web服务组合相类似，微服务组合采用某种适当地策略将若干个相互独立，功能单一的微服务组合成一个功能更强大的服务，为某个具体的业务功能提供支持。不同之处在于微服务相较于web服务而言，
粒度更小，功能更加独立，而不是面向业务，因此，相比较而言，微服务组合问题面临着更大的挑战。
2.3微服务组合需要解决的问题
在微服务架构中，由于微服务是较小粒度的独立功能单元，因此，通常一个具体的业务功能需要调用多个微服务，这就涉及到服务的映射和路由问题；其次，安全防护也是一个必要的考量，对来访的用户应该进行必要的身份认证，只有得到授权的用户才有访问权限；另外，可用性是保证服务稳定性的重要指标，在调用微服务的过程中，不可避免地会出现服务无响应或服务繁忙等情况，对于这些服务不可用的情况必须提供超时或熔断处理；最后，系统也可能面临短时间内访问量剧增的情况，考虑到系统有限的负载能力，通过采用适当的策略减轻服务的压力也是需要考虑的问题。
3微服务组合研究现状
伴随着微服务架构的出现，对于微服务组合策略的研究也随之出现，工业界和学术界也都纷纷提出了不同的解决方案，大体上分为两种，一种借鉴web服务组合的编排策略对微服务进行某种形式编排以实现微服务组合，另一种则是通过使用API网关来实现微服务组合。
Netflix Conductor是一个典型的借鉴web服务组合策略的微服务组合工具。Conductor支持创建复杂的业务流，这些业务流通过基于JSON DSL制定的蓝图来定义其整个执行流程，这些流程蓝图反过来也为整
个业务流提供了可见性和可追溯性。另外，在业务流程的执行过程中，Conductor也支持暂停、恢复、重启等多个控制语义，使其在运行时可以灵活应对各种突发情况。在性能上，Conductor能够在必要时同步处理所有任务，并允许扩展数百万个并发处理的业务流程。可以说，Conductor作为Netflix内部使用多年的微服务编排工具，其在多个方面都有优秀的表现。
图1  Netflix Conductor运行时模型
IT 大视野
数码世界 P .85
文献[5]提出了一个轻量级微服务组合平台Medley。Medley 首先为微服务组合定义一套服务组合规范，通过这些规范来约束微服务组合，然后通过编译器将这些规范语义编译成描述微服务组合的代码，最后将这些代码部署在服务器的Docker 容器中执行，从而实现整个服务组合流程。
基于API 网关实现微服务组合也是目前微服务领域较为常用的策略。API 网关往往作为一个系统的入口，是连接所有客户端和服务端的关键节点，通过一个统一的API 网关，客户端和服务端能够非常方便地进行交互而无需了解其底层微服务细节。API 网关对系统内部的细节进行了封装，将所有非业务功能放在网关层进行处理，使其内部组织结构对API 调用者透明，且对于每个调用者都提供对应的定制API。除此以外，API 网关在微服务架构中还可兼具负载均衡、身份验证、限流等多个功能职责。
4基于API 网关的微服务组合
4.1 API 网关的诞生背景和意义
相对于诞生不久的微服务架构而言，其实API 网关在很多领域并不算是一个新名词，早在微服务被提出并在业界流行起来之前，API 网关就已经在金融证券领域的前置机系统上得到应用。API 网关的作用在
于其将客户端和服务端有效地进行了分离，通过网关将后端的微服务进行组合并映射到对应的API，降低了客户端和服务端之间的耦合性，在面对业务变化时也能更方便地进行功能扩展与变更，节省了开发成本，通过API网关的功能聚合作用，可以有效提高系统访问效率。
随着移动互联网时代的到来，传统的系统后台需要支持的客户端对象从单一的PC 端逐渐转移到手机，平板等移动端，服务场景的增多一方面对后台的吞吐量提出了更高的要求，另一方面也无形中增大了后台服务的复杂性，毕竟不同的客户端由于使用场景的不同对后台的响应需求也各不相同，而借助于API 网关的强大功能，以上问题可以得到有效解决。尤其在微服务架构中，我们构建的微服务可能会面临服务端口更改和服务实例的变更问题，不同的微服务可能采用了不同的数据协议，对于客户端而言，其直接调用的往往是粗粒度的API，而微服务往往是细粒度的API，如果客户端直接调用细粒度的微服务，会大大增加API 调用的复杂性和系统耦合性，而这些问题也都在API 网关的解决范畴之内。因此，随着微服务架构的日益成熟完善，在很多微服务架构体系中，API 网关都成为了不可或缺的一个关键组件。
4.2 API 网关的解决方案
随着微服务架构的发展成熟，业界也相继出现了很多成熟的API 网关解决方案，常见的有Tyk、Orange、Kong、Netflix Zuul、apiaxle、Api-umbrella、Amazon API Gateway 等等。
Tyk 是一个轻量级的开源API 网关，基于Go 语言开发[6]。在安全认证方面，Tyk 支持多种认证方式，包
括基本身份认证、令牌认证、HMAC 签名认证、Json Web 令牌认证，也支持以上多个认证方式组合使用。在API 的访问控制方面，Tyk 内置了流量限制机制，包括速率限制、请求配额和请求大小限制。Tyk 提供了两种速率限制器，即硬同步速率限制器和分布式速率限制器来实现速率限制。配额类似于速率限制，它允许在一定时间内通过一定数量的请求。Tyk 支持在全局和各端点设置最大请求长度，以拒绝任何超过设定长度的请求。
Orange 是一款基于OpenResty 的API 网关，除了具备Nginx 的基本功能外，它还具备API 重定向和鉴权、流量切分、访问限速、访问统计以及web 防火墙等多种功能，是一个功能齐全的网关系统。Orange 的特性之一是其内置了多个通用插件，如全局状态统计、URL 重写、URL 重定向、自定义监控、访问限速、鉴权、WAF 防火墙等。
Kong 是Mashape 提供的一款开源API 网关，起初用于维护、管理和扩展其Marketplace 中的API 和微服务[8]。Kong 是基于Nginx 实现的，或者准确的说，Kong 是一个运行在Nginx 中的Lua 应用程序，它比Nginx 提供了更加简单的配置方式。Kong 主要包含两个重要组件，即Kong Server 和Apache Cassandra，前者用来接收API 请求，后者用来存储操作数据，可以通过增加Kong Server 的数量来对Kong 服务进行水平扩展，并通过负载均衡器转发请求以应对访问压力。Kong 的优秀之处在于其提供了大量的插件来扩展应用，为可插拔架构奠定了基础，Orange 的很多设计也正是借鉴于此。
Zuul 是由Netflix 开源的网关产品，其在Spring Cloud Netflix 项目中的主要作用相当于路由器和服务器端负载均衡器[9]。通过Zuul 的过滤器，Netflix 可以实现认证、测试、动态路由、服务迁移、安全、流量管理等操作。Zuul 的规则引擎支持任何以JVM 语言编写规则和过滤器，如Java 和Groovy 。
Apiaxle 是基于Nodejs 实现的开源API 管理平台，是一个免费的本地托管的API 管理解决方案[10]。APiaxle 系统主要包含三个组件，即Apiaxle-proxy、Apiaxle-api 和Apiaxle-repl，其中，Apiaxle-proxy 是系统执行代理的组件，负责身份验证、，密钥检查等工作，Apiaxle-api 负责负责管理用户、密钥等，Apiaxle-repl 则提供了一个以命令行的方式来管理Apiaxle 的途径。
通过以上对API 网关的简要介绍与分析，不难看出不同的API 网关之间还是存在明显的差异。首先，API 网关可能基于不同的技术基础来实现，如Kong 和Orange 基于Openresty 实现的，Openresty 本身则基于Nginx 和Lua 实现，而其他大多数API 网关基本是原生开发的。其次，不同的API 网关可能由不同的编程语言开发，如Tyk 基于Go 语言开发，Apiaxle 基于Nodejs 开发，Api-umbrella 基于Ruby 开发等等。另外，不同的API 网关的性能和稳定性可能也不一样，比如Zuul 有着易适用，配置简单等优点，同时其本身还存在重定向、异常处理等亟待解决的问题，而本身基于Nginx 开发的Kong 和Orange 等则依托于Nginx 的成熟稳定，其性能和稳定性可以得到有效保障。
尽管不同的API 网关之间差异明显，但总体而言，API 网关作为微服务架构中的重要一环，在连接系统
客户端与服务端并聚合微服务方面有着重要作用，为微服务调用中的安全性、准确性和稳定性提供了重要保障，为微服务组合问题提供了一个可行的解决方案。
4.3 使用API 网关来实现微服务组合
在微服务架构系统中，API 网关通常作为整个系统的唯一入口节点，其封装了系统内部结构，对外为各个客户端提供定制API。API 网关负责服务请求路由、服务组合以及服务协议转换，来自客户端的所有请求首先到达API 网关，然后API 网关根据请求路由到对应的微服务，这些最终被调用到的微服务通常会有多个，API 网关负责将它们的返回结果进行合并最终返回给客户端。此外，一个功能完整的API 网关往往还负责用户身份认证及授权、超时处理、服务限流控制、熔断保护、负载均衡和日志记录等功能。可以说， API 网关完全可以应对各种微服务组合问题。
4.3.1 服务路由
API 网关授权给客户端调用某个API，通常会预先在配置文件中配置服务路由。当客户端访问请求到达API 网关时，根据已配置的路由规则，API 网关将访问接口映射到系统内部对应的微服务访问接口，最终调用微服务并返回结果。当然，API 网关也支持主动设置拦截或忽略某些请求， 当符合这些配置路径的请求到达时，API 网关拦截这些请求并拒绝提供服务。
IT 大视野
数码世界 P .86
4.3.2客户端身份认证及授权
API网关作为系统的统一入口，为保障服务被安全合法地调用，身份认证自然是其必需的功能。API 网关的身份认证功能通常包括用户客户端合法性认证、客户端访问授权验证等。当用户进入系统，系统通过其提供的有效凭证（如用户名和密码）为其赋予一个身份认证令牌，当客户端请求某个服务资源时，
需要首先提供前面获得的身份认证令牌，身份认证服务通过验证该令牌来确定该用户请求是否合法有效。
4.3.3 服务超时处理
在理想情况下，微服务应该随调随用，但在实际环境中，不可避免地会出现服务器故障或者断电等或任何导致服务实例失效的情况，在这种情况下，API 网关不可能无限制地等待某个微服务响应，此时，服务超时处理就显得尤为关键了。通常，在API 网关中会设定一个最长允许超时时间，一旦API 网关调用微服务等待时长超过了这个设定值便会立刻停止调用，防止无意义的等待。
4.3.4 服务熔断保护处理
熔断处理在一定程度上保证了微服务调用的容错性，当API 网关调用的某个微服务出现异常的次数到达设定阈值时，API 网关会启动熔断保护机制，临时切断当前的微服务调用，以防错误进一步扩大，同时在合适的时机又会停止熔断保护。常见的熔断机制包含三种状态，即关闭状态、打开状态和半开状态，满足相应条件的情况下三种状态可以相互转化。正常情况下，熔断器处于关闭状态，当微服务调用异常次数达到设定阈值则转化为打开状态，打开状态经过了熔断保护时间则转为半开状态，在半开状态下微服务调用成功则转为关闭状态。
关闭
开启
半开
失败次数低于阈值
失败次数达到
阈值
成功
熔断
时微服务网关设计
间
结
束
失败
图2  熔断器状态转换机制
4.3.5 负载均衡
负载均衡在现代大型网站中早已成为标配之一，其作用是利用服务集的优势提高网站的性能，在API 网关中也是如此。在API网关中，对API接口进行负载均衡，能充分提高其并发访问能力，当客户端请求到达API 网关，根据设定的调度策略，该请求会被分配给合适的后台服务器进行处理，有效的防止了服务雪崩。
4.3.6 服务限流
在微服务架构中，我们往往会面临系统负载能力有限，而实际的请求数量却大大超出了系统的负载上限，为了防止短时间内大量请求对系统造成过大压力进而导致系统崩溃，对服务进行限流控制势在必行。不同的限流策略可能不尽相同，最常用的方式是为微服务设定单位时间内的最大请求数，当这个服务的单位时
间内的调用数到达设定阈值时，API 网关会短暂地终止对此服务的调用。
5结束语
伴随着微服务架构的出现，微服务组合问题也称为一个亟待解决的问题，在将粒度较小、功能单一的微服务组合为一个个具体的业务功能的过程中，所面临的安全性、可用性以及服务映射等诸多挑战。借鉴于Web 服务组合所采用的编制和编排方法，诞生了若干针对微服务组合问题的解决方案，但终究无法面面俱到，而API网关则为微服务组合问题提供了一个较为完备的解决方法，依托于API 网关的强大功能，微服务组合所面临的问题都可以得到有效解决。随着微服务技术的日益成熟，API 网关的功能也愈发强大，相信其能够为微服务组合问题提供更有力的支持。
参考文献
[1]王磊.微服务架构与实践[M].北京：电子工业出版社，2016：17-19[2] Papazoglou M P ，Heuvel W J．Service oriented architectures ：approaches，technologies and research issues[J]. Vldb Journal，2007，16(3)：389-415.
[3]王鑫，谢红薇. 基于编排和编制的Web服务组合技术研究[J]. 电脑开发与应用,2009,22(5):1-2.
[4]Netflix,Inc.”Netflix,Inc.Conduct-or”[EB/OL].[2017-12-14]flix.github.io/conductor/.
[5] Yahia E B H，Ｒéveillère L，Bromberg Y D.Medley：An event-driven lightweight platformforservicecomposition[C].Int-ernational Conference on Web Engineer-ing.Springer，2016：3-20.[6]Tyk Technologies.”
Tyk Open Source API Gateway”[EB/OL].[2018-4-17].tyk.io/features/.
[7]Sumory.”一个基于OpenResty / Nginx 的HTTP API Gateway”[EB/OL].[2017-5-17]. orange.sumory/.
[8]Kong,Inc.”Kong,Inc.kong”[EB/OL].[2019-2-15].github.
com/Kong/kong.
[9]Netflix,Inc.”Netflix,Inc.Zuul”[EB/OL].[2018-3-14].github/Netflix/zuul/wiki.
[10]ApiAxle,LTD.”ApiAxle,LTD.Apiaxle”[EB/OL].[2016-11-1].github/apiaxle/apiaxle.
作者简介
吴润(1991－)，硕士研究生，研究领域为软件工程
基金
国家重点研发计划（2018YFB1702703

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。