个推微服务网关架构实践

作者:个推应用平台基础架构高级研发工程师 阿飞

在微服务架构中,不同的微服务可以有不同的网络地址,各个微服务之间通过互相调用完成用户请求,客户端可能通过调用N个微服务的接口完成一个用户请求。因此,在客户端和服务端之间增加一个API网关成为多数微服务架构的必然选择。

在个推的微服务实践中,API网关也起着至关重要的作用。一方面,API网关是个推微服务体系对外的唯一入口;另一方面,API网关中实现了很多后端服务的共性需求,避免了重复建设

个推微服务网关的设计与实现

个推微服务主要是基于Docker和Kubernetes进行实践的。在整个微服务架构中,最底层的是个推私有部署的Kubernetes集群,在集群之上,部署了应用服务。

个推的应用服务体系共分为三层,最上一层是网关层,接着是业务层,最下面是基础层服务。在部署应用服务时,我们使用了Kubernetes的命名空间对不同产品线的产品进行隔离。除了应用服务外, Kubernetes集群上还部署了Consul来实现配置的管理、Kube-DNS实现服务注册与发现,以及一些辅助系统来进行应用和集群的管理。

下图是个推微服务体系的架构图。

个推对API网关的功能需求主要有以下几方面:

  1. 要支持配置多个产品,为不同的产品提供不同的端口;
  2. 动态路由;
  3. URI的重写;
  4. 服务的注册与发现;
  5. 负载均衡;
  6. 安全相关的需求,如session校验等;
  7. 流量控制;
  8. 链路追踪;
  9. A/B Testing。

在对市面上已有的网关产品进行调研后,我们的技术团队发现,它们并不太适合应用于个推的微服务体系。第一,个推配置的管理都是基于Consul实现的,而大部分网关产品都需要基于一些DB存储,来进行配置的管理;第二,大部分的网关产品提供的功能比较通用,也比较完善,这同时也降低了配置的复杂度以及灵活性;第三,大部分的网关产品很难直接融入到个推的微服务架构体系中。

最终,个推选择使用了OperResty和Lua进行自研网关,在自研的过程中,我们也借鉴了其他网关产品的一些设计,如Kong和Orange的插件机制等。

个推的API网关的插件设计如下图所示。

OpenResty对请求的处理分为多个阶段。个推API网关的插件主要是在Set、Rewrite、Access、Header_filter、Body_filter、Log这六个阶段做相应的处理,其中,每一个插件都可以在一个或多个阶段起到相应的作用。在一个请求到达API网关之后,网关会根据配置为该请求选择插件,然后根据每个插件的规则,进一步过滤出匹配规则的插件,最后对插件进行实例化,对流量进行相应的处理。

我们可以通过举例来理解这个过程,如上图所示,localhost:8080/api/demo/test/hello这个请求到达网关后,网关会根据host和端口确定产品信息,并提取出URI(/api/demo/test/hello),然后根据产品的具体配置,筛选出需要使用的插件——Rewrite_URI、Dyups和Auth,接下来根据每个插件的规则配置进行过滤,过滤后,只有Rewrite_URI和Dyups两个插件被选中。之后实例化这两个插件,在各个阶段对请求进行处理。请求被转发到后端服务时,URI就被rewrite为“/demo/test/hello”,upstream也被设置为“prod1-svc1”。请求由后端服务处理之后,响应会经网关返回给客户端,这就是整个插件的设计和工作的流程。为了优化性能,我们将插件的实例化延缓到了请求真正开始处理时,在此之前,网关会通过产品配置和规则,过滤掉不需要执行的插件。从图中也可以看出,每个插件的规则配置都很简单,并且没有统一的格式,这也确保了插件配置的简单灵活。

网关的配置均为热更新,通过Consul和Consul-Template来实现,配置在Consul上进行更新后,Consul-Template会将其实时地拉取下来,然后通过以下两种方式进行更新。

(1)通过调用Update API,将配置更新到shared-dict中。

(2)更新配置文件,利用Reload OpenResty实现配置文件的更新。

个推微服务网关提供的主要功能

1.动态路由

