解码 Atlassian 基础设施指南

A 最近走红的帖子将 Atlassian 庞大基础设施的内部运作机制推向了聚光灯下。在离职后，一位曾参与构建其系统的前工程师发布了一份详细的技术拆解，揭示了支撑这家年营收数十亿美元、服务数十万客户的公司背后的架构。

虽然有人将其视为构建竞争对手的“蓝图”，但真正的价值在于理解工程权衡以及用于在企业级水平维持稳定性和可扩展性的特定工具链。

架构栈

所披露的基础设施侧重于使用灵活的软件定义网络和自动化配置来取代传统的、昂贵的企业级硬件。该架构栈的关键组件包括：

1. 使用 Envoy Proxy 进行流量管理

而非依赖专有的企业级负载均衡器，该系统利用了 Envoy Proxy。Envoy 是一款专为云原生应用设计的开源、高性能代理。通过摆脱基于硬件的负载均衡，基础设施获得了更大的灵活性以及通过编程方式管理流量路由的能力。

2. 用于横切关注点的 Sidecar 模式

为了在不使核心应用逻辑臃肿的情况下处理必要的服务，该架构采用了 sidecar 架构。这种模式用于管理：

• Authentication: 集中化身份验证。
• Logging: 标准化跨服务的遥测数据收集方式。
• Logging and Rate Limiting: 通过在边缘或服务层实施限制，保护服务免受过载影响。

3. 通过 DynamoDB 和 SQS 进行异步配置

扩展到 35 万客户需要一种稳健的方式来处理资源分配。该系统利用 Amazon DynamoDB (一种 NoSQL 数据库) 和 Amazon SQS (Simple Queue Service) 来管理异步配置。这确保了当新客户注册或扩展其使用量时，该过程会在后台可靠地进行，而不会阻塞用户体验。

4. 使用 Packer 和 SaltStack 进行自动化 VM 部署

对于底层的计算层，基础设施依赖于 Packer 和 SaltStack。

• Packer 用于为多个平台创建相同的机器镜像。
• SaltStack 提供大规模部署和管理这些 VM 所需的配置管理和编排功能。

行业视角：蓝图 vs. 现实

这些信息的发布在 Hacker News 等平台上的工程社区引发了重大辩论。资深架构师们的共识是，虽然工具集令人印象深刻，但工具本身并不是“秘诀”。

“护城河”论点

几位批评者指出，所列出的技术——Envoy、DynamoDB 和 sidecars——都是高规模系统的行业标准。正如一位评论者所言：

"So basically anything anyone who is building at that scale would have some rendition of? ... It's like someone at Discord being fired then telling the world they worked with Erlang and Rust to scale Discord."

这里的论点是，像 Atlassian 这样的公司的技术护城河并不在于选择了特定的代理或数据库，而是在于管理这些工具以服务庞大客户群的运营经验。

执行力胜于架构

讨论中的另一个常见主题是“构建”系统与“运营”系统之间的区别。虽然组件是已知的，但难点在于“第二天”运营（day two operations）：监控、修补、调试以及在不中断服务的情况下演进系统。

"This is absolutely worthless. It's not hard to build a similar system, there's no moat in that. It's growing it and operating it that is difficult."

结论：拆解报告的价值

尽管对“指南”这一方面的存在怀疑，但这份拆解报告作为工程决策的案例研究仍然具有极高的价值。与其将其视为“构建下一个 Atlassian”的指南，不如将其视为一项关于大型企业如何从传统企业级硬件转型为现代云原生架构模式的研究。它突显了向开源工具和自动化编排的转变，以实现十亿美元级业务所需的规模。