背景介绍
某公司成立于2010年，最初是一个投资社区，现已发展成为国内领先的综合性在线管理平台，集投资、交流、交易于一体，向用户提供优质内容、实时行情、交易工具及财富管理服务。其核心的实时行情服务连接多个上游数据源，通过流式计算、存储和分发，保障数据稳定供应。由于行情数据量大且持续高负载，实时行情服务一直是系统资源消耗重点。极端行情时，系统可能因数据激增出现响应延迟甚至不可用，影响用户体验。
为提升服务稳定性和用户体验，某公司启动了服务双活（多活）架构改造计划。Apache APISIX作为云原生API网关，凭借丰富插件生态和强大动态路由能力，大幅简化双活架构实现复杂度，也为未来云原生架构升级奠定坚实基础。
原有架构及痛点
在单机房架构下，用户请求通过云端负载均衡（SLB）进入，经过网关进行基础公共逻辑处理后转发给后端服务。后端服务内嵌SDK鉴权模块，调用用户中心进行身份验证。该模式存在以下挑战：
- 鉴权模块复杂且耦合度高：鉴权逻辑包含OAuth2.0、JWT协议、多客户端兼容等复杂业务，嵌入服务内部，升级维护困难。
- 跨机房调用带来高延迟：双活改造初期，行情服务先上线云端，用户中心尚未云端化，导致跨机房RPC调用峰值高达5万QPS，延迟显著。
- OpenResty功能受限：原使用OpenResty作为网关，功能扩展和监控集成复杂，运维负担较重。
- 自研注册中心维护成本高：HTTP服务通过自研注册中心进行注册和健康检查，维护复杂且灵活性不足。
架构升级与APISIX应用（2025年最前沿方案）
1. 统一鉴权迁移至APISIX网关层
- 利用APISIX内置
jwt-auth插件实现本地JWT鉴权，简化鉴权流程。 - 通过
grpc-transcode插件代理调用用户中心的OAuth 2.0鉴权服务，实现HTTP与gRPC协议无缝转换。 - 当JWT鉴权失败时，APISIX可调用后端RPC服务补充鉴权，确保安全性和兼容性。
- 引入自动化协议管理工具，结合API设计平台，自动同步Protocol Buffers文件，避免版本不一致风险。
2. 服务注册与发现升级
- 采用etcd替代ZooKeeper作为注册中心，提升分布式配置和服务注册的高可用性与一致性，简化运维。
- APISIX通过etcd动态获取服务列表，实现实时更新和负载均衡，降低鉴权服务调用延迟。
3. 云原生环境下APISIX部署
- 在Kubernetes集群中部署APISIX Ingress Controller，利用K8s弹性伸缩和自愈能力，实现高效流量管理和资源利用。
- 结合硬件加速（TLS卸载、GZip压缩硬件加速）提升HTTPS性能，降低CPU消耗。
- 采用WASM插件扩展机制，实现灵活安全策略和自定义功能，增强系统安全性和扩展性。
4. 服务网格与API网关融合
- 引入Istio服务网格，与APISIX网关协同工作，实现微服务间细粒度流量管理、故障注入、流量镜像和灰度发布。
- 服务网格提供自动化安全策略和全链路可观测，提升系统弹性和安全保障。
5. 会话共享与状态管理
- 采用分布式缓存（Redis集群）和分布式会话管理方案，实现跨机房会话同步，保障双活环境下用户体验一致性。
- 利用消息队列（Kafka）实现异步数据同步和事件驱动架构，提升系统解耦和扩展能力。
6. 监控与可观测性
- 监控指标覆盖NGINX连接状态、流量、HTTP错误率、APISIX请求延迟及插件级耗时。
- 统一采集访问日志，格式化后汇总至流量大盘，实现多维度趋势分析和异常预警。
- 结合服务网格的分布式追踪（Jaeger、Zipkin），实现全链路性能监控和故障定位。
7. 多活架构与异地灾备
- 在同城双活基础上，逐步建设两地三中心架构，实现异地灾备，保障极端灾难情况下业务连续性。
- 采用秒级RTO/RPO的数据库多活同步技术，确保数据一致性和快速切换。
总结
某公司通过引入Apache APISIX，结合云原生服务网格、etcd注册中心、自动化API管理和分布式会话管理，构建了高弹性、高性能、易运维的双活架构。APISIX强大的插件生态和协议支持能力，配合Kubernetes和服务网格，实现了统一鉴权、流量治理和全链路可观测，极大提升了系统稳定性和用户体验。未来，随着异地多活和智能流量调度的推进，该架构将持续保持行业领先水平。
