Atlassian 使用 Istio 的案例研究
用户需求分析
Atlassian 内部开发人员对服务到服务通信平台的需求主要包括：
- 开发体验 (DevX): API 端面、HTTP 客户端/服务器调优、服务发现、身份验证、gRPC 支持、指标、故障处理和自动恢复、限速
- 安全: 身份验证、授权
- 可靠性: 故障注入、租户分片、混沌实验
- 成本: 成本控制
- 运维: 服务发现+依赖映射、指标、故障处理和自动恢复
其中，开发人员最关注的是开发体验、安全、可靠性和性能。
现有数据平面代理使用情况
Atlassian 多年来使用了多种数据平面代理，包括 Nginx、Haproxy、vTM、ALB、ELB、OpenRESTY、Zuul、Varnish 等。2 年前，Atlassian 引入了 Envoy 作为新的代理解决方案，主要原因是其可观察性、性能、流配置、可扩展性和生态系统。
Atlassian 以两种方式使用 Envoy：
- 自动伸缩入口网关: 终止 TLS，支持虚拟域，应用安全标准
- 边车代理: 透明入口侧车度量、HTTP 调整、身份验证、速率限制
现有设置与用例匹配度
当前 Envoy 设置能满足的部分用例：
- API 端面（身份验证）
- gRPC 支持
- 限速
- Metrics
但无法满足的用例：
- 动态路由规则
- 分片服务路由
- 节点到节点通信
- 动态更新上游集群列表
- 混沌实验
控制平面需求
Atlassian 需要一个动态控制平面来实现以下目标：
- 应用客户端功能并让开发人员享受到内部 API 网关带来的好处
- 本地支持路由到分片服务
- 降低 ELB / 跨 AZ 成本
- 在 HTTP 级别运行混沌实验
控制平面方案评估
Atlassian 使用 Kepner Tregoe 的“决策分析”方法评估了多个控制平面方案，包括 DIY、Istio、应用程序网格、领事连接、Kuma 和开放服务网格。
评估结果：
- Kuma 和 Open Service Mesh: 未满足安全性和规模验证记录要求
- DIY: 成本高
- Consul Connect: 成本高，功能缺失
- App Mesh: 构建和运营简单，但关键功能缺失，扩展性滞后
- Istio: 对非 K8s 计算支持增强，操作模型简化，扩展性良好
最终选择
Atlassian 选择 Istio 作为控制平面，因为它在安全性、可扩展性、性能和成本方面表现最佳。
测试与未来计划
Atlassian 已经进行了 Istio 的测试，但尚未在生产环境中全面部署。他们希望通过分享使用 Istio 的经验，帮助其他组织决定是否以及何时采用 Istio。
