衣舞晨风
0%

多云高可用场景下云原生网关架构设计

发表于 更新于 分类于
本文字数： 6.2k 阅读时长 ≈ 6 分钟

如何借助云的能力，实现一个跨云高可用的网关？

背景分析

数字化转型下，企业上云已成必然。但业务规模扩大后，单一云厂商的风险逐渐暴露，因此我们设计云原生网关架构，始终以多云高可用为核心。

网关作为微服务的流量核心入口，还集成了流量管理、安全防护与全链路可观测能力。那该如何设计这一网关，才能充分发挥这些能力，真正实现多云高可用呢？

基于这一核心定位，我们可从集群适配、流量隔离等多个关键维度设计网关，以此充分激活其各项能力并筑牢多云场景下的高可用底座。

  • 集群适配：随云环境精准选择网关类型
    • 依托多云技术布局，网关采用 “集群类型对应” 的选型逻辑，确保网关与应用服务底层集群基础设施无缝衔接，避免跨云。
  • 实例专属绑定：集群级隔离，精细化流量治理
    • 每个集群独立部署专属网关实例，实现资源与流量严格隔离。
  • 统一界面：屏蔽底层细节降低使用门槛
    • 网关提供一体化可视化操作平台，将底层复杂技术完全封装，贴合 APP 快速迭代的业务需求。
  • 云原生高可用：99.95% SLA兜底，支撑千万级访问
    • 高可用性全权由云厂商保障，无需额外架构投入。
  • 插件化安全：简化认证降低业务复杂度
    • 登录、权限校验等通用安全逻辑以插件化形式预置于网关，完全剥离于 APP 业务代码，大幅降低开发成本

为什么一个K8S集群要部署一个网关？

  • 服务隔离与安全边界
    • 不同集群承载不同安全等级的业务，通过独立网关可实现网络层面的服务隔离，降低横向移动风险。
  • 流量就近处理
    • 在多云环境中，集群往往分布在不同地域或不同云厂商。为每个集群部署独立网关，可以实现流量的就近处理，减少跨地域、跨云厂商的网络延迟。
  • 故障隔离
    • 独立网关能有效隔离故障影响范围。如果一个集群的网关出现问题，不会影响其他集群的正常运行。
  • 部署灵活性
    • 为每个集群部署独立网关，可以根据集群的实际需求和业务特点，灵活配置网关参数和功能。

为什么选择直接对接云网关？

在确定了”每集群一网关”的架构模式后，我们又面临一个选择：是使用开源网关（如Kong、APISIX、Higress）自己部署，还是直接对接云厂商提供的网关服务？

经过对比分析，我们最终选择了直接对接云网关服务。而这一决策的核心依据，正是云网关服务自身具备的一系列契合我们需求的核心特性，具体体现在以下几个方面。

  • 高可用性保障
    • 云厂商的网关服务通常都经过了大规模的生产验证，可用性承诺一般在99.95%以上，还有专业的运维团队支持。
  • 运维成本降低
  • 功能丰富
  • 弹性扩展能力强
  • 与云原生生态集成
    • 云厂商的网关服务与其他云服务深度集成，可以更好地发挥云原生的优势，提高开发效率和系统弹性。

架构分层

云原生网关代码分层设计

这是一套多云网关统一管理架构，旨在实现跨云服务商的网关资源集中编排与适配，解决多云环境下网关管理分散、运维复杂度高的问题。以下从架构分层、组件职责和价值三个维度展开介绍：

架构分层与组件解析

该架构分为业务编排层、网关聚合层、适配端层三层，各层职责明确且解耦：

1. 业务编排层：业务逻辑的“指挥中心”

  • 用户角色：网关用户是操作主体，负责对逻辑网关和路由执行“增删改查”操作。
  • 核心组件：
    • 逻辑网关：抽象网关的逻辑定义，依赖SSL证书实现安全通信，是业务侧对网关的逻辑抽象。
    • 路由：与逻辑网关关联，依赖插件和服务实现流量转发规则；路由的审批流程通过MQ（消息队列）异步处理，保障流程可靠性。

