在美国西雅图举行的首届 EnvoyCon https://envoyconna18.sched.com/ 会议上, 来自 eBay 的工程团队讨论了如何将 Envoy 作为网络边缘, 以替代基于硬件的负载均衡器. 他们的关键经验包括, 测试至关重要, 这样能够验证跨一系列真实场景的性能特征; 必须从组织和技术的角度仔细控制新旧边缘系统之间的迁移;"可编程的边缘" 会带来很多的优势, 但是也有一些挑战.
Bala Madhavan 和 Qiu Yu https://www.linkedin.com/in/unicell/ 是来自 eBay 的技术人员, 均为软件工程师, 他们首先讨论了 eBay 在美国的数据中心, 但是他们要在全球范围内运行连接点 (points of presence,PoP) 以减少延迟, 从而为终端用户提供更好性能. 他们使用了 "软件支撑的基础设施", 在每个 PoP 上部署了一个 Kubernetes 集群, 并且在每个集群的边缘上有一个 "north-south" 网关, 用来管理所有针对外部的传入和传出流量.
eBay 的边缘团队在每个 Kubernetes 集群中将 Envoy 运行在多个容器里面. 针对就绪 (readiness) 和存活 (liveness) 状态的探针会确保容器能够按照预期的方式运行, 并确保所有动态恢复过程都能顺利完成. 7 层路由和部署控制是由一个定制 Kubernetes Custom Resource Definitions (CRDs) 来进行管理的, 他们还使用 Ingress 注解实现自定义特性的规范. 除此之外, 他们还实现了一个自定义的发现服务, 用于处理如下的 Envoy 管理 xDS API , 并负责进行部署和路由: 路由发现服务(routing discovery services,RDS), 监听器发现服务(listener discovery service,LDS), 端点发现服务(endpoint discovery service,EDS) 以及集群发现服务(cluster discovery service,CDS).
从基于硬件的负载均衡器到 Envoy 支撑的边缘解决方案的迁移是渐进式的. 在迁移过程中, 第一步就是识别和实现已有方案和新 Envoy 方案之间的差异, eBay 团队已经将相关的代码贡献给了上游的 Envoy 开源项目 https://github.com/envoyproxy/envoy . 另外, 他们还添加了对专有证书管理系统集成的支持, 并且对 data plane 进行了一些定制(这些定制功能还没有往上游贡献). 它们会处理连接预取(prefetching), 根据特定的需求丢弃请求或者将请求重置到特定的路由, 而且提供了一个 "默认的上游集群" 来优雅地进行错误处理. 支持 BBR https://github.com/google/bbr , 同时添加了对谷歌新 TCP 流控制算法 的支持, 以及尚未明确说明的 "SSL 和 TCP 优化".
Madhavan 和 Yu 展示了响应时间的图表, 用以说明新的基于 Envoy 的实现要比之前传统的硬件负载均衡器表现更好. 它们还以 Envoy HTTP 过滤器的方式实现了一个额外的缓存层, 这个缓存层支持动态对象缓存, 能够使用外部缓存存储和 Envoy 的 RingHash 负载均衡器 在多个缓存存储之间共享缓存的数据, 首字节响应时间 (time-to-first-byte,TTFB) 提高了一个数量级.
在可观察性方面, 在每个 PoP 上会运行一个 Prometheus https://prometheus.io/ 集群, 另外还有一个中心化的 Grafana https://grafana.com/ 用来实现可视化. 告警是使用 Alertmanager https://prometheus.io/docs/alerting/alertmanager/ 和外部检查来实现的, 还包括用来进行异常探测的静态和动态阈值. 整个边缘技术栈是通过 Helm Chart https://docs.helm.sh/developing_charts/ 在 Kubernetes 中进行安装和配置的, Helm Chart 会作为部署的唯一来源.
总结一下所学习到的经验, 最重要的就是需要进行测试. 硬件和软件的交叉校验是非常重要的, 为了确保用户不会遇到性能下降的问题, 实时用户监控 (real user monitoring,RUM) 是必不可少的. DC 和 PoP 的故障恢复要进行测试, 还需要运行额外的 混沌 (chaos) 试验 ."平滑工作负载迁移" 的经验包括建议进行跨功能 (团队) 的规划和验证, 以可控的方式在边缘解决方案之间切换流量, 同时密切观察运维指标.
他们提到的挑战包括运行新系统时增加 PoP 的数量所带来的运维操作, 跨 PoP 探测配置漂移以及为集群管理提供工具支持. 通过 API 驱动 Envoy 代理的方式实现 "可编程的边缘" 会提供很多的优势, 但是也遇到了很多的挑战. 例如, control plane 是 "自行构建还是集成", 与已有的 (遗留) 组件进行集成, 如何操作指标和相关的性能数据, 以及硬件专家所组成的运维团队如何调试和解决基于软件的方案.
演讲幻灯片的 PDF 版本可以在 EnvoyCon Sched 页面上 "Running Envoy as an Edge Proxy" 下载, 演讲的录像 可以在 CNCF YouTube 频道观看.
来源: http://www.tuicool.com/articles/JVjeQbe