本文来自 HAProxyConf 2022，为什么 LinkedIn 选择了 HAProxy。
对于基础设施和架构团队，技术选型的目标是简洁、故障隔离、性能。
下图是 LinkedIn 整体的网络、物理架构图：
对反向代理、负载均衡、路由策略非常依赖，这也是网关系统的重要性。
过去 LinkedIn 重度依赖 Apache Traffic Server，为满足业务需要，开发了 30+ 的插件。
LinkedIn 面临三个挑战，如下图：
数据快速增长，QPS 增加很快；业务多元化，比如不同地区的路由策略要求不一样；需要支持最新的协议，比如 HTTP/2、HTTP/3 和 gRPC。
那 Apache Traffic Server 能否应对呢？
首先通过横向扩展，但带来的性能提升很有限，仅12%，过多的横向扩展也会带来新的问题，会出现其它的瓶颈。
其次复杂性带来的风险，过度依赖自定义的 Apache Traffic Server C/C++ 插件，而且是以共享库的方式运行，无法做到有效的隔离。
那既然 Apache Traffic Server 无法胜任，如何寻找更好的解决方案呢。
LinkedIn 的选型决策如下图：
具体考虑：
-
• 开源、社区活跃 -
• 高性能，减少机器成本 -
• 功能丰富，尤其是路由 -
• 支持现代化的协议
最终 HAProxy 打败了 Zuul、Nginx、Envoy 等对手。
它的核心亮点如下图：
性能方面，LinkedIn 做了测试，1KB的测试负载（包括1毫秒后端延迟模拟）来测试 RPS，HAProxy 达到 55000 RPS，也不会出现延迟。
可配置性增强，原来 16000 条路由规则，现在仅仅需要 250 条。
可扩展性与故障隔离更好，比如 HAProxy 实现了业务级别的软路由，可以根据会员属性路由到一个数据中心。
最终完成了核心目标，如下图：
通过迁移到 HAProxy，LinkedIn 不仅仅是替换了一个组件，从根本上实现了网关系统的现代化改造。从一个复杂、依赖大量插件、难以扩展的架构，转向了一个管道化、高性能、易管理、更现代化的网络技术解决方案。