 与 TCP 负载均衡架构)
后端API网关微服务【免费下载链接】fabioConsul Load-Balancing made simple项目地址https://gitcode.com/gh_mirrors/fa/fabio点击查看免费下载fabio 的核心部署定位是将来自互联网的 HTTP(S) 与 TCP 请求分发到能够处理这些请求的前端FE服务再由前端服务借助 Consul 的服务发现能力找到所需的后端BE服务。本文基于 fabio 官方部署文档docs/content/deploy/_index.md及其四个部署场景子页完整讲解 Direct、现有网关之后、Amazon ELB/NLB、Amazon API Gateway 四种部署拓扑并结合仓库源码监听器实现、PROXY protocol 处理、配置解析补充底层原理与可落地的配置示例。读完本文你将掌握 fabio 的监听器配置语法proxy.addr、PROXY protocol 的启用方式以及在不同云网关场景下如何安全、高可用地接入 fabio。fabio 的部署定位互联网入口 → 前端服务官方部署文档首先明确了 fabio 的主要使用场景分发来自互联网的 HTTP(S) 和 TCP 请求到前端FE服务。在这个场景中FE 服务再利用 Consul 的服务发现功能去查找它们处理请求所需的后端BE服务形成一条完整的链路internet -- HTTP/HTTPS/TCP -- fabio -- FE 服务 -- (Consul 服务发现) -- BE 服务文档同时给出了一个重要的边界说明fabio 目前并不作为 FE-BE 或 BE-BE 路由器来在服务之间转发流量因为 Consul 的服务发现机制已经解决了服务间的寻址问题。不过从架构上讲没有任何机制阻止 fabio 被这样使用只是项目当前没有这样做。这意味着你在规划部署时应将 fabio 视为面向公网的南北向流量入口而不是服务网格内部的业务路由层。从仓库的监听器实现可以印证这一定位proxy/listen.go 中的ListenTCP负责解析监听地址net.ResolveTCPAddr、开启 TCP KeepAlive、按需叠加 PROXY protocol 支持与 TLS 封装最终返回一个统一的tcpListener。所有入口流量最终都汇聚到这一套监听器抽象上再由路由表registry从 Consul 同步而来完成分发。监听器配置基础proxy.addr语法无论采用哪种部署拓扑fabio 的入口行为都由proxy.addr配置项驱动。完整的参数说明见 docs/content/ref/proxy.addr.md其语法为[host]:port;optarg;opt[arg];...即每个监听器由一个地址和一组可选的optarg选项组成多个监听器用逗号分隔。每个监听器通过proto选项指定协议受支持的协议包括协议用途httpHTTP 协议httpsHTTPS 协议grpc/grpcsgRPC 及 gRPCTLStcp原始 TCP 代理可选 TLStcpsni基于 SNI 的 TCP 代理解析 ClientHello 中的服务器名扩展不解密即转发tcp-dynamic由 Consul 驱动的 TCP 代理httpstcpsniSNI 感知 TCP 代理带 HTTPS 回退prometheusPrometheus 指标端点配合 metrics.targetprometheus使用若未显式指定proto协议将根据是否通过cs选项配置了证书源自动判定为http或https。常用通用选项包括rt/wt/it读、写、空闲超时如3sstrictmatchtrue证书源必须提供与连接主机名匹配的证书否则使用第一张证书与 Go TLS 服务器默认行为一致pxyprototrue监听器尊重上游发送的 PROXY protocol v1/v2 头pxytimeoutPROXY 协议头读取超时启用pxyproto时默认 250msrefreshtcp-dynamic模式下检查路由表更新的刷新间隔TLS 相关选项为tlsmin、tlsmax取值为ssl30/tls10/tls11/tls12或 Gocrypto/tls常量对应数字与tlsciphers引号包裹、逗号分隔的十六进制或常量名列表如0xc00a,0xc02b。几个可直接使用的示例# 单 HTTP 监听器默认值 proxy.addr :9999 # IPv4 监听 读超时 proxy.addr 1.2.3.4:9999;rt3s # 多个监听器不同协议 proxy.addr 172.16.20.11:80;protohttp;rt60s;wt30s, \ 172.16.20.11:443;protohttps;rt60s;wt30s;csall;tlsmin10, \ 172.16.20.11:8443;prototcpsni # HTTPS 监听 证书源 TLS 版本/密码套件约束 proxy.addr :443;cssome-name;tlsmintls10;tlsmaxtls11;tlsciphers0xc00a,0xc02b # Consul 驱动的动态 TCP 代理5 秒刷新 proxy.addr 0.0.0.0:0;prototcp-dynamic;refresh5s从源码看config包中Listen结构体 的字段ProxyProto bool、ProxyHeaderTimeout、TLSCiphers、StrictMatch、各类超时与上述选项一一对应proxy/listen.go中的ListenTCP正是将这些字段落实为实际网络行为的地方。部署模式一Direct——fabio 直接监听公网 IP最简单的拓扑见 docs/content/deploy/direct.mdfabio 直接监听公网 IP可选地为一个或多个域名终止 SSL——一个 IP 对应一个域名。终止 SSL 后fabio 通过明文 HTTP 将请求转发给内部的前端服务-- service-a | internet -- HTTP/HTTPS -- fabio -- HTTP ---- service-b | -- service-c对应的监听器配置示例HTTPS 入口 证书源proxy.addr 1.2.3.4:443;protohttps;csall;rt60s;wt30s这里的cs指向证书源配置proxy.cs证书可以来自文件、目录、HTTP 服务器、Consul KV 或 Vault详细配置见 docs/content/feature/certificate-stores.md。Direct 模式的高可用与带宽扩展文档给出的扩展方式是将 fabio 与前端服务一起部署同机部署从而同时获得高可用性和网络带宽的分布效果- HTTP/HTTPS - fabio -- HTTP - service-a (host-a) | | internet --- HTTP/HTTPS - fabio -- HTTP - service-b (host-b) | | - HTTP/HTTPS - fabio -- HTTP - service-c (host-c)每一台主机host-a/b/c上同时运行 fabio 实例与对应的前端服务多份 fabio 实例共同承接公网流量任一主机故障时其余实例继续服务。这是理解后续所有横向扩展论述的基础模式。部署模式二Behind Existing Gateway——位于现有网关之后当公司/云环境已存在负责终止 SSL 的网关或负载均衡器时见 docs/content/deploy/existing-lb.mdfabio 不需要再处理 HTTPS 证书只需接收网关转发的明文 HTTP-- service-a | internet -- HTTP/HTTPS -- LB -- HTTP -- fabio -- HTTP ---- service-b | -- service-c此时监听器配置退化为纯 HTTPproxy.addr :9999;protohttp同样可以按与前端服务同机部署的方式横向扩展 fabio 实例实现高可用与带宽分布- HTTP - fabio -- service-a (host-a) | | internet -- HTTP/HTTPS -- LB -- HTTP - fabio -- service-b (host-b) | | - HTTP - fabio -- service-c (host-c)此模式的关键点SSL 终止与域名证书管理全部前移到既有网关fabio 只保留 HTTP 路由与负载均衡职责运维复杂度显著降低。部署模式三Amazon ELB 与 NLB——通过 PROXY protocol 保留客户端地址在 AWS 环境中见 docs/content/deploy/amazon-elb.md可以将 fabio 部署在 Amazon Classic Load Balancer 或 Network Load Balancer 之后Classic ELB启用 PROXY protocolv1将客户端的远端地址和端口传递给 fabioNLB在目标组上启用 PROXY protocolv2并在 fabio 监听器上设置pxyprototrue。由于 fabio 监听器同时接受 v1 和 v2 两种 PROXY 协议版本同一份 fabio 路由配置可以复用于两种负载均衡器- HTTP/TCP w/PROXY v1 or v2 - fabio -- service-a (host-a) | | internet -- HTTP/HTTPS/TCP -- ELB or NLB -- HTTP/TCP w/PROXY v1 or v2 - fabio -- service-b (host-b) | | - HTTP/TCP w/PROXY v1 or v2 - fabio -- service-c (host-c)对应的 fabio 监听器配置# 位于 ELB/NLB 之后解析 PROXY 协议头并设置 250ms 读取超时 proxy.addr :9999;protohttp;pxyprototrue;pxytimeout250ms文档同时给出了一项重要的版本说明PROXY protocol 在 fabio 1.1.3 至 1.5.10 之间默认开启自引入pxyproto选项的 1.5.11 版本起默认关闭需要显式设置。另外注意此监听器选项与同名路由选项相互独立——监听器选项用于解析上游LB发来的 PROXY 头而路由选项用于向 TCP 上游连接写入v1 版本的 PROXY 头。源码级验证PROXY 头如何被解析与写入在 proxy/listen.go 中当l.ProxyProto为真时监听器会被包装为proxyproto.Listener来自github.com/pires/go-proxyproto并传入l.ProxyHeaderTimeout作为ReadHeaderTimeout即前面提到的pxytimeout。该包装器负责在应用层读取并校验连接起始处的 PROXY 协议头然后剥离头部、暴露真实客户端地址。反向地当 fabio 需要向上游写入 PROXY 头时由 proxy/tcp/proxy_proto.go 的WriteProxyHeader完成它从in.RemoteAddr()与in.LocalAddr()提取客户端与服务端的 IP/端口对根据 IPv4/IPv6 生成PROXY TCP4/TCP6 ...文本头并写入输出连接——这正是 ELB/NLB 场景下客户端真实地址得以透传的底层机制。仓库还提供了可直接参考的 AWS 编排示例demo/aws/main.tf 中创建了aws_elb监听 80 → 实例 9999、9998 → 9998并通过aws_proxy_protocol_policy为实例端口9999启用 PROXY protocol 策略安全组同时放行了公网 80/9998 与 VPC 内 9999/9998——这是一个完整的ELB → fabio(9999) → 前端服务参考实现。部署模式四Amazon API Gateway——fabio 作为 API 网关目标fabio 还可以直接作为 [Amazon API Gateway] 的目标见 docs/content/deploy/amazon-api-gw.mdinternet -- HTTP/HTTPS -- API GW -- HTTP - fabio -- service-b (host-b)或位于启用 PROXY protocol 的 ELB 之后API GW → ELB → fabio- HTTP w/PROXY - fabio -- service-a (host-a) | | internet -- HTTP/HTTPS -- API GW -- ELB -- HTTP w/PROXY - fabio -- service-b (host-b) | | - HTTP w/PROXY - fabio -- service-c (host-c)使用客户端证书认证来自 API Gateway 的调用一种更强的安全方案是用客户端证书认证来自 API Gateway 的调用。此时需要在 fabio 上配置一个携带有效证书的 HTTPS 监听器internet -- HTTPS -- API GW -- HTTPS w/client cert - fabio -- service要让 fabio 能校验 Amazon 签发的客户端证书需要在配置中指定 AWS 生成证书的 CN。旧版方式是通过aws.apigw.cert.cn参数proxy.addr 1.2.3.4:9999;your/cert.pem;your/key.pem;api-gw-cert.pem aws.apigw.cert.cn ApiGateway其中api-gw-cert.pem是 AWS 管理控制台生成的证书your/cert.pem与your/key.pem是 HTTPS 证书/密钥对。关键背景由于 Amazon API Gateway 证书没有设置CA标志位Go 的 TLS 客户端认证默认会拒绝它们因此 fabio 需要将这些证书升级为可信 CA 才能完成认证否则连接会报TLS handshake error: failed to verify clients certificate。新版证书存储方式caupgcn文档明确提示aws.apigw.cert.cn参数在 1.2 及以后的版本中不再支持这些版本改用动态证书存储需要改为在证书源配置中添加caupgcnApiGateway参数proxy.cs cssome-name;typepath;certpath/to/certs;clientcapath/to/clientcas;caupgcnApiGateway完整的说明位于 docs/content/feature/certificate-stores.md 的 Common options 一节caupgcn会把指定 CNCommon Name的自签名客户端认证证书升级为 CA 证书典型用途正是处理 AWS API Gateway 那些缺少 CA 标志位的证书它取代了 1.1.5 引入的旧参数aws.apigw.cert.cn。从 config/config.go 的CertSource结构可以看到CAUpgradeCN字段的存在对应证书源中该选项的解析与存储。部署层面的工程参考端口与运行约束从仓库 Dockerfile 可以看出 fabio 的运行约定配置挂载于/etc/fabio/fabio.properties容器以非特权用户nobody:nogroup运行暴露9998管理 UI/API与 9999默认代理端口两个端口。构建阶段还通过setcap cap_net_bind_serviceep授权二进制绑定低端口80/443这为 Direct 模式直接监听公网 80/443 提供了依据相关的低端口绑定讨论见 docs/content/faq/binding-to-low-ports.md。横向扩展的通用原则四种部署模式反复出现同一个结论将 fabio 与前端服务同机部署即可同时获得高可用性与网络带宽分布。无论是直连公网、位于既有网关之后还是位于 AWS ELB/NLB/API Gateway 之后fabio 实例都可以按此模式水平复制在 AWS 场景下多个实例挂入同一个目标组即可由 LB 统一分发流量。运维与故障排查入口fabio 的 9998 端口提供管理界面与 API见 admin/server.go可用于查看路由表与运行状态路由表数据由 Consul 后端持续同步registry/consul/backend.go。若遇到与 PROXY protocol 相关的连接问题优先核对监听器的pxyproto/pxytimeout设置是否与上游 LB 的协议版本v1/v2匹配若遇到客户端证书认证失败则检查caupgcn是否已正确配置为ApiGateway。小结fabio 的部署方式可以归纳为一条主线无论流量从哪条路径进入直连公网、既有网关、AWS ELB/NLB 或 API Gatewayfabio 的职责始终是南北向的 HTTP(S)/TCP 入口分发。选择何种拓扑取决于两点谁来做 SSL 终止Direct 模式由 fabio 自己做其余模式前移给网关/LB以及是否需要透传客户端真实地址AWS 场景通过 PROXY protocol v1/v2 实现fabio 监听器默认同时兼容两者但需注意 1.5.11 起pxyproto默认关闭。结合proxy.addr的监听器语法、pxyproto/pxytimeout选项与caupgcn证书处理参数即可在 AWS 或自建环境中搭建出高可用、可横向扩展的 fabio 接入层。赞分享后端API网关微服务【免费下载链接】fabioConsul Load-Balancing made simple项目地址https://gitcode.com/gh_mirrors/fa/fabio点击查看免费下载相关推荐PrismAudio环境搭建指南3分钟搞定conda虚拟环境配置PrismAudio环境搭建指南3分钟搞定conda虚拟环境配置 PrismAudio是一款强大的音频处理工具通过conda虚拟环境可以快速搭建起稳定的运行后端API网关微服务InsightFace模型部署架构微服务设计与负载均衡终极指南InsightFace模型部署架构微服务设计与负载均衡终极指南 InsightFace作为业界领先的2D和3D人脸分析项目其模型部署架构设计体现了现代微服务人工智能计算机视觉深度学习himawaripy让你的桌面背景实时展示地球最新卫星图像的神奇工具himawaripy让你的桌面背景实时展示地球最新卫星图像的神奇工具 himawaripy 是一款强大的 Python 3 脚本能够获取近乎实时延迟约10上一篇qs安全特性深度剖析防护机制与最佳实践下一篇Calibre中文路径终极指南如何让电子书保持原生中文名创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
fabio 部署指南：构建从互联网入口到前端服务的 HTTP(S) 与 TCP 负载均衡架构
后端API网关微服务【免费下载链接】fabioConsul Load-Balancing made simple项目地址https://gitcode.com/gh_mirrors/fa/fabio点击查看免费下载fabio 的核心部署定位是将来自互联网的 HTTP(S) 与 TCP 请求分发到能够处理这些请求的前端FE服务再由前端服务借助 Consul 的服务发现能力找到所需的后端BE服务。本文基于 fabio 官方部署文档docs/content/deploy/_index.md及其四个部署场景子页完整讲解 Direct、现有网关之后、Amazon ELB/NLB、Amazon API Gateway 四种部署拓扑并结合仓库源码监听器实现、PROXY protocol 处理、配置解析补充底层原理与可落地的配置示例。读完本文你将掌握 fabio 的监听器配置语法proxy.addr、PROXY protocol 的启用方式以及在不同云网关场景下如何安全、高可用地接入 fabio。fabio 的部署定位互联网入口 → 前端服务官方部署文档首先明确了 fabio 的主要使用场景分发来自互联网的 HTTP(S) 和 TCP 请求到前端FE服务。在这个场景中FE 服务再利用 Consul 的服务发现功能去查找它们处理请求所需的后端BE服务形成一条完整的链路internet -- HTTP/HTTPS/TCP -- fabio -- FE 服务 -- (Consul 服务发现) -- BE 服务文档同时给出了一个重要的边界说明fabio 目前并不作为 FE-BE 或 BE-BE 路由器来在服务之间转发流量因为 Consul 的服务发现机制已经解决了服务间的寻址问题。不过从架构上讲没有任何机制阻止 fabio 被这样使用只是项目当前没有这样做。这意味着你在规划部署时应将 fabio 视为面向公网的南北向流量入口而不是服务网格内部的业务路由层。从仓库的监听器实现可以印证这一定位proxy/listen.go 中的ListenTCP负责解析监听地址net.ResolveTCPAddr、开启 TCP KeepAlive、按需叠加 PROXY protocol 支持与 TLS 封装最终返回一个统一的tcpListener。所有入口流量最终都汇聚到这一套监听器抽象上再由路由表registry从 Consul 同步而来完成分发。监听器配置基础proxy.addr语法无论采用哪种部署拓扑fabio 的入口行为都由proxy.addr配置项驱动。完整的参数说明见 docs/content/ref/proxy.addr.md其语法为[host]:port;optarg;opt[arg];...即每个监听器由一个地址和一组可选的optarg选项组成多个监听器用逗号分隔。每个监听器通过proto选项指定协议受支持的协议包括协议用途httpHTTP 协议httpsHTTPS 协议grpc/grpcsgRPC 及 gRPCTLStcp原始 TCP 代理可选 TLStcpsni基于 SNI 的 TCP 代理解析 ClientHello 中的服务器名扩展不解密即转发tcp-dynamic由 Consul 驱动的 TCP 代理httpstcpsniSNI 感知 TCP 代理带 HTTPS 回退prometheusPrometheus 指标端点配合 metrics.targetprometheus使用若未显式指定proto协议将根据是否通过cs选项配置了证书源自动判定为http或https。常用通用选项包括rt/wt/it读、写、空闲超时如3sstrictmatchtrue证书源必须提供与连接主机名匹配的证书否则使用第一张证书与 Go TLS 服务器默认行为一致pxyprototrue监听器尊重上游发送的 PROXY protocol v1/v2 头pxytimeoutPROXY 协议头读取超时启用pxyproto时默认 250msrefreshtcp-dynamic模式下检查路由表更新的刷新间隔TLS 相关选项为tlsmin、tlsmax取值为ssl30/tls10/tls11/tls12或 Gocrypto/tls常量对应数字与tlsciphers引号包裹、逗号分隔的十六进制或常量名列表如0xc00a,0xc02b。几个可直接使用的示例# 单 HTTP 监听器默认值 proxy.addr :9999 # IPv4 监听 读超时 proxy.addr 1.2.3.4:9999;rt3s # 多个监听器不同协议 proxy.addr 172.16.20.11:80;protohttp;rt60s;wt30s, \ 172.16.20.11:443;protohttps;rt60s;wt30s;csall;tlsmin10, \ 172.16.20.11:8443;prototcpsni # HTTPS 监听 证书源 TLS 版本/密码套件约束 proxy.addr :443;cssome-name;tlsmintls10;tlsmaxtls11;tlsciphers0xc00a,0xc02b # Consul 驱动的动态 TCP 代理5 秒刷新 proxy.addr 0.0.0.0:0;prototcp-dynamic;refresh5s从源码看config包中Listen结构体 的字段ProxyProto bool、ProxyHeaderTimeout、TLSCiphers、StrictMatch、各类超时与上述选项一一对应proxy/listen.go中的ListenTCP正是将这些字段落实为实际网络行为的地方。部署模式一Direct——fabio 直接监听公网 IP最简单的拓扑见 docs/content/deploy/direct.mdfabio 直接监听公网 IP可选地为一个或多个域名终止 SSL——一个 IP 对应一个域名。终止 SSL 后fabio 通过明文 HTTP 将请求转发给内部的前端服务-- service-a | internet -- HTTP/HTTPS -- fabio -- HTTP ---- service-b | -- service-c对应的监听器配置示例HTTPS 入口 证书源proxy.addr 1.2.3.4:443;protohttps;csall;rt60s;wt30s这里的cs指向证书源配置proxy.cs证书可以来自文件、目录、HTTP 服务器、Consul KV 或 Vault详细配置见 docs/content/feature/certificate-stores.md。Direct 模式的高可用与带宽扩展文档给出的扩展方式是将 fabio 与前端服务一起部署同机部署从而同时获得高可用性和网络带宽的分布效果- HTTP/HTTPS - fabio -- HTTP - service-a (host-a) | | internet --- HTTP/HTTPS - fabio -- HTTP - service-b (host-b) | | - HTTP/HTTPS - fabio -- HTTP - service-c (host-c)每一台主机host-a/b/c上同时运行 fabio 实例与对应的前端服务多份 fabio 实例共同承接公网流量任一主机故障时其余实例继续服务。这是理解后续所有横向扩展论述的基础模式。部署模式二Behind Existing Gateway——位于现有网关之后当公司/云环境已存在负责终止 SSL 的网关或负载均衡器时见 docs/content/deploy/existing-lb.mdfabio 不需要再处理 HTTPS 证书只需接收网关转发的明文 HTTP-- service-a | internet -- HTTP/HTTPS -- LB -- HTTP -- fabio -- HTTP ---- service-b | -- service-c此时监听器配置退化为纯 HTTPproxy.addr :9999;protohttp同样可以按与前端服务同机部署的方式横向扩展 fabio 实例实现高可用与带宽分布- HTTP - fabio -- service-a (host-a) | | internet -- HTTP/HTTPS -- LB -- HTTP - fabio -- service-b (host-b) | | - HTTP - fabio -- service-c (host-c)此模式的关键点SSL 终止与域名证书管理全部前移到既有网关fabio 只保留 HTTP 路由与负载均衡职责运维复杂度显著降低。部署模式三Amazon ELB 与 NLB——通过 PROXY protocol 保留客户端地址在 AWS 环境中见 docs/content/deploy/amazon-elb.md可以将 fabio 部署在 Amazon Classic Load Balancer 或 Network Load Balancer 之后Classic ELB启用 PROXY protocolv1将客户端的远端地址和端口传递给 fabioNLB在目标组上启用 PROXY protocolv2并在 fabio 监听器上设置pxyprototrue。由于 fabio 监听器同时接受 v1 和 v2 两种 PROXY 协议版本同一份 fabio 路由配置可以复用于两种负载均衡器- HTTP/TCP w/PROXY v1 or v2 - fabio -- service-a (host-a) | | internet -- HTTP/HTTPS/TCP -- ELB or NLB -- HTTP/TCP w/PROXY v1 or v2 - fabio -- service-b (host-b) | | - HTTP/TCP w/PROXY v1 or v2 - fabio -- service-c (host-c)对应的 fabio 监听器配置# 位于 ELB/NLB 之后解析 PROXY 协议头并设置 250ms 读取超时 proxy.addr :9999;protohttp;pxyprototrue;pxytimeout250ms文档同时给出了一项重要的版本说明PROXY protocol 在 fabio 1.1.3 至 1.5.10 之间默认开启自引入pxyproto选项的 1.5.11 版本起默认关闭需要显式设置。另外注意此监听器选项与同名路由选项相互独立——监听器选项用于解析上游LB发来的 PROXY 头而路由选项用于向 TCP 上游连接写入v1 版本的 PROXY 头。源码级验证PROXY 头如何被解析与写入在 proxy/listen.go 中当l.ProxyProto为真时监听器会被包装为proxyproto.Listener来自github.com/pires/go-proxyproto并传入l.ProxyHeaderTimeout作为ReadHeaderTimeout即前面提到的pxytimeout。该包装器负责在应用层读取并校验连接起始处的 PROXY 协议头然后剥离头部、暴露真实客户端地址。反向地当 fabio 需要向上游写入 PROXY 头时由 proxy/tcp/proxy_proto.go 的WriteProxyHeader完成它从in.RemoteAddr()与in.LocalAddr()提取客户端与服务端的 IP/端口对根据 IPv4/IPv6 生成PROXY TCP4/TCP6 ...文本头并写入输出连接——这正是 ELB/NLB 场景下客户端真实地址得以透传的底层机制。仓库还提供了可直接参考的 AWS 编排示例demo/aws/main.tf 中创建了aws_elb监听 80 → 实例 9999、9998 → 9998并通过aws_proxy_protocol_policy为实例端口9999启用 PROXY protocol 策略安全组同时放行了公网 80/9998 与 VPC 内 9999/9998——这是一个完整的ELB → fabio(9999) → 前端服务参考实现。部署模式四Amazon API Gateway——fabio 作为 API 网关目标fabio 还可以直接作为 [Amazon API Gateway] 的目标见 docs/content/deploy/amazon-api-gw.mdinternet -- HTTP/HTTPS -- API GW -- HTTP - fabio -- service-b (host-b)或位于启用 PROXY protocol 的 ELB 之后API GW → ELB → fabio- HTTP w/PROXY - fabio -- service-a (host-a) | | internet -- HTTP/HTTPS -- API GW -- ELB -- HTTP w/PROXY - fabio -- service-b (host-b) | | - HTTP w/PROXY - fabio -- service-c (host-c)使用客户端证书认证来自 API Gateway 的调用一种更强的安全方案是用客户端证书认证来自 API Gateway 的调用。此时需要在 fabio 上配置一个携带有效证书的 HTTPS 监听器internet -- HTTPS -- API GW -- HTTPS w/client cert - fabio -- service要让 fabio 能校验 Amazon 签发的客户端证书需要在配置中指定 AWS 生成证书的 CN。旧版方式是通过aws.apigw.cert.cn参数proxy.addr 1.2.3.4:9999;your/cert.pem;your/key.pem;api-gw-cert.pem aws.apigw.cert.cn ApiGateway其中api-gw-cert.pem是 AWS 管理控制台生成的证书your/cert.pem与your/key.pem是 HTTPS 证书/密钥对。关键背景由于 Amazon API Gateway 证书没有设置CA标志位Go 的 TLS 客户端认证默认会拒绝它们因此 fabio 需要将这些证书升级为可信 CA 才能完成认证否则连接会报TLS handshake error: failed to verify clients certificate。新版证书存储方式caupgcn文档明确提示aws.apigw.cert.cn参数在 1.2 及以后的版本中不再支持这些版本改用动态证书存储需要改为在证书源配置中添加caupgcnApiGateway参数proxy.cs cssome-name;typepath;certpath/to/certs;clientcapath/to/clientcas;caupgcnApiGateway完整的说明位于 docs/content/feature/certificate-stores.md 的 Common options 一节caupgcn会把指定 CNCommon Name的自签名客户端认证证书升级为 CA 证书典型用途正是处理 AWS API Gateway 那些缺少 CA 标志位的证书它取代了 1.1.5 引入的旧参数aws.apigw.cert.cn。从 config/config.go 的CertSource结构可以看到CAUpgradeCN字段的存在对应证书源中该选项的解析与存储。部署层面的工程参考端口与运行约束从仓库 Dockerfile 可以看出 fabio 的运行约定配置挂载于/etc/fabio/fabio.properties容器以非特权用户nobody:nogroup运行暴露9998管理 UI/API与 9999默认代理端口两个端口。构建阶段还通过setcap cap_net_bind_serviceep授权二进制绑定低端口80/443这为 Direct 模式直接监听公网 80/443 提供了依据相关的低端口绑定讨论见 docs/content/faq/binding-to-low-ports.md。横向扩展的通用原则四种部署模式反复出现同一个结论将 fabio 与前端服务同机部署即可同时获得高可用性与网络带宽分布。无论是直连公网、位于既有网关之后还是位于 AWS ELB/NLB/API Gateway 之后fabio 实例都可以按此模式水平复制在 AWS 场景下多个实例挂入同一个目标组即可由 LB 统一分发流量。运维与故障排查入口fabio 的 9998 端口提供管理界面与 API见 admin/server.go可用于查看路由表与运行状态路由表数据由 Consul 后端持续同步registry/consul/backend.go。若遇到与 PROXY protocol 相关的连接问题优先核对监听器的pxyproto/pxytimeout设置是否与上游 LB 的协议版本v1/v2匹配若遇到客户端证书认证失败则检查caupgcn是否已正确配置为ApiGateway。小结fabio 的部署方式可以归纳为一条主线无论流量从哪条路径进入直连公网、既有网关、AWS ELB/NLB 或 API Gatewayfabio 的职责始终是南北向的 HTTP(S)/TCP 入口分发。选择何种拓扑取决于两点谁来做 SSL 终止Direct 模式由 fabio 自己做其余模式前移给网关/LB以及是否需要透传客户端真实地址AWS 场景通过 PROXY protocol v1/v2 实现fabio 监听器默认同时兼容两者但需注意 1.5.11 起pxyproto默认关闭。结合proxy.addr的监听器语法、pxyproto/pxytimeout选项与caupgcn证书处理参数即可在 AWS 或自建环境中搭建出高可用、可横向扩展的 fabio 接入层。赞分享后端API网关微服务【免费下载链接】fabioConsul Load-Balancing made simple项目地址https://gitcode.com/gh_mirrors/fa/fabio点击查看免费下载相关推荐PrismAudio环境搭建指南3分钟搞定conda虚拟环境配置PrismAudio环境搭建指南3分钟搞定conda虚拟环境配置 PrismAudio是一款强大的音频处理工具通过conda虚拟环境可以快速搭建起稳定的运行后端API网关微服务InsightFace模型部署架构微服务设计与负载均衡终极指南InsightFace模型部署架构微服务设计与负载均衡终极指南 InsightFace作为业界领先的2D和3D人脸分析项目其模型部署架构设计体现了现代微服务人工智能计算机视觉深度学习himawaripy让你的桌面背景实时展示地球最新卫星图像的神奇工具himawaripy让你的桌面背景实时展示地球最新卫星图像的神奇工具 himawaripy 是一款强大的 Python 3 脚本能够获取近乎实时延迟约10上一篇qs安全特性深度剖析防护机制与最佳实践下一篇Calibre中文路径终极指南如何让电子书保持原生中文名创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
