摘要:现在大家在谈“分布式”、“微服务”、“云原生”这些概念时,更多在谈支撑“软件服务”的弹性伸缩与负载均衡。API Gateway作为其第一道关卡以及其重要组成组件,我们来看看他的发展历程、现状及未来的方向。
API网关作为现代分布式、微服务、云原生系统中的一个重要组成部分,也作为一项重要的讨论主题,咱也聊聊负载均衡及API Gateway的现状。
现在大家在谈“分布式”、“微服务”、“云原生”这些概念时,除了“软件服务”功能本身,更多的是在谈如何让服务可以更好的扩展来支持大规模的应用。负载均衡及API网关是作为其第一道关卡以及其重要组成组件,我们来看看他的发展历程、现状及未来的方向。
谈到网关,不得不谈负载均衡,通常负载均衡有服务器负载均衡和客户端负载均衡(例如Spring Cloud Ribbon & Eureka)两种不同的方式。对于非REST且对实时性要求较高的服务来说,客户端负载均衡是一种常用的选择,比如王者荣耀、英雄联盟这种游戏来说,进入游戏的各种日常活动,都是基于REST服务的,而组队进行比赛时,通常都是非REST服务。还有在线协作的产品,如Welink的IM/Presence功能,其服务端是可以做成REST服务,而Welink Meeting这种实时音视频会议(real-time colloration),RESE服务不能满足其实时性要求。大都是采用客户端负载均衡的方式,基本过程如下:
1、负载均衡网关与服务器之间的注册或发现机制。
2、客户端向网关请求会议服务器列表,这里服务器会有一些业务逻辑从而计算出一些服务器列表返回给客户端。
3、客户端拿到服务器列表会向服务器发送探测报文,根据探测报文的响应时间(客户端与服务器之间网络状况),以及服务器的负载等因素来决定选择哪一个服务器。
4、客户端与服务器通过约定的协议建立业务连接。
5、如果客户端或者服务器任何一段出现异常,客户端会重新走2-4的流程恢复业务连接。
从上述可以看出客户负载均衡的会有一个相对复杂的过程,但是一旦建立连接,其性能一定是最优的。不过客户端负载均衡无法保证服务器REST服务化,一旦服务器发生故障,会有短暂的服务中断。但是该方案适用于一些实时性要求较高的一些应用(如上述说到的一些应用)。而对于REST的服务来说,采用L4负载均衡(F5、LVS、nginx、haproxy等)/L7负载均衡(haproxy、nginx、apache、Mysql proxy等)是通用的方法。这次Arch Summit,部分厂商介绍其采用4层负载均衡方案。我们来大致看一下整个分布式系统负载均衡的整体架构及发展历程。
从负载均衡的发展来看,根据其应用规模其演进过程大致如下:
随着微服务的流行,API Getway得到蓬勃的发展。对于API Gateway本职工作是承担消息分发任务,提供给客户统一的API入口。通常有2种方式:Single API Gateway和Backend for Frontend API Gateway。有沒有第三种模式呢?我之前做的一个产品,其网关基本架构如下:
1、客户端有登录的要求,在登录认证的response里,包含了不同服务的api的url列表。
2、客户端在不同的api请求是,使用对应的api url,这样客户端来实现了大部分api的分发工作。
3、这时候API 网关的主要任务其实已经不是最初的API转发的功能了。而是为了简化后端服务,实现后端服务的一些公共功能。
4、甚至在这种场景下,可以没有API网关,API可以直接面对应用服务,再由应用服务来调度微服务进行业务处理。
回到的API gateway本身,其最核心设计理念是保证数据面的业务不中断。由于对接 API 网关的服务是多样的,客户 API 跟应用的设计不可控,你很难能要求每个接入的服务以及客户端都具备容错能力。这就要求网关尽量保证能正常处理每个请求,且满足较高的 SLA,现在业界的 API 网关的主流使用Nginx系,主要考虑如下:
随着现在的系统的越来越复杂,很多服务模块除了处理自身业务之外,还有承担一些非业务的职责,如认证和授权,限流,缓存,日志,监控,重试,熔断等。这样涌现了一批开源的API网关实现。
除了上述功能,随着API网关服务承担了越来越多的职责,其性能瓶颈也越显突出。这次ArchSummit一些公司展示了一些自己的特色功能,还有在产品演化中,自己在架构上做了一些优化,主要有:
从网关的发展来看,其经历了一代又一代的演进,从自身架构的演进,再到其功能上叠加,在促进其架构上的再此迭代演进。在现再这个万物皆云的时代,云原生这个概念已经被各个行业所接受并且提高一个很高的高度。连一些传统的网络设备业务也要上云。
对于产品的发展与演进,我们也会“抄、学、变”。
|