API网关意义

API网关旨在用一套单一且统一的API入口点，来组合一个或多个内部API。

API网关定位为应用系统服务接口的网关，区别于网络技术的网关，但是原理是一样的。API网关统一服务入口，可方便实现对平台众多服务接口进行管控，如对访问服务的身份认证、防报文重放与防数据篡改、功能调用的业务鉴权，以及响应数据的脱敏、流量与并发控制，甚至基于API调用的计量或计费等。

API并不能适用于所有场景

在基于微服务的架构设计中，往往包含多个服务，这些服务并不能适用于所有场景。例如，在一个面向PC的Web应用中，服务所要提供的API是要返回一个页面，而非单纯的数据，那么这样的API只能适用于Web应用，而不能适用于移动APP。

又如，在移动APP的架构设计中，由于网络带宽的限制，在设计API时，往往会考虑较少的网络传输次数及更少的传输数据。而面向PC的Web应用却无须考虑这些限制。

图10-1展示了不同场景下的API网关使用情况。

API网关常用于以下场景。

黑白名单:实现通过IP地址控制禁止访问网关功能。
日志:实现访问日志的记录，可用于分析访问、处理性能指标，同时将分析结果支持其他模块功能应用。
协议适配:实现通信协议校验、适配转换的功能。
身份认证:负责网关访问身份认证验证。
计流限流:实现微服务访问流量计算，基于流量计算分析进行限流，可以定义多种限流规则。
路由:是API网关很核心的模块功能，此模块实现根据请求锁定目标微服务，并将请求进行转发。

API网关所带来的好处

API网关能够为外部消费方提供一套统一的入口点，且不会受到内部微服务的具体数量与组成的影响。

API网关为微服务架构系统带来了如下好处。

1.避免将内部信息泄露给外部

在数据安全方面，API网关能够将外部公共API与内部微服务API区分开来，使各项微服务在添加或变更时，能有明确的安全边界。这样，微服务架构就能随时间推移而始终通过重组来保证系统安全，且不会对外部绑定客户造成影响。另外，其还能够为全部微服务提供单一入口点，从而避免外部客户进行服务发现及版本控制信息查看。

2.为微服务添加额外的安全层

API网关能够提供─套额外的保护层，足以应对SQL注入、XML解析攻击及拒绝服务(DoS)攻击等常见威胁因素，从而实现额外的保护层效果。系统的权限控制也可以在这一层来实施。

3.支持混合通信协议

面向外部的API，由于考虑到平台和语言的无关性，往往向外提供基于HTTP或REST的API。但内部微服务往往会采用不同的通信协议。此类协议包括ProtoBuf、AMQP或其他集成有SOAP、JSON-RPC或XML-RPC的系统。API网关可跨越这些协议，提供一个外部统一的、基于REST的API，并允许各团队以此为基础选择最适合内部架构的协议方案。

4.降低构建微服务的复杂性

微服务架构系统往往拥有比单个架构更多的管理复杂度，如API令牌验证、访问控制及速率限制等。每一项功能的实施，都会给相关实现服务带来影响，进而会延长微服务的开发时间。API网关能够从代码层面隔离这些功能项，使开发人员在构建单个微服务时，能够专注于实际的核心业务。

5.微服务模拟与虚拟化

通过将微服务内部API与外部API加以区分，大家可以模拟或虚拟化自己的服务，从而满足设

计要求或配合集成测试。

API网关的弊端

虽然使用API网关会给微服务架构带来一定的好处，但同时仍然要考虑如下的弊端。

由于额外API网关的加入，会使整个开发在架构上考虑更多的编排与管理工作。
在开发过程中，对路由逻辑配置要进行统一的管理，从而能够确保以合理的路由方式对接外部API与专用微服务。
除非架构本身充分适应高可用性与规模化要求，否则API网关往往会成为一项限制性因素，甚至引发单点故障。

常见API网关的实现方式

业界常用的API网关方式有很多，技术方案也很成熟，其中也不乏很多开源的产品，如NG-INX、Tyk、Kong、API Umbrella、ApiAxle、Zuul、WSO2 API Manager等。下面介绍三种常见的API网关方案。

