解碼 Atlassian 基礎設施策略手冊

A 最近在網路上瘋傳的一篇貼文，將 Atlassian 龐大基礎設施的內部運作機制推向了聚光燈下。在離職後，一位曾協助建構其系統的前工程師發布了一份詳細的技術拆解，說明了支撐這家年營收達數十億美元、服務數十萬客戶的公司之架構。

雖然有些人將其視為建立競爭對手的「藍圖」，但真正的價值在於理解工程上的權衡（trade-offs）以及用於在企業級別維持穩定性與擴展性的特定工具鏈。

架構堆疊

揭露的基礎設施重點在於以靈活的軟體定義網路（software-defined networking）和自動化配置（automated provisioning）來取代傳統且昂貴的企業級硬體。該堆疊的核心組件包括：

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

不再依賴專有的企業級負載平衡器，系統利用了 Envoy Proxy。Envoy 是一款專為雲端原生應用程式設計的高性能開源代理伺服器。透過捨棄硬體負載平衡，基礎設施獲得了更大的靈活性，以及透過程式化管理流量路由的能力。

2. 處理橫切關注點（Cross-Cutting Concerns）的 Sidecar 模式

為了在不增加核心應用程式邏輯負擔的情況下處理必要服務，該架構採用了 sidecar architecture。此模式用於管理：

• Authentication: 中央化身份驗證。
• Logging: 標準化各服務間遙測數據（telemetry）的收集方式。
• Logging and Rate Limiting: 透過在邊緣或服務層級實施限制，保護服務不被過載。

3. 透過 DynamoDB 和 SQS 進行非同步配置

擴展到 35 萬名客戶需要一種穩健的方式來處理資源分配。系統利用 Amazon DynamoDB (a NoSQL database) 和 Amazon SQS (Simple Queue Service) 來管理非同步配置。這確保了當新客戶註冊或擴展其使用量時，該過程會在背景可靠地進行，而不會阻塞使用者體驗。

4. 使用 Packer 和 SaltStack 進行自動化 VM 部署

對於底層的運算層，基礎設施依賴 Packer 和 SaltStack。

• Packer 用於為多個平台建立相同的機器映像檔（machine images）。
• SaltStack 提供大規模部署與管理這些 VM 所需的配置管理與編排（orchestration）。

行業觀點：藍圖 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）：監控、修補、patching、除錯以及在不中斷服務的情況下演進系統。

"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」的指南，不如將其視為研究大型企業如何從傳統企業硬體轉型為現代、雲端原生架構模式的研究。它突顯了向開源工具與自動化編排的轉型，以實現數十億美元規模業務所需的擴展性。