2. 网关聚合层：多云指令的“转换器”

  • 承接业务编排层的操作指令，对域名执行“创建/删除”，对路由组执行“发布/下线（Publish/Unpublish）”。
  • 核心是CloudGatewayProvider（Adapter），作为“中间桥梁”，将业务层的统一指令转换为适配多云环境的操作格式，实现多云指令的标准化。

3. 适配端层：多云资源的“执行器”

  • 对接不同云服务商的网关服务，如阿里云-MSE、华为云-APIG、腾讯云-云原生网关等，实现多云网关的“一管多”。
    • 阿里云-MSE：管理域名、服务、路由、策略、插件等资源，是阿里云生态下的微服务网关载体。
    • 华为云-APIG：通过API组管理域名、响应等，是华为云的API网关服务入口。
    • 腾讯云-云原生网关：适配腾讯云的网关产品，支持云原生场景下的流量管理。

架构价值

  • 统一编排：业务侧通过“逻辑网关+路由”的模式，无需关注底层云差异，实现网关资源的集中化、标准化编排。
  • 多云适配：通过聚合层和适配层的解耦设计，轻松对接阿里云、华为云、腾讯云等多厂商，避免“一云一套管理逻辑”的重复建设。
  • 灵活扩展：插件、策略等组件支持自定义扩展，可根据业务需求灵活增强网关能力；适配端层的“…”节点也支持快速接入新的云服务商。

核心接口设计

抽象比具体更重要

在多云环境下，关键是要把不同云厂商API的差异藏起来，给业务层提供统一的网关管理能力。

核心接口

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
// CloudGateway 核心网关接口定义 - 包含域名、服务、路由的CRUD操作
// 产品的一步操作 对应云的多步操作
// 具体需要实现哪些接口,按需实现即可
type CloudGateway interface {
        // ----------------- 域名管理 -----------------

        // CreateDomain 域名管理--可重入
        CreateDomain(ctx context.Context, request *model.CreateDomainRequest) (*model.CreateDomainResponse, error)

        // GetDomain 查询域名
        GetDomain(ctx context.Context, request *model.GetDomainRequest) (*model.GetDomainResponse, error)

        // UpdateDomain 更新域名
        UpdateDomain(ctx context.Context, request *model.UpdateDomainRequest) (*model.UpdateDomainResponse, error)

        // DeleteDomain 删除域名
        DeleteDomain(ctx context.Context, request *model.DeleteDomainRequest) (*model.DeleteDomainResponse, error)

        // ListDomains 查询域名列表
        ListDomains(ctx context.Context, request *model.ListDomainRequest) (*model.ListDomainResponse, error)

        // ConflictCheckDomain 冲突检查域名
        ConflictCheckDomain(ctx context.Context, request *model.ConflictCheckDomainRequest) (*model.ConflictCheckDomainResponse, error)

        // ----------------- 服务管理 -----------------

        // CreateService 服务管理 --可重入
        CreateService(ctx context.Context, request *model.CreateServiceRequest) (*model.CreateServiceResponse, error)

        // GetService 查询服务
        GetService(ctx context.Context, request *model.GetServiceRequest) (*model.GetServiceResponse, error)

        // UpdateService 更新服务
        UpdateService(ctx context.Context, request *model.UpdateServiceRequest) (*model.UpdateServiceResponse, error)

        // DeleteService 删除服务
        DeleteService(ctx context.Context, request *model.DeleteServiceRequest) (*model.DeleteServiceResponse, error)

        // ListServices 查询服务列表
        ListServices(ctx context.Context, request *model.ListServiceRequest) (*model.ListServiceResponse, error)

        // ServiceConflictCheck 服务冲突检查
        ServiceConflictCheck(ctx context.Context, request *model.ConflictCheckServiceRequest) (*model.ConflictCheckServiceResponse, error)

        // CreateRoute ----------------- 路由管理 -----------------

        // CreateRoute 创建路由--可重入
        CreateRoute(ctx context.Context, request *model.CreateRouteRequest) (*model.CreateRouteResponse, error)

        // GetRoute 查询路由
        GetRoute(ctx context.Context, request *model.GetRouteRequest) (*model.GetRouteResponse, error)

        // UpdateRoute 更新路由
        UpdateRoute(ctx context.Context, request *model.UpdateRouteRequest) (*model.UpdateRouteResponse, error)

        // DeleteRoute 删除路由--可重入
        DeleteRoute(ctx context.Context, request *model.DeleteRouteRequest) (*model.DeleteRouteResponse, error)

        // ListRoutes 查询路由列表
        ListRoutes(ctx context.Context, request *model.ListRouteRequest) (*model.ListRouteResponse, error)

        // PatchRoute 部分更新路由
        PatchRoute(ctx context.Context, request *model.PatchRouteRequest) (*model.PatchRouteResponse, error)
}

