如何发挥网关最大价值?业务网关建设之路

76 阅读9分钟

流量网关

流量网关是一种网络设备,用于监控和控制网络流量,对流量进行分析、优化、限制和管理,以提高网络性能、安全性和可靠性。

  • 常见的流量网关包括但不限于以下功能:
    • 流量控制:限制特定应用程序或用户的流量,避免网络拥塞和带宽滥用。
    • 流量过滤:根据规则过滤特定类型的流量,如垃圾邮件、恶意软件和非法内容等。
    • 流量优化:通过压缩、缓存和负载均衡等技术优化网络流量,提高网络性能和响应速度。
    • 流量分析:收集和分析网络流量数据,提供实时的流量监控和分析报告,帮助管理员识别网络瓶颈和安全问题。
    • 流量管理:管理不同应用程序和用户的流量,优先级和带宽分配,确保网络资源的公平共享和合理利用。
  • 常见的流量网关包括但不限于以下几种:
    • 代理服务器:用于代理客户端与目标服务器间的通信,可以缓存和过滤流量。
    • 负载均衡器:用于将流量分配到多个服务器上,以提高系统的可用性和性能。
    • 防火墙:用于保护网络免受攻击和恶意流量的侵害。
    • VPN 网关:用于连接不同地理位置的网络,提供加密隧道和安全访问控制。
    • WAN 加速器:用于优化宽带连接的性能,减少延迟和带宽使用。
    • 内容筛选器:用于过滤和控制访问特定类型的内容和协议。

流量网关可以采用硬件、软件或虚拟化的形式,可以部署在边缘网关、数据中心和云环境中,提供全面的网络流量管理和优化解决方案。

业务网关

业务网关是一种网络设备或软件,它在企业内部网络和公网之间充当连接点和安全缓冲区,负责管理和协调不同系统之间的信息交换。业务网关可以实现业务逻辑的封装、信息的转换和路由等功能,提高业务处理效率和灵活性。

  • ​实现了多种功能,包括:
    • 访问控制:业务网关可以控制外部用户访问企业内部网络的权限,限制他们可以访问的资源和服务。它还可以检测和阻止恶意流量和攻击,提高网络的安全性。
    • 流量管理:业务网关可以管理网络流量,包括优化带宽使用、负载均衡、流量调度和QoS(服务质量)控制等功能。
    • 协议转换:业务网关可以将不同的协议转换为企业内部网络所支持的协议,以便外部用户可以访问内部资源。
    • 数据加密:业务网关可以加密网络流量,保护敏感数据在传输过程中的机密性和完整性。
    • 应用代理:业务网关可以代理企业内部应用程序的访问,提供更好的性能和安全性,同时可以根据用户需要进行定制和扩展。
  • 常见的业务网关种类
    • API网关:API网关是一种处理API调用的服务器,位于服务提供者和消费者之间。它负责路由请求、组合API、数据转换、安全性、速率限制和API版本管理等。
    • B2B网关:业务对业务(Business-to-Business, B2B)网关用于在不同的业务伙伴之间交换信息。它处理各种类型的文件和消息格式,并提供安全和验证服务。
    • 集成网关:集成网关用于连接企业内部的异构系统,实现数据和信息的流动。它通常包含数据转换和路由功能,并可能支持各种类型的集成模式,例如服务导向架构(SOA)和事件驱动架构(EDA)。
    • 鉴权网关:鉴权网关用于在系统和服务之间提供安全控制,包括身份验证、授权、审计和账户管理。

总之,业务网关是企业网络的重要组成部分,它可以提高网络的安全性、性能和可靠性,帮助企业满足业务需求。

二者对比

对比维度功能场景技术部署总结
流量网关流量网关主要用于路由和管理网络流量,例如负载均衡、流量控制、安全认证、监控等流量网关适用于需要大量数据传输和处理的场景,例如数据中心、大型企业网络等。流量网关更多地侧重于网络技术,如TCP/IP、HTTP、SSL等。流量网关通常以独立的微服务形式部署在系统的边缘节点,例如容器、云服务器等流量网关主要关注网络流量和数据的管理,包括流量控制、负载均衡和网络安全等。
业务网关业务网关主要用于对接和管理业务系统,例如业务流程管理、数据转换、接口聚合、业务逻辑封装、数据缓存等。业务网关适用于需要整合多个系统和业务流程的场景,例如多渠道业务、电子商务平台、供应链管理等。业务网关更多地侧重于应用层技术,如API、SOAP、XML、JSON等。业务网关通常集成在应用服务器或者中间件中,例如Tomcat、WebLogic等。业务网关主要关注业务级别的流程、应用程序的集成,它在系统之间充当通信和转换的角色。

网关选型

  • 详见《云原生架构下的微服务网关剖析》,最终的选型确定为以Envoy为技术底座的轻舟云原生网关。
  • 其他原因
  • 灰度环境建设作为我们稳定性保障重要的专项,以Envoy为技术底座的多协议代理是核心,例如Dubbo、Redis、MySql,虽然部分协议代理还在试验阶段,但其上限之高,覆盖了整个微服务体系流量的代理。

落地挑战

由于业务中心的建设一直以来都是使用Nginx作为反向代理、负载均衡器,没有引入过微服务网关,导致一些通用的横向能力散落在各个业务线,例如认证、鉴权、限流、降级、等治理能力。不仅如此,受限于缺少技术栈的统一、各个业务线的实现方式也是“五花八门”。这种非标准的业务形态和杂乱的技术底座为我们的云原生网关的落地带来了种种挑战,例如统一的认证鉴权、标准的Header维度的业务拓展信息获取等。不仅如此,未来微服务治理方案引入服务网格也是大势所趋。在面对这些技术潮流时,是时候审视现状,诸如,如何更好的、充分的利用云原生网关的价值成为了一个新的挑战。

