讲师:袁鹏,一页科技架构师
摘要: 君润人力采用多套 Apache APISIX 集群来满足自研服务平台的功能需求。
君润人力成立于 2019 年,是一家以科技驱动的人力资源解决方案服务商,依托行业领先的科技水平和服务能力,专注于为客户提供一站式人力资源服务。自研数十家人力资源服务平台,深度链接 B 端企业和 C 端用户,构建数字化人力资源服务生态。
本文从君润人力业务快速扩张的背景入手,重点介绍开源 API 网关 Apache APISIX 对其自研平台系统架构的多样化应用场景支持,共有四大线上实战案例,希望对仍在网关选型过程中的企业或用户有所帮助。
君润人力在搭建自研服务平台架构时,首要原则就是**“开放、开源、拥抱云原生”**。平台基于 Kubernetes 微服务架构构建云端系统,整体架构参考下图。
右侧是君润自研服务平台,DevOps 流程依托 Git webhook、coding、Kubernetes 集群实现全自动化与无感发布,业务系统基于 PaaS 平台进行迭代开发,确保研发规范,并达成技术栈的统一。上侧是监控手段,系统集成了 sky-agent 和 arthas,满足了线上服务观测多维度的需求。与此同时,采用腾讯日志云与 Kubernetes 结合的方式将服务日志存储在云上,实现 Kubernetes 集群内无文件化服务,避免磁盘容量堆积从而影响到 Kubernetes 集群单个节点的健康。
左侧是业务系统中最重要的环节 —— 流量管理。所有流量会通过 WAF(WAF,Web 应用防火墙,负责网络安全)进入三层网络里面的第一层 CLB,主要负责流量转发;第二层就是云原生网关 APISIX,它承担了业务系统的内部服务治理;第三层则是业务系统的 Gateway 应用内部的网关,负责单系统鉴权和路由。
其中第一层的 CLB 和第二层的 APISIX 尤其重要,它是所有系统的入口,一旦出现问题,那么所有系统将无法被访问。CLB 采用的是腾讯云服务,稳定性、扩展性与抗并发性能都比较高,业务架构需要解决的是第二层云原生网关 APISIX,保证它的高可用。
APISIX-Service 被部署在 Kubernetes 集群内部,Kubernetes 集群采用的是腾讯云提供的服务,为了保证出现问题后能够快速恢复,系统外置了 etcd 集群,使数据得以保留,这是 APISIX 集群高可用的体现。
那么,如何来保证 APISIX 的高并发和高性能?这里系统利用了 Kubernetes 的机制,当 APISIX 进行路由转发时,通过 Kubernetes 的服务名 + 服务端口使它在同一个网段内跳转;因为网关服务部署在 Kubernetes 内部,依托于 Kubernetes 的特性,可以进行滚动升级,进而达到 APISIX 网关升级的无感发布。
通过该架构图不难发现,第二层是所有流量的入口,选择一个满足业务扩张需求的云原生网关,对系统架构来说至关重要,下面谈谈在网关技术选型时的主要思考。
ext-plugin
来支持 Java 开发,技术栈问题迎刃而解。此外 APISIX 的生态非常好,作为国产网关产品,社区极其活跃,业内实践还特别多,在云原生网关这层来说,业内也是顶级存在。我们的团队非常开放,做完技术选型后,快速实践落地。从上线部署到服务分批次接入,耗时不到 1 个月时间。目前 99% 的服务通过 APISIX 访问,上线一年多至今零事故,稳定性非常好。下面这张图里,大家能看到 APISIX 的一些特性,红字部分是我们最看重的几点。
下面我们来逐一介绍 APISIX 的四个实践场景。
Apache APISIX 基于 Radixtree 和 etcd 提供路由极速匹配与配置快速同步的能力。路由和插件的设计实现都满足了极速性能和超低延迟的需求。比如以下两个场景中,都表现出了不错的性能:
下图是君润人力 2022 年度路由增长趋势图。可以看到,不论前端还是后端路由,在引入 APISIX 之后,都实现了三倍或以上的数量增长。
我们基于 APISIX 做了双层网关架构,在 APISIX 上隔离出一个逻辑网关,用户访问 CLB 进来 APISIX 再转发到业务系统。如果用户使用的这个功能需要用到 PaaS,就会通过 PaaS 服务网关进行访问,此时的 PaaS 服务网关就是一个逻辑网关。
我们在 Kubernetes 内部封闭了一个区域,即 PaaS 平台,里面包含大量的基础服务。利用 APISIX 网关的特性:熔断、安全、身份识别,使上层业务系统访问 PaaS 服务都需要通过 PaaS 网关。
由于业务系统数量较多, 核心服务(SSO、PaaS 服务和发薪服务)可用性要求高, 这些服务的流量管控需要依赖 APISIX 提供的流量管理灰度策略。
为此,系统内部采用了两种方式进行。一是基于标签灰度。核心服务上到生产环境之前,测试人员先在灰度环境验证。我们会将测试用户流量转发到灰度服务,进行生产环境验证,验证通过后再基于权重切入流量,观察一段时间,没问题后再把全部流量切换到新版本;二是生产环境内。相同的服务并存多个版本,不同的业务系统访问不同的版本时,基于标签进行路由转发。
从下图的架构模式可以看出,APISIX 和 Pod 服务都基于 Kubernetes 架构,所有后端路由都被绑定在同一服务上,在 APISIX 服务上配置的 Kafka 插件用来采集日志数据,同时配置了 Skywalking 监控程序性能。根据 RequestId 和 TraceId 在 Skywalking 和日志云,可以观测到整个调用链路,并查看每个环节的日志记录和 API 请求耗时。
从目前观测到的数据来看,系统每天都有上千万次的 API 请求,平均每天产生的日志数据达到 30G ,日志总量达到 TB 级。
在使用 APISIX 的过程中,我们总结了一些经验之谈,在这里分享给对 APISIX 感兴趣的朋友们。
构建基础镜像需要拉取国外资源。 APISIX 需要部署在 Kubernetes 内部,内部会进行一定的二次开发和源码编译,这时需要到 GitHub 上拉取资源,目前官方提供的 Docker 镜像有一部分需要拉取国外资源,在进行本地开发和线上部署时,环境调试相对麻烦。
调试环境部署有要求。 自定义插件 java-plugin-runner
,需要基于 runner.sock 进行 RPC 通讯,现有案例较少,调试起来有一定困难,它需要和 APISIX-Service 在同一个镜像内。
**每天产生大量的日志记录到本地。**刚刚发布生产时,我们发现就算只开启 error 级别日志,每天的增长数量都非常大,导致 Kubernetes 集群中一个节点磁盘告警。后面打包镜像时将日志由文件记录改变为输出至控制台,收集至云日志服务 CLS 存储记录分析,实现本地无文件化存储。
当然,以上都属于前期准备工作上的必经之路,在正式投入使用后,APISIX 给我们带来的收益远远大于期望,总体有以下三点:
总结下来,使用 APISIX 云原生网关给君润人力服务平台带来了非常大的帮助,使我们能轻松应对多样化的复杂场景,打造趋于完美的数字化人力资源服务生态。
本文由博客一文多发平台 OpenWrite 发布!