// CloudClientManager 客户端管理接口 - 用于初始化和获取云SDK客户端
type CloudClientManager[T any] interface {
        // InitClient 初始化云SDK客户端
        InitClient(ctx context.Context, config *model.CloudClientInitConfig) error

        // GetClient 获取初始化好的客户端
        GetClient(ctx context.Context, config model.CloudClientGetConfig) (T, error)
}

// CloudGatewayProvider 综合接口，组合核心功能和客户端管理
type CloudGatewayProvider interface {
        CloudGateway
        GetCloudGatewayProviderType() model.CloudGatewayProvider
}

// NewGatewayProvider 工厂函数，用于创建特定云厂商的网关实例
func NewGatewayProvider(provider model.CloudProvider) (CloudGatewayProvider, error) {
        switch provider {
        case model.HuaweiCloud:
                return huawei_apig.NewHuaweiAPIGProvider(), nil
        case model.AliCloud:
                return ali_mse.NewAliMSEProvider(), nil
        default:
                return nil, &bizerrors.GatewayError{
                        Code:    "unsupported_provider",
                        Message: "不支持的云厂商",
                }
        }
}

设计思路

  • 统一抽象很重要：不同云厂商的网关API差异很大，有的关注”域名”，有的主打”服务”。通过CloudGateway接口，我们把这些差异都藏在适配层下面，让业务代码不用关心具体是哪家云厂商。
  • 工厂模式实用：用工厂模式创建不同云厂商的网关实例，后面要加新的云厂商时，直接加个case分支就行，不用改现有代码。实际落地时，这个设计帮我们省了不少对接新云平台的时间。
  • 客户端管理要封装：每个云厂商的SDK初始化方式都不一样，通过CloudClientManager接口，我们把这些复杂逻辑包起来，让代码更简洁，维护也更容易。
  • 幂等性很关键：我在接口中标注了”可重入”，这是从运维经验里总结的。分布式环境下网络不稳定，请求很容易重试。确保核心操作幂等，就能避免重复创建资源或状态混乱的问题。
  • 按需实现更灵活：接口虽然覆盖了完整生命周期，但我们允许具体实现”按需实现”。实际落地时，确实有些云厂商的某些功能不完善，这种设计让我们能灵活应对。
  • 错误处理要精细：专门定义了GatewayError类型，提供详细的错误码和信息。排查问题时，这个设计帮我们快速定位是哪个云厂商的哪个功能出了问题。

部署架构及高可用

云原生网关架构-应用层高可用

经验总结

  • 什么是架构？
    • 架构的基本需求主要是在满足功能属性的前提下，关注软件质量属性，架构设计则是为满足架构需求（质量属性）寻找适当的“战术”（即架构策略）。
    • 软件架构（及软件架构设计师）重点关注的是质量属性。因为在大量的可能结构中，可以使用不同的结构来实现同样的功能性，即功能性在很大程度上是独立于结构的，架构设计师面临着决策（对结构的选择），而功能性所关心的是它如何与其他质量属性进行交互，以及它如何限制其他质量属性。
  • 多为运维考虑
    • 设计架构不能只看开发方不方便，还要想长期怎么维护。我们选的方案让运维团队从底层维护中解放出来，能更专注于业务支撑。
  • 保持技术中立
    • 虽然用了云厂商服务，但通过抽象层保持中立，这样将来想换云厂商时，也能平滑迁移，不会被一家绑定死。
相关文章

欢迎关注我的其它发布渠道