NGINX

NGINX是一个免费的、开源的、高性能的HTTP服务器和反向代理，以及一个IMAP/POP3代理服务器。NGINX以其高性能、稳定性、丰富的功能集、简单的配置和低资源消耗而闻名。

NGINX是为解决C10K问题而编写的少数服务器之一。与传统服务器不同，NGINX不依赖于线程来处理请求。相反，它使用可扩展的事件驱动(异步）架构。这种架构在负载下使用小的但更重要的可预测的内存量。即使用户不希望处理数千个并发请求，仍然可以从NGINX的高性能和小内存中获益。NGINX在各个方向扩展:从最小的VPS一直到大型服务器集群。

NGINX拥有诸如Netflix、Hulu、Pinterest、CloudFlare、Airbnb、WordPress.com、GitHub、SoundCloud、Zynga、Eventbrite、Zappos、Media Temple、Heroku、RightScale、Engine、Yard,MaxCDN等众多高知名度网站。

NGINX具有很多非常优越的特性。

作为Web服务器;相比Apache，NGINX使用更少的资源，支持更多的并发连接，体现更高的效率，这点使NGINX尤其受到虚拟主机提供商的欢迎。
作为负载均衡服务器:NGINX既可以在内部直接支持Rails和PHP，也可以支持作为HTTP代理服务器对外进行服务。NGINX用C语言编写，系统资源开销小，CPU使用效率高。
作为邮件代理服务器:NGINX同时也是一个非常优秀的邮件代理服务器（最早开发这个产品的目的之一也是作为邮件代理服务器）。

将NGINX作为API网关

NGINX用server_name来定义服务器名称，所以它可以决定哪一个server块将用来处理给定的请求，也就是实现了API网关的功能。

NGINX可以使用精确名称、通配符、正则表达式来定义服务器名称。下面是一个例子。

server{
listen
80;
server name example.org www.example.org;
server {
listen 80;
server name .example.org;
..
server{
listen80;
server namemail.*;
server {
listen
80;
server name~^(?<user>.+).examplel.net$;
。。。
}

当寻找一个虚拟服务器的名称时，如果指定的名称匹配多个变量，如通配符和正则表达式都匹配，将会按照以下的顺序选择第一个匹配的变量。

精确名称。
以星号“*”开头的最长的通配符，如“*.example.org”。
以星号“*”结尾的最长的通配符，如“mail.*”。
第一个匹配的正则表达式（根据在配置文件中出现的顺序）。

Spring Cloud Zuul

Zuul是Netflix公司开源的一个API网关组件，提供了认证、鉴权、限流、动态路由、监控、弹性、安全、负载均衡、协助单点压测、静态响应等边缘服务的框架。

Zuul的基本功能如下。

验证与安全保障:识别面向各类资源的验证要求并拒绝那些与要求不符的请求。
审查与监控:在边缘位置追踪有意义的数据及统计结果，从而为用户带来准确的生产状态结论。
动态路由:以动态方式根据需要将请求路由至不同后端集群处。
压力测试:逐渐增加指向集群的负载流量，从而计算性能水平。
负载分配:为每一种负载类型分配对应容量，并弃用超出限定值的请求。
静态响应处理:在边缘位置直接建立部分响应，从而避免其流入内部集群。

Zuul处理每个请求的方式是针对每个请求使用一个线程来处理。通常情况下，为了提高性能，所有请求会被放到处理队列中，从线程池中选取空闲线程来处理该请求。2016年年底，Netlix将它们的网关服务Zuul进行了升级，全新的Zuul 2将HTTP请求的处理方式从同步变成了异步，以提升其处理性能。

Spring Cloud Zuul是基于Netflix Zuul的微服务路由和过滤器的解决方案，也用于实现API网关。

有关Zuul的内容，将会在本文后续章节中详细介绍。

Kong

Kong 是专注于提供微服务API网关的管理平台，它本身是基于NGINX的，但比NGINX提供了更为简单的配置方式，并且提供了一些优秀的插件，如验证、日志、调用频次限制等。

Kong 另外一个强大之处在于提供了大量的插件来扩展应用，通过设置不同的插件，可以为服务提供各种增强的功能。Kong 的插件平台可以访问
https://konghq.com/pluginsl。

Kong具有以下特性。

支持云部署:可以运行在Kubernetes管理的平台上。
动态负载均衡。
服务器发现
webSocket。
OAuth2.0。
日志。
安全:ACL(访问控制）、CORS（跨域资源共享）、动态SSL、IP限制、爬虫检测实现。
系统日志。
SSL。
监控。
认证:HMAC、JWT、Basic等。
速率限制。
缓存。
RESTAPI。
集群。
可扩展。

图10-2展示了Kong 的架构示意图，该图来自Kong官网。

本篇文章内容给大家讲解的是API网关的意义和常见API网关的实现方式

下篇文章给大家讲解如何集成 Zuul和实现API网关；
觉得文章不错的朋友可以转发此文关注小编；
感谢大家的支持

微服务架构开发实战：API网关意义和常见API网关的实现方式相关推荐

gradle 指定springcloud 版本_SpringCloud微服务架构开发实战：实现服务注册与发现
实现服务的注册与发现在前面分别用Eureka Server和Eureka Client来搭建了一台注册服务器,以及多个Eureka Client客户端.Eureka Client在启动后,就会将自己 ...
微服务架构开发实战：如何实现微服务的自动扩展？
微服务架构开发实战:如何实现微服务的自动扩展? 程序员高级码农II 2020-09-25 07:25:00 如何实现微服务的自动扩展前面讲了一些关于自动扩展的理论知识,但如何实现自动扩展,并不是三言 ...
微服务架构开发实战：如何集成Zuul和实现API网关？
如何集成 Zuul 本节将基于Zuul来实现API网关.作为Spring Cloud 的一部分,集成Zuul会变得非常简单. Zuul简介路由是微服务架构中必需的一部分,如""可 ...
springcloud微服务架构开发实战：分布式消息总线
消息总线的定义前面在1.4.2节中强调过,在微服务架构中,经常会使用REST 服务或基于消息的通信机制. 在3.6节中也详细介绍了消息通信的实现方式.消息总线就是一种基于消息的通信机制. 消息总线是 ...
微服务架构开发实战日志与监控：微服务日志管理将面临的挑战
微服务的日志与监控:微服务日志管理将面临的挑战日志来自正在运行的进程的事件流.对于传统的JavaEE应用程序而言,有许多框架和库可用于日志记录.Java Logging (JUL)是Java自身所提 ...
《Spring Cloud微服务架构开发实战》_董超笔记
服务治理一.服务治理说明 1.方便微服务实例的上线与下线,实现服务快速进行水平扩展. 2.为微服务架构提升应用弹性,当其中一个应用的一个服务提供者实例不可用或者出现问题时,服务治理可及时发现问题,在 ...
spring cloud 日志_微服务架构开发实战：ElasticStack实现日志集中化
常见日志集中化的实现方式有许多现成的可用于实现集中式日志记录的解决方案,它们使用不同的方法.体系结构和技术.理解所需的功能并选择满足需求的正确解决方案非常重要. 日志托运有一些日志托运组件可以与其 ...
微服务架构开发实战：分布式消息总线，实现配置信息的自动更新
实现配置信息的自动更新在上一篇文章中节演示了集成Spring Cloud Bus 的过程.在示例中,当微服务实例启动的时候,可以去加载最新的配置信息.当时这种做法有一定的局限性,即只有在应用启动的过 ...
Java开发面试题目，微服务架构开发实战
面试失败之后在这之后的很长一段时间后,他没敢再去面试,觉得自己太丢人.技术太差不敢去谈论技术话题.后来他渐渐开始看网上的文章,知道要刷leetcode,看面经,然后之后一年多的时间,边上课,边刷题, ...

微服务架构开发实战：API网关意义和常见API网关的实现方式

API网关意义

常见API网关的实现方式

本篇文章内容给大家讲解的是API网关的意义和常见API网关的实现方式

微服务架构开发实战：API网关意义和常见API网关的实现方式相关推荐

最新文章

热门文章