【服务网格架构】Envoy架构概览(7):断路,全局限速和TLS

简介: 【服务网格架构】Envoy架构概览(7):断路,全局限速和TLS

断路


断路是分布式系统的关键组成部分。快速失败并尽快收回下游施加压力几乎总是好的。Envoy网格的主要优点之一是,Envoy在网络级别强制实现断路限制,而不必独立配置和编写每个应用程序。Envoy支持各种类型的完全分布(不协调)的电路中断:


  • 群集最大连接数:Envoy将为上游群集中的所有主机建立的最大连接数。实际上,这仅适用于HTTP / 1.1群集,因为HTTP / 2使用到每个主机的单个连接。
  • 群集最大挂起请求数:在等待就绪连接池连接时将排队的最大请求数。实际上,这仅适用于HTTP / 1.1群集,因为HTTP / 2连接池不会排队请求。HTTP / 2请求立即复用。如果这个断路器溢出,集群的upstream_rq_pending_overflow计数器将增加。
  • 群集最大请求数:在任何给定时间,群集中所有主机可以处理的最大请求数。实际上,这适用于HTTP / 2群集,因为HTTP / 1.1群集由最大连接断路器控制。如果这个断路器溢出,集群的upstream_rq_pending_overflow计数器将增加。
  • 集群最大活动重试次数:在任何给定时间,集群中所有主机可以执行的最大重试次数。一般来说,我们建议积极进行断路重试,以便允许零星故障重试,但整体重试量不能爆炸并导致大规模级联故障。如果这个断路器溢出,集群的upstream_rq_retry_overflow计数器将递增。

每个断路极限可以按照每个上游集群和每个优先级进行配置和跟踪。这允许分布式系统的不同组件被独立地调整并且具有不同的限制。


请注意,在HTTP请求的情况下,断路将导致x-envoy-overloaded报头被路由器过滤器设置。


全局限速


尽管分布式电路断路在控制分布式系统中的吞吐量方面通常是非常有效的,但是有时并不是非常有效并且需要全局速率限制。最常见的情况是大量主机转发到少量主机,并且平均请求延迟较低(例如连接到数据库服务器的请求)。如果目标主机被备份,则下游主机将压倒上游集群。在这种情况下,要在每个下游主机上配置足够严格的电路中断限制是非常困难的,这样系统将在典型的请求模式期间正常运行,但仍然可以防止系统开始发生故障时的级联故障。全球限速是这种情况的一个很好的解决方案。


Envoy直接与全球gRPC限速服务集成。尽管可以使用任何实现定义的RPC / IDL协议的服务,但Lyft提供了一个使用Redis后端的Go编写的参考实现。特使的费率限制整合具有以下特点:


  • 网络级别限制过滤器:Envoy将为安装过滤器的侦听器上的每个新连接调用速率限制服务。配置指定一个特定的域和描述符设置为速率限制。这对速率限制每秒传送收听者的连接的最终效果。配置参考。
  • HTTP级别限制过滤器:Envoy将为安装过滤器的侦听器上的每个新请求调用速率限制服务,并且路由表指定应调用全局速率限制服务。对目标上游群集的所有请求以及从始发群集到目标群集的所有请求都可能受到速率限制。配置参考。


限速服务配置。


TLS


在与上游集群连接时,Envoy支持侦听器中的TLS终止以及TLS发起。对于特使来说,支持足以为现代Web服务执行标准的边缘代理职责,并启动与具有高级TLS要求(TLS1.2,SNI等)的外部服务的连接。Envoy支持以下TLS功能:

  • 可配置的密码:每个TLS监听者和客户端可以指定它支持的密码。
  • 客户端证书:除了服务器证书验证之外,上游/客户端连接还可以提供客户端证书。
  • 证书验证和固定:证书验证选项包括基本链验证,主题名称验证和哈希固定。
  • ALPN:TLS监听器支持ALPN。HTTP连接管理器使用这个信息(除了协议推断)来确定客户端是否正在讲HTTP / 1.1或HTTP / 2。
  • SNI:SNI当前支持客户端连接。听众的支持可能会在未来添加。
  • 会话恢复:服务器连接支持通过TLS会话票据恢复以前的会话(请参阅RFC 5077)。可以在热启动之间和并行Envoy实例之间执行恢复(通常在前端代理配置中有用)。


基础实施

目前Envoy被写入使用BoringSSL作为TLS提供者。


启用证书验证

除非验证上下文指定了一个或多个受信任的授权证书,否则上游和下游连接的证书验证都不会启用。


示例配置

static_resources:
  listeners:
  - name: listener_0
    address: { socket_address: { address: 127.0.0.1, port_value: 10000 } }
    filter_chains:
    - filters:
      - name: envoy.http_connection_manager
        # ...
      tls_context:
        common_tls_context:
          validation_context:
            trusted_ca:
              filename: /usr/local/my-client-ca.crt
  clusters:
  - name: some_service
    connect_timeout: 0.25s
    type: STATIC
    lb_policy: ROUND_ROBIN
    hosts: [{ socket_address: { address: 127.0.0.2, port_value: 1234 }}]
    tls_context:
      common_tls_context:
        validation_context:
          trusted_ca:
            filename: /etc/ssl/certs/ca-certificates.crt

/etc/ssl/certs/ca-certificates.crt是Debian系统上系统CA软件包的默认路径。这使得Envoy以与例如相同的方式验证127.0.0.2:1234的服务器身份。cURL在标准的Debian安装上执行。Linux和BSD上的系统CA捆绑包的通用路径是