动态路由主要涉及到三个方面:服务注册、服务发现和请求转发。

如下图所示,服务的注册和发现是基于Kubernetes的Service和Kube-DNS实现的,在Consul中,会维持一个服务的映射表,应用的每一个微服务都对应Kubernetes上的一个Service,每创建一个Service都会在Consul上的服务映射表中添加一项(会被实时更新到网关的共享内存中)。网关每收到一个请求都会从服务映射表中查询到具体的后端服务(即Kubernetes中的Service名),并进行动态路由。Kube-DNS可以将Service的域名解析成Kubernetes内部的ClusterIP,而Service代理了多个Pod,会将流量均衡地转发到不同的Pod上。

2.流量控制

流量控制主要是通过一个名为“Counter”的后端服务和网关中的流控插件实现的。Counter负责存储请求的访问次数和限值,并且支持按时间维度进行计数。流控插件负责拦截流量,调用Counter的接口进行超限查询,如果Counter返回请求超限,网关就会直接拒绝访问,实现限次的功能,再结合时间维度就可以实现限频的需求。同时流控插件通过输出日志信息到fluent-bit,由fluent-bit聚合计次来更新Counter中的计数。

3.链路追踪

整个微服务体系的链路追踪是基于分布式的链路追踪系统Zipkin来实现的。通过在网关安装Zipkin插件和在后端服务中引入Zipkin中间件,实现最终的链路追踪功能。具体架构如下图所示。

4. A/B测试

在A/B测试的实现中,有以下几个关键点:

(1)所有的策略信息都配置在Consul上,并通过Consul-Template实时生效到各个微服务的内存中;

(2)每条策略均有指明,调用一个微服务时应调用A还是B(默认为A);

(3)网关中实现A/B插件,在请求到达网关时,通过A/B插件配置的规则,即可确定请求适用的A/B策略;

(4)网关会将请求适用的A/B策略通过URL参数传递下去;

(5)每个微服务通过传递下来的策略,选择正确的服务进行访问。

下图给出了两种场景下的调用链路。

总结

以上就是个推微服务网关的设计和主要功能的实现。之后,个推的技术团队会不断提升API网关的弹性设计,使其能够在故障出现时,缩小故障的影响范围;同时,我们也会继续将网关与DevOps平台做进一步地结合,以确保网关在迭代更新时,能够有更多的自动化测试来保证质量,实现更快速地部署。

原文地址:https://blog.51cto.com/13031991/2358568

时间: 2024-10-11 22:13:02

个推微服务网关架构实践的相关文章

我的那些年(13)~主推微服务架构

回到目录 我的那些年(13)~主推微服务架构 整个系统走向微服务架构 网关 服务注册与发现 配置中心 熔断器 链路跟踪 授权与鉴权 服务间的通讯-同步feign 服务间的通讯-异步消息 日志收集 个系统走向微服务架构 公司系统比较多,耦合度比较大,将这些模块进行拆分,各个负责自己的模块,减少相互之间的直接依赖,版本迭代互不影响,做到最小粒度的部署,这就是微服务,也是未来软件架构与设计的一个趋势! 典型的微服务架构图 graph TD client-->gateway gateway-->gat

从Uber微服务看最佳实践如何炼成?

导读:Uber成长非常迅速,工程师团队快速扩充,据说Uber有2000名工程师,8000个代码仓库,部署了1000多个微服务.微服务架构是Uber应对技术团队快速增长,功能快速上线很出色的解决方案.本文偏向微服务的入门篇,以Uber微服务为例,进行了深入浅出的讲解. 微服务特性 对于微服务没有适当的定义,你可以说它是一个框架,由小型的.独立的可部署的服务组成,执行不同的操作. 微服务专注于单个业务领域,可以作为完全独立的可部署服务,并在不同的技术栈上实现它们. 单体架构和微服务架构区别 在使用微

springCloud(13):使用Zuul构建微服务网关-简介