双向奔赴

业务侧

  • 业务标准化 - 内部技术栈、治理方法,比如限流、鉴权这些能力先统一
  • 业务聚焦 - 剥离非业务层面的服务治理内容

网关侧

  • 拓展插件 - 依托Envoy网关插件拓展框架,结合自身的业务开发横向统一能力插件包。

目标设定

  • 全局治理 - 使用轻舟云原生网关标准能力治理
    • Path、Query 级别的限流、降级、熔断、缓存、IP黑白名单
    • Header 级别无法使用,目前业务请求中未使用Header
    • 业务拓展 - 基于Rider插件的业务拓展
    • 请求参数校验
    • 签名校验
    • 业务维度的限流
    • Session/Cookie优化
    • 业务Lua SDK生态建设
  • 灰度建设
    • 入口流量染色
    • 非Http协议的流量代理
    • 基于Envoy的精细化路由、隔离环境建设,包括Dubbo/Redis/Kafka/Mysql代理与流量治理
  • 业务能力标准化
    • 业务瘦身 - 专注业务层面开发,剥离服务治理、安全层面的内容
    • 横向能力梳理 - 内部业务的实现、技术栈

业务拓展

  • 签名校验设计与实现
    • 现状 - 各个业务使用切面、代码实现
    • 方案 - 网关签名校验插件
  • 基于RedisCache
  • 业务维度的精细化限流
    • 以ProductId/TargetId为限流单位的精细化流量治理
    • Session/Cookie优化

​灰度建设

  • 入口流量染色 + Service Mesh + Envoy多协议路由
    • Envoy多协议路由
    • Kafka 路由
static_resources:
  listeners:
    - name: listener_0
      address:
        socket_address: { address: 0.0.0.0, port_value: 9092 }
      filter_chains:
        - filters:
            - name: envoy.filters.network.kafka_broker
              typed_config:
                "@type": type.googleapis.com/envoy.config.filter.network.kafka_broker.v2alpha1.KafkaBroker
                stat_prefix: kafka_stats
                route:
                  cluster: kafka_cluster
                  topic: my-kafka-topic
                  partition: 0
                  broker:
                    address: kafka-broker-1.example.com
                    port: 9092
  clusters:
    - name: kafka_cluster
      connect_timeout: 0.25s
      type: strict_dns
      lb_policy: round_robin
      dns_lookup_family: V4_ONLY
      hosts:
        - socket_address:
            address: kafka-broker-1.example.com
            port_value: 9092
        - socket_address:
            address: kafka-broker-2.example.com
            port_value: 9092
  admin:
    access_log_path: "/dev/null"
    address:
      socket_address: { address: 0.0.0.0, port_value: 9901 }
  • Mysql路由
static_resources:
  clusters:
  - name: mysql_cluster
    type: STATIC
    connect_timeout: 0.25s
    lb_policy: CLUSTER_PROVIDED
    lb_subset_config:
      fallback_policy: ANY_ENDPOINT
      subset_selectors:
        - keys:
            - <mysql_cluster_key>
    load_assignment:
      cluster_name: mysql_cluster
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: <mysql_host1>
                port_value: <mysql_port1>
          metadata:
            filter_metadata:
              envoy.lb:
                <mysql_cluster_key>: <mysql_cluster_key_value_1>
        - endpoint:
            address:
              socket_address:
                address: <mysql_host2>
                port_value: <mysql_port2>
          metadata:
            filter_metadata:
              envoy.lb:
                <mysql_cluster_key>: <mysql_cluster_key_value_2>
    typed_extension_protocol_options:
      envoy.extensions.upstreams.mysql.v3.MySQLCluster:
        detect_statement:
          patterns:
            - match_pattern: "^SELECT"
        load_balancing_policy:
          consistent_hashing:
            ring_hash:
              minimum_ring_size: 125
              deprecated_v1:
                hash_seed: "<mysql_hash_seed>"
  listeners:
  - name: mysql_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 3306
    filter_chains:
    - filters:
      - name: envoy.filters.network.mysql_proxy
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.mysql_proxy.v3.MySQLProxy
          stat_prefix: mysql
          auth:
            mysql_clear_password:
              username: <mysql_username>
              password: <mysql_password>
          cluster: mysql_cluster                 
  • Redis 路由
static_resources:
  clusters:
  - name: redis_cluster_1
    type: STATIC
    connect_timeout: 0.25s
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: redis_cluster_1
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: <redis_host_1>
                port_value: <redis_port_1>
  - name: redis_cluster_2
    type: STATIC
    connect_timeout: 0.25s
    lb_policy: ROUND_ROBIN
    load_assignment:
      cluster_name: redis_cluster_2
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: <redis_host_2>
                port_value: <redis_port_2>
  listeners:
  - name: redis_listener
    address:
      socket_address:
        address: 0.0.0.0
        port_value: 6379
    filter_chains:
    - filters:
      - name: envoy.filters.network.redis_proxy
        typed_config:
          "@type": type.googleapis.com/envoy.extensions.filters.network.redis_proxy.v3.RedisProxy
          settings:
            op_timeout_ms: 5000
            prefix_routes:
              - prefix: "cluster1:"
                cluster_name: redis_cluster_1
              - prefix: "cluster2:"
                cluster_name: redis_cluster_2
  // Redis requests with a key prefix of "cluster1:" will be routed to the "redis_cluster_1" cluster, and requests with a key prefix of "cluster2:" will be routed to the "redis_cluster_2" cluster.

业务建设