/etc/ssl/certs/ca-certificates.crt (Debian/Ubuntu/Gentoo etc.)
/etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem (CentOS/RHEL 7)
/etc/pki/tls/certs/ca-bundle.crt (Fedora/RHEL 6)
/etc/ssl/ca-bundle.pem (OpenSUSE)
/usr/local/etc/ssl/cert.pem (FreeBSD)
/etc/ssl/cert.pem (OpenBSD)

有关其他TLS选项,请参阅UpstreamTlsContexts和DownstreamTlsContexts的参考。

认证过滤器

Envoy提供了一个网络过滤器,通过从REST VPN服务获取的主体执行TLS客户端身份验证。此过滤器将提供的客户端证书哈希与主体列表进行匹配,以确定是否允许连接。可选IP白名单也可以配置。该功能可用于为Web基础架构构建边缘代理VPN支持。


客户端TLS认证过滤器配置参考。

相关文章
|
2月前
|
缓存 Kubernetes 容灾
如何基于服务网格构建高可用架构
分享如何利用服务网格构建更强更全面的高可用架构
|
9月前
|
敏捷开发 运维 监控
探索微服务架构下的服务网格
【5月更文挑战第29天】 在现代软件开发的复杂多变环境中,微服务架构已成为构建分布式系统的热门选择。随着其应用的广泛化,服务网格(Service Mesh)这一概念应运而生并迅速崛起,它旨在提供一种透明且高效的方式来管理服务间的通信。本文将深入探讨服务网格的核心组件、运作机制以及如何通过服务网格优化微服务架构。我们还将讨论服务网格引入的挑战与克服这些挑战的策略,为采用微服务的企业提供指导和见解。
|
4月前
|
自然语言处理 监控 Cloud Native
探索微服务架构中的服务网格Service Mesh
【10月更文挑战第7天】服务网格(Service Mesh)是微服务架构中的关键组件,通过在每个服务实例旁部署Sidecar代理,实现服务间通信的管理、监控和安全增强。本文介绍了服务网格的基本概念、核心组件、优势及实施步骤,探讨了其在现代开发中的应用,并提供了实战技巧。
|
6月前
|
运维 负载均衡 监控
探索微服务架构下的服务网格(Service Mesh)实践之路
【8月更文挑战第30天】 在当今日益复杂的分布式系统中,微服务架构已成为众多企业解决系统扩展与维护难题的利器。然而,随着服务的不断增多和网络交互的复杂性提升,传统的微服务管理方式开始显得力不从心。服务网格(Service Mesh)作为一种新兴的解决方案,旨在通过提供应用层的网络基础设施来简化服务间通讯,并增强系统的可观察性和安全性。本文将分享我在采用服务网格技术过程中的经验与思考,探讨如何在现代云原生环境中有效地实施服务网格,以及它给开发和运维带来的变革。
|
7月前
|
存储 分布式计算 大数据
从零到一建设数据中台 - 架构概览
从零到一建设数据中台 - 架构概览
158 1
|
7月前
|
敏捷开发 运维 Cloud Native
云原生架构的演进之路:从容器化到服务网格
在数字化转型的浪潮中,云原生技术以其灵活性、可扩展性和弹性成为企业IT架构的新宠。本文将探讨云原生技术的演进路径,特别是容器化技术和服务网格的发展,以及它们如何共同推动现代应用的开发和部署。通过分析实际案例,我们揭示了云原生技术如何助力企业实现敏捷开发和高效运维,同时指出了未来云原生技术的发展趋势。
|
7月前
|
Kubernetes Cloud Native 持续交付
云原生架构的核心组成部分通常包括容器化(如Docker)、容器编排(如Kubernetes)、微服务架构、服务网格、持续集成/持续部署(CI/CD)、自动化运维(如Prometheus监控和Grafana可视化)等。
云原生架构的核心组成部分通常包括容器化(如Docker)、容器编排(如Kubernetes)、微服务架构、服务网格、持续集成/持续部署(CI/CD)、自动化运维(如Prometheus监控和Grafana可视化)等。
|
6月前
|
Cloud Native 安全 云计算
云原生技术的未来:探索服务网格和无服务器架构
随着企业数字化转型的深入,云计算已成为推动业务创新的核心力量。本文将深入探讨云原生技术的最新发展趋势,重点分析服务网格和无服务器架构如何重塑云计算的未来。通过实际案例和技术解析,揭示这些前沿技术如何解决现代应用部署的复杂性,提高系统的可伸缩性和弹性。文章旨在为读者提供云原生领域的深度见解,并激发对云技术未来发展的思考。
121 0
|
7月前
|
Kubernetes Cloud Native Docker
云原生架构的演进:从容器化到服务网格
本文深入探讨了云原生技术从最初的容器化技术,如Docker和Kubernetes,发展到现代的服务网格架构,如Istio。文章将通过分析云原生技术的演进路径,揭示其在处理微服务复杂性、流量管理和安全性方面的优势。我们将通过具体案例展示服务网格如何优化分布式系统的性能,并预测未来云原生技术的发展趋势。
63 2
|
7月前
|
敏捷开发 设计模式 运维
探索微服务架构中的服务网格
【7月更文挑战第30天】在现代软件工程中,微服务架构因其灵活性和可扩展性而备受推崇。然而,随着系统规模的扩大,服务之间的通信和管理变得日益复杂。服务网格作为解决这一问题的新兴技术,提供了一种透明、可靠的服务到服务通信方式。本文将深入探讨服务网格的核心概念、实现原理以及其在微服务架构中的应用实践,为读者呈现一个关于如何利用服务网格优化微服务间通信的全景视图。
56 0