一.为什么要使用微服务网关 不同的微服务一般会有不同的网络地址,而外部客户端可能需要调用多个服务的接口才能完成一个业务需求.如:一个电影购票的手机APP,可能会调用多个微服务,才能完成一次购票的业务流程.如果让客户端直接与各个微服务通信,会有以下的问题: 1.客户端会多次请求不同的微服务,增加了客户端的复杂性: 2.存在跨域请求,在一定场景下处理相对复杂: 3.认证复杂,每个服务都需要独立认证: 4.难以重构,随着项目的迭代,可能需要重新划分微服务,如果客户端直接与微服务通信,那么重构将会很难实

Spring Cloud 微服务设计与实践

整理微服务设计与实践历程,共享给大家. 微服务的描述 The description of microserivce by Martin Fowler : 根据业务模块划分服务种类. 每个服务可以独立部署并且互相隔离. 通过轻量的 API 调用服务. 服务需要保证良好的高可用性. 微服务架构是以专注与单一责任的小功能模块为基础.通过 API 相互通信的方式完成复杂业务系统搭建的一种设计思想. 演变过程 单体架构(Monolithic) -> 垂直架构 -> SOA 架构 -> 微服务架构

微服务探索与实践—总述

背景 软件开发是一个不断发展的过程,从当初的面向过程为主到如今的面向对象的开发,软件开发者不断探索与实践更加符合时代发展要求的开发模式与架构思想,而这,也在极大程度上提高了软件开发的效率. 微服务是一种架构模式或者说是架构风格,而架构这个词语,相信有很多人都曾试图为它做出明确的定义,可是很难下,因为软件架构也在不断发展,内涵也在不断得到丰富.只是不变的是,我们需要通过软件架构,根据族组织.业务.技术等因素划分出不同的但可以相互协作的应用系统,使得设计出来的系统具有较高的伸缩性.可维护性以及可扩展

基于Spring cloud gateway定制的微服务网关

在构建微服务的架构体系过程中,API网关是一个非常重要的组件.那我们应该怎样实现一个微服务API网关,本文主要介绍Spring Cloud Gateway的功能,以及如何基于Spring Cloud Gateway定制自己的网关. Spring Cloud GatewaySpring Cloud Gateway提供的是一个用于在Spring MVC之上构建API网关的library,它的目标是提供一种简单而有效的方式路由API请求,它提供了一个切面,主要关注:安全.监控/metrics.弹性伸缩

Zuul微服务网关

Zuul简介: Zuul是Netflix开源的微服务网关,它可以和Eureka.Ribbon.Hystrix等组件配合使用.Zuul的核心是一系列的过滤器,这些过滤器可以完成以下功能 身份认证与安全:识别每个资源的验证要求,并拒绝那些与要求不符的请求 审查与监控:在边缘位置追踪有意义的数据和统计结果,从而带来精确的生产试图 动态路由:动态地将请求路由到不同的后端集群 压力测试:逐渐增加只想集群的流量,以了解性能 负载分配:为每一种负载类型分配对应容量,并弃用超出限定值的请求 静态响应处理:在边缘

微服务核心架构梳理

Hello,Microservices 什么是微服务 微服务Microservices之父,马丁.福勒,对微服务大概的概述如下: 就目前而言,对于微服务业界并没有一个统一的.标准的定义(While there is no precise definition of this architectural style ) . 但通在其常而言,微服务架构是一种架构模式或者说是一种架构风格,它提倡将单一应用程序划分成一组小的服务,每个服务运行独立的自己的进程中,服务之间互相协调.互相配合,为用户提供最终

Spring Cloud微服务安全实战_4-1_微服务网关安全_概述&微服务安全面临的挑战

  第四章  网关安全 这一章从简单的API的场景过渡到复杂的微服务的场景 4.1 概述 微服务安全面临的挑战:介绍中小企业的一个微服务架构,相比第三章的单体应用的简单的API所面临的哪些挑战 OAuth2协议与微服务安全:介绍OAuth2中的各个角色,以及相互之间的关系,介绍具体的代码实现 微服务网关安全:搭建网关,安全中心,两个微服务,怎么将安全从微服务中解耦出来放到网关上,与OAuth协议联系起来解决微服务安全面临的新的挑战. 4.2 微服务安全面临的挑战  更多的入口点,更高的安全风险