写点什么

雪球基于 Apache APISIX 的双活架构演进

  • 2022-06-08
  • 本文字数:3368 字

    阅读完需:约 11 分钟

雪球基于Apache APISIX的双活架构演进

本文整理自雪球基础组件团队在 Apache APISIX Summit ASIA 2022 上的分享。更多技术干货,详见内容专题

背景


雪球成立于 2010 年,起步于投资社区,现已成为国内领先的集投资、交流和交易为一体的在线管理平台,为投资者提供优质内容、实时行情、交易工具、财富管理等多种服务。


其中实时行情服务对接了多种上游数据源,通过数据流式计算、存储与分发,为投资者提供稳定的数据服务。所以实时行情一直是雪球业务系统中的资源消耗大户,持续在高水位运行。雪球内部一项重要的工作就是持续进行稳定性建设,其中包括对行情服务进行性能优化。即便如此,在偶然发生极端行情的情况下,部分系统仍会因为数据量激增而发生响应变慢,甚至是不可用的情况,从而影响用户体验。


在此背景下,雪球为了向广大投资者提供稳定优质的服务,启动了服务双活改造计划。Apache APISIX 能极大地简化双活架构的实施复杂度。同时 APISIX 自身的云原生功能特性、丰富的社区生态和插件等,也为雪球未来云原生架构的演进打下了良好基础。本文将介绍雪球公司如何借助 Apache APISIX 实现内部双活架构的演进。



 上图是雪球单机房时期的简单架构描述,用户流量从云端入口(SLB)进来后,经网关进行简单的公共性逻辑处理,向后端服务转发。后端服务会通过 SDK 的方式,由集成在服务中的鉴权模块向雪球用户中心发起用户鉴权,通过后则继续进行后续的业务处理。

双活改造痛点


在实践业务场景中,该架构下一些痛点也开始逐渐显现。


  1. SDK 鉴权模块复杂

在双活改造实施过程中,微服务的提供方和消费方无法完全同步进行部署上线。当行情服务首先在云端上线,而雪球用户中心还不具备云端服务能力时,便会出现跨机房调用的情况。根据用户中心统计,其 RPC 调用量日均约数十亿,峰值可达到 50K QPS,在行情高的 QPS 场景下会带来较高延迟。


同时雪球鉴权业务复杂度较高,除 OAuth2.0 / JWT 协议外,还需要兼顾客户端版本、雪球旗下多个 APP 等多种因素。由于鉴权模块嵌入了服务内,导致升级也变得较为困难。


  1. OpenResty 功能性稍有不足


雪球在之前一直将 OpenResty 作为网关,其自身功能性上略有不足。所以将 OpenResty 集成雪球现有监控体系时,仍需要一定的工作量;同时扩展流程繁琐,还需要运维侧去添加自定义脚本进行实现。


  1. 依赖自研注册中心


目前雪球的 HTTP 服务注册是在后端服务启动时,请求注册中心将自身注册到网关,服务停止时请求注册中心进行服务节点摘除,注册中心会定期轮询服务节点进行健康检查。但自研的服务相比开源项目而言,维护成本较高。

API 网关选型


所以在这些痛点之上,雪球内部希望在不引入过多变量的同时,尽量保证对业务方透明以及最小化改动; 可以将问题在基础设施层面进行统一处理,并且尽量将鉴权服务在本机房完成。综上考虑,雪球决定将鉴权服务移至 API 网关进行完成。



基于在业务实践场景中逐渐显现的痛点,雪球基础设施团队开始了针对网关产品的调研。通过内部诉求和目前市场中网关产品的对比,最终选择了基于 Apache APISIX 进行后续架构的调整与使用。



基于 Apache APISIX 的实践

调整后架构



如上图是目前雪球行情双活架构。左侧展示的是在原机房里对应的架构,并没有进行太多改动;右侧展示的则是上云之后基于多 Region 设计的多活架构。


上述架构主要基于 APISIX 进行了如下调整:

  • 将鉴权模块统一调整到代理层,利用 APISIX 进行统一鉴权方式。其中涉及到 JWT 类型的可以直接利用 APISIX jwt-auth 插件进行本地鉴权;

  • 兼容 OAuth 2.0 形式,利用 APISIX 统一调用雪球用户中心进行处理;

  • 对接雪球后端 RPC 服务注册中心,用于 JWT 鉴权失败时使用雪球后端服务来鉴权。

应用场景展示


在后端服务接入 APISIX 后,主要在网关鉴权和可观测性等层面进行了一些实践。

