马蜂窝如何利用 APISIX 网关实现微服务架构升级

作者：董红帅，马蜂窝微服务体系建设以及基础服务能力建设专家。

马蜂窝作为旅行社交平台，是数据驱动的新型旅行电商。基于十余年的内容积累，马蜂窝通过 AI 技术与大数据算法，将个性化旅行信息与来自全球各地的旅游产品供应商实现连接，为用户提供与众不同的旅行体验。

随着业务的发展，马蜂窝架构也在跟随技术步伐进行更迭，开始基于 Kubernetes 进行更多的延展。在这个技术背景下，需要针对云服务开启新一轮的架构更新，比如：微服务场景建设新的蜂效平台及周边设施来支持迭代和流量泳道的能力，在多 Kubernetes 集群场景引入 Karmada 实现多集群管理，在微服务网关领域将 Istio + Envoy 的架构替换为 Apache APISIX 与 Envoy 共存的微服务网关模式。

微服务 1.0 模式现状

目前马蜂窝内部的微服务架构经历了两次迭代，本文中将针对原有架构的第一次调整定义为 1.0 版本。在进行微服务 1.0 架构的搭建之前，我们从发布系统能力、Kubernetes 容器、服务发现和微服务网关等角度进行了一些考量与目标对齐。比如 Kubernetes 的广泛应用，需要开始考虑基于容器做多语言支持，在 CI/CD 环节实现全面容器化，并支持多 Kubernetes 集群等。

在进行第一次迭代之前，内部架构的微服务网关使用的是 NGINX Ingress，但它其实是存在问题的。比如配置变更基于 NGINX reload，会造成业务有损；同时在应用范围内仅支持单 Kubernetes 集群，场景受限；内置资源过于简单，大量匹配规则依赖 Annotations，配置繁杂不友好，尤其是对外部服务发现能力支持很弱。

因此在进行微服务 1.0 迭代落地的过程中，为了满足一些业务需求，我们进行了如下动作（选取部分操作列举）：

• 在 Kubernetes 容器内，基于 macvlan 改造容器网络，IDC 机房网络与云厂商网络互通（容器互通的通信基础）；借助网关或容器直连实现服务互访，不再使用 Kubernetes Service。
• 基于 Kubernetes 容器场景部署；基于 Consul 物理机虚拟机部署。
• 增加统一服务发现能力，基于 Kubernetes、Consul 建设统一的发现中心 — Atlas；同时基于 Atlas 扩展微服务网关、Java 生态、监控体系等。
• 在微服务网关的选择上，基于 Istio + Envoy 架构进行构建。对 Istio 中 Pilot 进行二次开发，对接 Atlas 发现中心，由于 Atlas 数据来源于多套 Kubernetes 和 Consul，进而将实例发现与 Kubernetes 集群解耦，间接做到网关对接多 Kubernetes 集群的能力，实现整个网关动态感知识别的变化。

痛点梳理

在微服务 1.0 的这套架构中，实践下来还是存在一些痛点。