场景一:网关鉴权


在前文中提到过,雪球之前架构模式中的鉴权方式并不统一。一种需要依赖于内部的应用端,通过 SDK 形式去调用用户中心实现鉴权,另一种则使用 JWT 鉴权。当两种鉴权方式共存时,会带来扩展性和维护性较差的问题。


接入 APISIX 作为网关之后,在鉴权方案的改造上则是通过 APISIX 网关层来统一管理。基于官方插件 jwt-auth 去替代原有的 JWT 鉴权方式;同时结合雪球内部自身的业务要求,使用 APISIX grpc-transcode 插件代理调用鉴权服务,来处理之前 OAuth 2.0 相关的鉴权方式。


jwt-auth 插件的配置使用较为简单,在 Dashboard 中将路由和上下游等相关信息配置齐全即可开启使用。这里主要描述下雪球内部是如何利用 APISIX 调用 gRPC 来实现鉴权。


在实现调用之前,雪球内部考虑了以下三种解决方案:

  • 方案一:Lua 直接调用 gRPC。由于此方案在执行中,需要去考虑负载均衡和动态上游等相关实现,过程会比较麻烦,故舍弃。

  • 方案二:Lua 协程回调 Golang。由于公司内部缺乏相应的实践经验,不可妄自尝试,故舍弃。

  • 方案三:Lua 进行 HTTP 调用,gRPC 接口采用 APISIX 的 grpc-transcode 插件进行实现。得益于 APISIX 社区对插件优化迭代快的前提,最终选择了方案三去实现 gRPC 调用。


在执行过程中,目前仍需要对 protocol buffers 文件进行手动同步。因为如果用户中心修改了该 protocol buffers 文件,但是与 APISIX 保存的 protocol buffers 文件不一致的话,会导致鉴权出现问题。

场景二:可观测性下的多维监控


雪球的日常使用场景中,通常在网站上线后是需要监控很多指标的,重点主要是以下三部分:

  • NGINX 连接状态和进出口流量

  • HTTP 错误状态码速率(用于排查 Service 或上下游问题)

  • APISIX 请求延迟耗时(APISIX 进行转发时逻辑执行带来的耗时)


比如 APISIX 的延迟指标会在某些情况下,出现指标非常高的现象(如下图所示),这种其实是跟该延迟指标的计算逻辑有关。目前 APISIX 延迟指标的计算逻辑是:单条 HTTP 请求在 NGINX 上的耗时时间-这条请求路由到上游的延迟。两个耗时之间的差数值即为 APISIX 延迟指标数据。



使用 APISIX 后,在新增或修改一些插件时会导致一些逻辑的变更,变更之后可能会导致耗时相关的数据出现偏差。为了避免出现混淆数据真实性的现象发生,雪球在监控层面还增加了基于插件级别的耗时监控。在保证各数据监测的准确性下,还方便了后续进行插件级的业务改造时,提前通过耗时定位一些问题,从而方便排查。



同时可以利用 APISIX 的可观测性能力,收集 Access 日志信息,并通过格式化统一投递到流量大盘中进行视图汇总。更方便地从多角度提前了解整体趋势,发现潜在问题并及时进行处理。



场景三:扩展 ZooKeeper 注册中心


目前,雪球 gRPC 服务调用是基于 Zookeeper 注册中心进行注册和发现。在实现鉴权过程中,API 网关在本地 JWT 校验失败时,需要访问雪球用户中心的 gRPC 服务进行鉴权,这就要求 API 网关能够从注册中心获取后端 gRPC 服务地址列表。APISIX 官方插件 apisix-seed 可以去集成 ZooKeeper 进行服务发现,但结合雪球自身使用场景需求,在 APISIX 上则是进行了更针对自家业务的相关拓展。


具体实现主要是在 APISIX 的一个内容节点上,当 Worker 进程启动时去轮询像下图中的 ZK-Rest 集群,然后定时去拉取整个服务的源数据信息以及实际信息,更新到 Worker 进程内的本地缓存,用于服务列表的更新。



通过上图也可以看到,ZK-Rest 集群相当于通过 Rest 的形式进行访问 ZooKeeper 的数据。所以整个过程其实实现的功能比较少(主要是基于自身业务场景需求),只需要增加它的一个实例就可以实现高可用特性,免去一些复杂操作。


但这样操作也会带来一个比较明显的缺点。当需要定时去轮询 ZK-Rest 集群时,可能会导致服务列表在更新上出现延迟。所以这里也是提供给大家一个思路,仅供参考。

总结及展望

目前,Apache APISIX 在雪球内部作为网关层运行良好。具体表现在:

  • 实现了在网关层统一鉴权、熔断与限流等功能;

  • 降低了整体系统的耦合度,提高了双机房场景下的服务质量;

  • 借助于 APISIX 监控体系,完善了从网关到服务的统一监控方案;

  • 对全链路排查起到了很好的支撑;

  • 对 gRPC 协议的转换与服务管理都提供了比较优雅的实现方式。


在后续的使用中,雪球也在规划如下进程:

  • 使用 APISIX Ingress Controller 应用于 K8s 集群;

  • 利用 grpc-transcode 插件进行 HTTP/gRPC 协议转换,达到后端统一接口形式;

  • 利用 traffic-spilt 插件进行流量打标、对接 Nacos 注册中心,实现全链路灰度等服务治理。


并在后续计划中,用 Apache APISIX 去替代现有的 OpenResty,最终实现全域南北流量的管理。

2022-06-08 10:153855

评论

发布
暂无评论
发现更多内容

一口气了解【2021 阿里云峰会】重磅发布

阿里云视频云

阿里云

IDEA使用

xujiangniao

Java IDEA

外包3年凭借一手“秒杀架构”成功上岸阿里

Java架构师迁哥

深入讲解RxJava响应式编程框架,背压问题的几种应对模式

小Q

Java 学习 编程 架构 面试

C语言从入门到精通(一)

代码情缘

c++ 编程 开发 C语言 硬件开发

怒肝最新保姆级前端学习路线,速成贴心全面!

程序员鱼皮

CSS JavaScript Vue 大前端 React

野生程序员高考试卷,试试你能打多少分?

北游学Java

程序员 高考

深入浅出负载均衡

vivo互联网技术

负载均衡 高可用 服务器 hash

阿里架构师手肛6个月,总结出17W字操作系统、网络教程(导图+笔记)

Java架构师迁哥

阿里开源三天就被狂转50w次的《Java面试突击》限时下载!

Java架构师迁哥

牛掰!阿里首席架构师用7部分讲明白了Java百亿级高并发系统(全彩版小册开源)

Java架构追梦

Java 学习 阿里巴巴 架构 百亿级并发架构设计

五层验证系统,带你预防区块链业务漏洞

华为云开发者联盟

区块链 智能合约 漏洞 可信 自免疫系统

去阿里/腾讯/字节面试P7Java岗时,需要掌握哪些技术栈?

Java架构师迁哥

a.docker

xujiangniao

Docker

用了这么多年 Gitlab,可能还不了解这些知识

郭旭东

DevOps gitlab 极狐GitLabs

架构解析|网易自研新一代大规模分布式传输网

网易云信

分布式 音视频

助力初创企业加速升级,华为云初创扶持计划微光训练营南京站开营仪式成功举办

科技热闻

阿里P9分享:基于JDK 8 源码剖析

Java架构师迁哥

拼搏26天刷完了阿里大佬的Java面试合集1000题,拿到了月薪30K的offer

Java 程序员 架构 面试

iOS APP 架构漫谈

iOSer

ios ios开发 iOS架构

来自Linux老学员的经验分享,新生必看!

学神来啦

Linux 运维 安全 虚拟机

流程即代码:低代码 & 云研发 IDE —— Uncode

Phodal

ide 云开发 云研发

EBean ORM 框架介绍-2.字段加密、更新日志和历史记录

Barry的异想世界

jpa Ebean 字段加密 更新日志 历史记录

新手模拟实现bind

前端树洞

面试 大前端 js this

计算机专业的应届生想进大厂做开发有多难?

Java架构师迁哥

质量基础设施(NQI)“一站式”服务平台开发搭建

源中瑞-龙先生

NQI 质量基础设施“一站式”

2021上半年1000道大厂高频面试题汇总(Java岗)

Java架构师迁哥

阿里分享:全网最详细的一篇SpringCloud总结

Java架构师迁哥

机器学习- 吴恩达Andrew Ng 编程作业技巧 -John 易筋 ARTS 打卡 Week 50

John(易筋)

ARTS 打卡计划

云钉一体应用创新:音视频如何带来灵活高效的协同体验

阿里云视频云

阿里云 音视频

10次面试9次被刷?吃透这500道大厂Java高频面试题后,怒斩offer

Java 程序员 架构 面试

雪球基于Apache APISIX的双活架构演进_架构_雪球基础组件团队_InfoQ精选文章