Building Bluesky: a Distributed Social Network (Real-World Engineering Challenges)
建立 Bluesky：一個分佈式社交網絡（現實世界的工程挑戰）
Bluesky is built by around 10 engineers, and has amassed 5 million users since publicly launching in February this year. A deep dive into novel design decisions, moving off AWS, and more.
Bluesky 是由約 10 位工程師建立的，自今年 2 月公開推出以來已經吸引了 500 萬用戶。深入探討新穎的設計決策、遷移離開 AWS 等議題。
Before we start: AI tooling for software development feels like it has hit "peak hype" across mainstream media. We would like to do a "reality check" and find out how engineers and teams are using these tools (and which tools/use cases are genuinely efficient). Please help us by filling out this survey.
在我們開始之前：軟體開發的人工智慧工具感覺在主流媒體上已達到了“高潮”，我們想要進行一次“現實檢查”，找出工程師和團隊如何使用這些工具（哪些工具/使用案例真正有效）。請通過填寫此調查問卷來幫助我們。
We will share the full report with all of you who share detailed insights. Thanks for your help!
我們將與分享詳細見解的所有人分享完整報告。感謝您的幫助！
‘Real-world engineering challenges’ is a series in which we interpret interesting software engineering or engineering management case studies from tech companies.
“現實世界的工程挑戰”是一個系列，我們將解釋來自科技公司的有趣軟體工程或工程管理案例研究。
Bluesky is known as a Twitter-alternative. It launched two years ago, with an invite-only beta launch last year. It’s already grown to an impressive 5.5 million registered users. Interestingly for software engineers, Bluesky is also a fascinating engineering project unlike any other mainstream social network. Martin Kleppman, author of the Designing Data Intensive Applications book, is involved as a technical advisor, and has published a paper outlining the novel approaches Bluesky has taken.
Bluesky 被稱為 Twitter 的替代品。它在兩年前推出，去年進行了僅限邀請的測試推出。它已經發展到令人印象深刻的 550 萬註冊用戶。對於軟體工程師來說，Bluesky 也是一個與其他主流社交網絡不同的迷人工程項目。《設計資料密集型應用》一書的作者 Martin Kleppman 是技術顧問之一，並發表了一篇論文概述了 Bluesky 採取的新方法。
The biggest differences between Bluesky and other large social networks:
Bluesky 和其他大型社交網絡之間最大的區別：
Decentralized. Bluesky is a “decentralized social network,” meaning anyone can run their own servers. If Bluesky’s core team turned off all services today, the network would keep functioning. As such, Bluesky offers a way for users to truly own their data and services.
去中心化。Bluesky 是一個“去中心化社交網絡”，意味著任何人都可以運行自己的服務器。如果 Bluesky 的核心團隊今天關閉所有服務，該網絡仍將繼續運作。因此，Bluesky 為用戶提供了一種真正擁有其數據和服務的方式。Open source. Nearly everything about Bluesky builds is open source, and hosted on GitHub.
開源。關於 Bluesky 的幾乎所有內容都是開源的，並且托管在 GitHub 上。Rapid growth. The product went from zero to 5 million users in around 12 months after announcing an invite-only beta.
快速增長。該產品在宣布僅限邀請測試版後的約 12 個月內，用戶數從零增長到 500 萬。Small team. Bluesky was built with a small team of 3 engineers during the first year, and with 12 software engineers at the time of publication.
小團隊。Bluesky 在第一年由 3 名工程師組成的小團隊建立，並在發布時有 12 名軟件工程師。
Other social networks have achieved some of these things; such as Mastodon allowing users to own their data and identity, and Meta achieving eye-catching growth by getting 100 million users in just a week. Still, only Bluesky has pulled off them all.
其他社交網絡已經實現了其中一些功能；例如 Mastodon 允許用戶擁有自己的數據和身份，Meta 在短短一周內就吸引了 1 億用戶的增長。然而，只有 Bluesky 完成了所有這些。
Today, we dive into how Bluesky is built, sitting down with its two founding engineers: Daniel Holmgren and Paul Frazee. They take us through:
今天，我們深入探討 Bluesky 的建立方式，與其兩位創始工程師 Daniel Holmgren 和 Paul Frazee 進行對話。他們帶領我們了解：
Development timeline. How Bluesky went from a vague idea with few specific details, to a decentralized social network with millions of users.
開發時間軸。Bluesky 如何從一個模糊的想法演變為擁有數百萬用戶的去中心化社交網絡。Experimentation phase. A team of 2-3 engineers prototyped for 9 months, established the development principles, and laid the groundwork for the protocol and app.
實驗階段。一支由 2-3 名工程師組成的團隊進行了 9 個月的原型製作，確立了開發原則，為協議和應用程序奠定了基礎。v1 architecture. An overview of Bluesky’s architecture at the launch of its public beta offering. This was a Postgres database built on top of AWS, and used Pulumi.
v1架構。在Bluesky的公共測試版推出時，對其架構進行概述。這是建立在AWS上的Postgres數據庫，並使用了Pulumi。v2 architecture. Extending Bluesky to support “federation,” allowing users to run their own Bluesky instances.
v2 架構。擴展 Bluesky 以支持“聯邦”，允許用戶運行自己的 Bluesky 實例。Scaling the database layer. PostgreSQL didn’t scale with the site’s growth, so it was time to migrate. The team chose ScyllaDB and SQLite.
擴展數據庫層。隨著網站的增長，PostgreSQL 無法擴展，因此是時候遷移了。團隊選擇了 ScyllaDB 和 SQLite。Infra stack: from AWS to on-prem. AWS was becoming too costly, so Bluesky moved over to dedicated data centers and bare-metal machines.
基礎架構堆棧：從 AWS 到本地。AWS 變得太昂貴，因此 Bluesky 轉移到了專用數據中心和裸金屬機器。Reality of building a social network. Typical firefighting issues, Elon Musk, and outages not being “life-or-death” crises.
建立社交網絡的現實。典型的消防問題，埃隆·馬斯克，以及斷線不是“生死攸關”的危機。
1. Development timeline 1. 開發時間軸
Bluesky has been in development for just over 2 years, and has been publicly available for around 12 months. Here’s the timeline:
Bluesky已經開發了2年多，並且已經公開提供了大約12個月。以下是時間表：
藍天的發展時間軸和重要里程碑
Adding in the three phases we’ll discuss below:
在下面我們將討論的三個階段中添加：
Bluesky 的發展，分為三個階段
Phase 1: Experimentation 第一階段：實驗
The first 10 months of the project between January and October 2022 were all about exploration, and the team started to work fully in the open after 4 months. The first project the team open sourced was Authenticated Data Experiment (ADX), an experimental personal data server and a command-line client, accompanied by a network architecture overview.
2022年1月至10月的專案前10個月都是關於探索，團隊在4個月後開始完全公開工作。團隊首個開源的專案是驗證數據實驗（ADX），一個實驗性的個人數據伺服器和命令行客戶端，附帶網絡架構概述。
In April 2022, heavy Twitter user, Elon Musk, raised the prospect of potentially acquiring the site, which created interest in alternatives to the bird app, as any major change in a market-leading social network does.
2022年4月，Twitter重度用戶伊隆·馬斯克提出了可能收購該網站的前景，這引起了對鳥網站替代方案的興趣，因為市場領先社交網絡的任何重大變化都會引起關注。
The first commit for the Bluesky mobile app was made in June 2022, and Paul Frazee worked on it. It started as a proof-of-concept to validate that the protocol worked correctly, and to aid protocol development via real-world use. Conventional wisdom says that prototypes are thrown away after serving their purpose.
Bluesky手機應用程式的第一次提交是在2022年6月進行的，由Paul Frazee負責。它最初是一個概念驗證，以確認協議正確運作，並通過實際使用來幫助協議開發。傳統智慧認為原型在完成任務後應被丟棄。
However, in this case this mobile app that a single person had built, became the production app, following the unforeseen spike of interest in it caused by takeover news at Twitter. This is a good reminder that real world events can push conventional wisdom out of the window!
然而，在這種情況下，這個由一個人建立的手機應用程式成為了生產應用程式，這是由於推特被併購消息引起的意外興趣激增。這是一個很好的提醒，現實世界的事件可能會推翻傳統智慧！
In October 2022, the team announced the Authenticated Transfer Protocol (AT Protocol) and the app’s waitlist, just a few days after news that Elon Musk was to acquire Twitter. This led many tweeters to seek alternative social networks, and drove a major signup spike for Bluesky’s private beta. This development put pressure on the Bluesky team to seize the unexpected opportunity by getting the protocol and app ready for beta users. See details on the AT Protocol.
2022 年 10 月，團隊宣布了驗證轉移協議（AT Protocol）和應用程序的等候名單，就在幾天之後，有消息稱埃隆·馬斯克將收購 Twitter。這導致許多推特用戶尋求替代社交網絡，並為 Bluesky 的私人測試版帶來了一波主要的註冊高峰。這一發展使 Bluesky 團隊面臨壓力，要抓住意外的機會，讓協議和應用程序準備好供測試版用戶使用。有關 AT Protocol 的詳細信息請參見。
Phase 2: invite-only launch and the first 1M users
第二階段：僅限邀請的推出和首批 100 萬用戶
In October 2022, Bluesky consisted solely of Jay Graber CEO, and two software engineers; Daniel and Paul. Engineer #3, Devin, joined the same month. Announcing the AT Protocol and waitlist generated some media buzz and Bluesky attracted more interest during this period.
2022 年 10 月，Bluesky 僅由首席執行官 Jay Graber 和兩名軟件工程師 Daniel 和 Paul 組成；工程師＃3 Devin 在同一個月加入。宣布 AT 協議和等候名單引起了一些媒體關注，Bluesky 在這段時間吸引了更多的興趣。
In March 2023, the company was confident that the protocol and mobile app were stable enough to invite more users by sending invites.
2023 年 3 月，公司相信協議和手機應用程式已經足夠穩定，可以通過發送邀請來邀請更多用戶。
“Blocking” was implemented in a single night. After the app opened up to more users, there was an influx of offensive posts and of users verbally harassing other accounts. This made it clear that implementing blocks to restrict individual accounts from viewing and commenting on a user’s posts, was urgently-needed functionality.
在一個晚上實施了「封鎖」功能。當應用程式向更多用戶開放後，出現了大量冒犯性帖子和用戶對其他帳戶進行口頭騷擾的情況。這清楚地表明，實施封鎖功能以限制個別帳戶查看和評論用戶帖子的功能是迫切需要的。
The three earliest developers – Paul, Devin and Daniel – jumped on a call, then got to work. In the community, developers saw the pull requests (PRs) on this feature appear on GitHub, and started to point out bugs, and cheer on the rapid implementation. They wrapped it up and launched the feature by the end of the same day. To date, this is the most rapidly-built feature, and is still used across the protocol and the app!
三位最早的開發者 - Paul、Devin 和 Daniel - 進行了一次通話，然後開始工作。在社區中，開發者們在 GitHub 上看到了有關這一功能的拉取請求（PRs），並開始指出錯誤，並為快速實施喝彩。他們完成了這項功能並在同一天結束時推出了。迄今為止，這是最快建成的功能，仍然在協議和應用程序中使用！
In June 2023, Bluesky passed the 100,000-users milestone when the team numbered 6 developers, who’d shipped features like custom feeds, blocking and muting, moderation controls, and custom domains. A web application built on React Native was also in production.
2023 年 6 月，當 Bluesky 團隊人數為 6 名開發者時，其用戶數超過了 10 萬，他們已經推出了自定義動態、屏蔽和靜音、審核控制和自定義域等功能。一個基於 React Native 的 Web 應用程序也正在生產中。
In September 2023, Bluesky passed 1 million users – a 900,000 increase in just 3 months!
2023 年 9 月，Bluesky 用戶數突破 100 萬 - 僅在 3 個月內增加了 90 萬！
Phase 3: Preparing for public launch
第三階段：為公眾發布做準備
In the 6 months following the 1 million-user milestone, the focus was on preparing to open up Bluesky to the public with no waitlist or throttling of invites.
在突破 100 萬用戶里程碑後的 6 個月裡，重點是準備開放 Bluesky 給公眾，無需等候名單或邀請限制。
Federation (internal.) To prepare for “proper” federation, the team made architecture changes to enable internal federation of Bluesky servers.
聯邦（內部）：為了準備“正確”的聯邦，團隊對架構進行了更改，以實現 Bluesky 服務器的內部聯邦。
Federation is a key concept in distributed networks. It means a group of nodes can send messages to one another. For Bluesky, it meant that – eventually – users should be able to run their own PDS instances that host their own user information (and user information of users on that server.) And the Bluesky network operates seamlessly with this distributed backend.
聯邦是分佈式網絡中的一個關鍵概念。它意味著一組節點可以互相發送消息。對於 Bluesky 來說，這意味著最終用戶應該能夠運行自己的 PDS 實例，其中托管他們自己的用戶信息（以及該服務器上用戶的用戶信息）。Bluesky 網絡與這種分佈式後端無縫運行。
A new logo and a reference to Twitter. The team prepared a new logo for launch, and announced it in December 2023:
一個新的標誌和對 Twitter 的引用。團隊為推出準備了一個新的標誌，並在 2023 年 12 月宣布：
新舊標誌
The butterfly logo is intended as a symbol of freedom and change. Existing centralized social media platforms – like X (formerly Twitter,) Instagram, TikTok, and Youtube – are platforms that want to lock users into their website and apps. Bluesky, on the other hand, offers its protocol, but doesn’t dictate which apps or websites people use. It doesn’t even want to dictate the hosting of content:
蝴蝶標誌旨在象徵自由和改變。現有的中央社交媒體平台 - 如X（前身為Twitter）、Instagram、TikTok和Youtube - 是希望將用戶鎖定在其網站和應用程序中的平台。另一方面，Bluesky提供其協議，但不指定人們使用哪些應用程序或網站。它甚至不想指定內容的託管：
Jay Graber在Twitter關於Bluesky願景的演示中的最後一張幻燈片。2021年，Twitter授予Bluesky初始1300萬美元的資金，部分基於這個願景。這張圖像展示了藍鳥從封閉平台中解放出來進入Bluesky的開放生態系統。來源：Bluesky。
Let’s dive into each phase of the building process.
讓我們深入了解建築過程的每個階段。
2. Experimentation phase 2. 實驗階段
During Bluesky’s first 9 months (January-September 2022) two software engineers built the protocol and apps – Daniel Holmgren and Paul Frazee – and Jay the CEO signed off design decisions. The first couple of months were about experimenting and tech “spiking,” which means timeboxing the time and effort spent building and trying out ideas. Here’s Paul:
在 Bluesky 的前 9 個月（2022 年 1 月至 9 月）中，兩位軟體工程師 Daniel Holmgren 和 Paul Frazee 建立了協議和應用程式，CEO Jay 簽署了設計決策。最初的幾個月是關於實驗和技術“尖峰”，這意味著限制建立和嘗試想法所花費的時間和精力。以下是 Paul 的說法：
“We would greenfield for a period, then attack what we had just created to see if it holds up. We gave the existing technologies a really close look; if we didn’t see meaningful improvements from the existing protocols, then we decided we’d use what was already out there.”
“我們將進行綠田野地的一段時間，然後攻擊我們剛剛創建的內容，看看它是否堅固。我們仔細研究了現有的技術；如果我們沒有從現有協議中看到有意義的改進，那麼我們決定使用已經存在的東西。”
When the direction wasn’t clear, the team kept trying out new approaches, says Daniel:
當方向不明確時，團隊不斷嘗試新的方法，Daniel 說：
“We set out to use as many existing specs as we could. We spent a lot of time early on investigating things like Activity Pub and seriously trying to figure out how we could make it work, and realizing that it didn't really work for our use case.”
“我們設法使用盡可能多的現有規範。我們在早期花了很多時間調查諸如 Activity Pub 之類的事物，並認真嘗試弄清楚我們如何使其運作，並意識到它實際上並不適用於我們的用例。”
Development principles 開發原則
The still-small team set up principles to ensure continuous progress:
這個仍然很小的團隊設立了原則，以確保持續進步:
No backward steps. Ease of use, scale, and feature developer experience, can not be worse than existing social networks’.
不要後退。使用、規模和功能開發者體驗的便利性，不能比現有社交網絡更糟。Unify app development with protocol development. Never make tech decisions in isolation from practical use cases.
通過協議開發統一應用程序開發。永遠不要在與實際用例隔離的情況下做技術決策。Don’t be precious! If an idea or design doesn’t work, just throw it out!
不要太在意！如果一個想法或設計不起作用，就把它丟掉！
Approach to building a new, novel decentralized protocol
建立新的、新穎的去中心化協議的方法
The team prioritized flexible design choices in order to not lock themselves into a technology, until they knew exactly what they were building. Not coupling the data layer too closely with Postgres is an example of this. See below.
團隊優先考慮靈活的設計選擇，以免將自己困在一種技術中，直到他們確切知道他們在建立什麼。不將數據層與 Postgres 過於緊密耦合就是一個例子。請參見下文。
Building for flexibility, not scalability, was deliberate. The idea was to swap this approach to prioritize scale once everyone knew exactly what to build. The knowledge that decisions are hard to undo made the team’s own decision-making more thorough, Daniel reflects:
建立靈活性，而非可擴展性，是有意的。這個想法是交換這種方法，優先考慮規模，一旦每個人確切知道要建立什麼。知道決策很難撤銷的認識使團隊自己的決策更加徹底，丹尼爾反思：
“The most difficult part of building Bluesky has been the constant awareness that small decisions you make may be locked in for years and have ripple effects. In a decentralized environment, these can be difficult to unwind. It puts a lot of weight on every decision, and we have to double and triple check choices that we make so that we hopefully don’t regret them.”
建立Bluesky最困難的部分是要不斷意識到你所做的小決定可能會鎖定多年並產生連鎖效應。在分散式環境中，這些決定可能很難解開。這讓每個決定都承擔著很大的壓力，我們必須仔細檢查我們所做的選擇，希望不會後悔。
Inventing new approaches was never a goal. The original idea was to take a protocol or technology off the shelf, and push it as far as possible to reveal a requirement that didn’t quite fit. For example, Lexicon – the schema used to define remote procedure call (RPC) methods and record types – started out as JSON schemas. The team tried hard to keep it lightweight, and stuck to JSON schemas. But they ended up bending over backwards to make it work. In the end, the team decided to fork off from JSON schemas and added features to it, which is how Lexicon was born.
發明新方法從來不是目標。最初的想法是從架構或技術中選取一個，並將其推進到極限，以揭示一個不太合適的需求。例如，Lexicon - 用於定義遠程過程調用（RPC）方法和記錄類型的模式 - 起初是 JSON 模式。團隊努力保持輕量級，堅持使用 JSON 模式。但他們最終不得不費盡心機使其運作。最終，團隊決定從 JSON 模式中分叉出來並為其添加功能，這就是 Lexicon 誕生的方式。
Bluesky gets criticism for inventing new approaches which are non-standard across decentralized networks. Paul explains it like this:
Bluesky 因為發明了在去中心化網絡中非標準的新方法而受到批評。保羅這樣解釋：
“We never set out to live the ‘not invented here’ (NIH) syndrome. I don’t think anyone building something new has this goal. In the end, it just naturally evolved in this direction.
“我們從來沒有設定過要過著‘這裡沒有人發明’（NIH）綜合症的生活。我不認為任何建立新事物的人都有這個目標。最終，它自然而然地演變成這個方向。No one had done a high-scale decentralized social network before this! If someone had, we probably wouldn’t have needed to invent as many things.”
在此之前，沒有人做過一個大規模的去中心化社交網絡！如果有人這樣做了，我們可能就不需要發明那麼多東西了。
Bluesky takes inspiration from existing web technologies. As Daniel puts it:
Bluesky 從現有的 Web 技術中汲取靈感。正如丹尼爾所說：
“The AT Protocol is a pretty typical JSON API collection over HTTP. The architecture of Bluesky looks very similar to a traditional social media data center turned inside out. The firehose API looks a lot like Kafka – and we’re probably going to shard it in a similar way.”
AT協議是一個相當典型的JSON API集合，通過HTTP進行。Bluesky的架構看起來非常類似於一個傳統的社交媒體數據中心被顛倒過來。firehose API看起來很像Kafka - 我們可能會以類似的方式進行分片。
3. v1 architecture: not really scalable and not federated – yet
v1架構：並非真正可擴展且非聯邦化 - 但是
Infrastructure choices 基礎設施選擇
PostgreSQL was the team’s database of choice when starting development. Postgres is often called the “Swiss Army knife of databases” because it’s speedy for development, great for prototyping, with a vast number of extensions. One drawback is that Postgres is a single bottleneck in the system, which can cause issues when scaling to handle massive loads that never materialize for most projects.
在開發初期，PostgreSQL 是團隊首選的資料庫。Postgres 常被稱為「資料庫中的瑞士軍刀」，因為它在開發時速度快，適合原型製作，並擁有大量的擴充功能。其中一個缺點是，Postgres 在系統中是單一瓶頸，這可能在擴展以處理從未實現的大量負載時出現問題，對於大多數專案來說這種情況並不常見。
For the team, using Postgres worked really well while they were unsure exactly what they were building, or how they would query things. Paul’s summary of the choice to use Postgres:
對於團隊來說，在他們不確定他們正在建造什麼，或者他們將如何查詢事物時，使用Postgres效果非常好。Paul對選擇使用Postgres的總結：
“You start with a giant Postgres database and see how far that can take you, so that you can move quickly early on.”
您從一個龐大的 Postgres 數據庫開始，看看它能帶您走多遠，這樣您就可以在早期快速移動。
AWS infrastructure was what the team started with because it’s quick to set up and easy to use, says Daniel:
團隊最初使用的是 AWS 基礎設施，因為它快速設置且易於使用，Daniel 表示：
“We were running everything out of AWS, and that is great because you can just spin up new VMs very easily, and spin up new stacks and services easily.”
我們當時在 AWS 上運行所有內容，這很棒，因為您可以非常輕鬆地啟動新的虛擬機器，並且可以輕鬆地啟動新的堆棧和服務。
The first infra hire at Bluesky, Jake Gold, iterated on the AWS setup:
在 Bluesky 的第一位基礎設施聘用者 Jake Gold 上對 AWS 設置進行了迭代：
“The basic idea we have right now is we’re using AWS, we have auto-scaling groups, and those auto-scaling groups are just EC2 instances running Docker Community Edition (CE) for the runtime and for containers. And then we have a load balancer in front and a Postgres multi-availability zone instance in the back on Relational Database Service (RDS). It’s a really simple setup.”
我們目前的基本構想是使用AWS，我們有自動擴展群組，這些自動擴展群組只是運行Docker Community Edition (CE) 作為運行時和容器的EC2實例。然後我們在前面有一個負載均衡器，在後面有一個在Relational Database Service (RDS)上的Postgres多可用區域實例。這是一個非常簡單的設置。
To facilitate deployments on AWS, the team used infrastructure-as-code service, Pulumi.
為了在 AWS 上進行部署，團隊使用了基礎設施即代碼服務 Pulumi。
Modularizing the architecture for an open network was an effort the team kicked off early. The goal of modularization was to spin out parts of the network which users could host themselves. Daniel says:
早期團隊努力將開放網絡的架構模塊化。模塊化的目標是將網絡的部分分離出來，讓用戶自行托管。丹尼爾說：
“Our early insight was that we should give developers building on top of Bluesky the ability to focus on the parts of the network that they want to focus on. This is the microservices part.
「我們早期的洞察是，我們應該讓在 Bluesky 上構建應用的開發人員能夠專注於他們想專注的網絡部分。這就是微服務的部分。An external developer building a feed should not need to index every “like” in the network. Someone self-hosting their own account should not need to consume thousands of posts to create a timeline. You can split the network into specific roles and have them work in concert.”
一位外部開發者建立一個訂閱應用程式時，不需要索引網絡中的每個「讚好」。自行託管自己的帳戶的人不需要消耗數千篇文章來建立時間軸。您可以將網絡分成特定角色，讓它們協同工作。
Personal Data Server 個人數據伺服器
At first, the architecture of Bluesky consisted of one centralized server, the PDS (Personal Data Server.)
起初，Bluesky 的架構由一個集中式伺服器組成，即 PDS（個人數據伺服器）。
2023年3月的Bluesky後端
The strategy was to split this centralized service into smaller parts and allow for federation, eventually.
這個集中服務的策略是將其分割為更小的部分，並最終允許聯邦化。
Bluesky being a federated network means individual users can run their own “Bluesky instance” and curate their own network.
Bluesky 作為一個聯邦化網絡意味著個人用戶可以運行自己的“Bluesky 實例”並管理自己的網絡。
The feed generator 資訊生成器
2023年5月後端，在將供稿生成器移至其自己的組件後。
In May 2023, the Bluesky team moved the feed generator to its own role. This service allows any developer to create a custom algorithm, and choose one to use. Developers can spin up a new Feed Generator service and make it discoverable to the Bluesky network, to add a new algorithm. Bluesky also allows users to choose from several predefined algorithms.
在2023年5月，Bluesky團隊將餵養生成器移至其自己的角色。此服務允許任何開發人員創建自定義算法，並選擇其中一個使用。開發人員可以啟動新的Feed Generator服務並使其可被Bluesky網絡發現，以添加新的算法。Bluesky還允許用戶從幾個預定義的算法中選擇。
The Feed Generator interface was the first case of Bluesky as a decentralized network. From then, the Bluesky network was not solely the services which the Bluesky team operated, it was also third-party services like Feed Generator instances that plugged into the Bluesky network.
Feed Generator介面是Bluesky作為去中心化網絡的第一個案例。從那時起，Bluesky網絡不僅僅是Bluesky團隊運營的服務，還包括像Feed Generator實例這樣的第三方服務，它們接入了Bluesky網絡。
Dedicated “Appview” service
專用的“Appview”服務
For the next step, the view logic was moved from the PDS, to an “Appview” service. This is a pretty standard approach for backend systems, to move everything view-related to its own service, and not to trouble other systems with presenting data to web and mobile applications.
對於下一步，視圖邏輯從 PDS 移至“Appview”服務。這是後端系統的一種標準方法，將所有與視圖相關的內容移至自己的服務，不會讓其他系統為向 Web 和移動應用程序呈現數據而困擾。
將應用程式視圖邏輯拆分為獨立服務
Relays to crawl the network
用於爬取網絡的中繼器
In the future, there could be hundreds or thousands of PDSs in the Bluesky network. So, how will all the data be synchronized with them? The answer is that a “crawler” will go through all these PDSs. In preparation for this crawl the team introduced a Relay service:
未來，Bluesky 網絡中可能會有數百或數千個 PDS。那麼，所有數據將如何與它們同步？答案是一個“爬蟲”將通過所有這些 PDS。為了準備這次爬行，團隊引入了一個中繼服務：
通過添加一個中繼服務來為聯邦和多個PDS做準備，以便稍後“爬行”。
4. v2 architecture: scaleable and federated
4. v2 架構：可擴展和聯邦
The v1 architecture needed to evolve in order to support full federation, and the team always planned to move on from it. But they expected v1 to last longer than only 6 months.
v1 架構需要進化以支持完整的聯邦，團隊一直計劃從中前進。但他們預期 v1 的壽命不止 6 個月。
Federation 聯邦
Federation sandbox. Before shipping a first version of federation, the team built a Federation Sandbox to test the architecture, as a safe space to try new features like modulation and curation tooling.
聯邦沙盒。在推出聯邦的第一個版本之前，團隊建立了一個聯邦沙盒來測試架構，作為一個安全的空間來嘗試新功能，如調製和整理工具。
Internal federation. To prepare for federation proper, the next refactoring was to add support for multiple Personal Data Servers. As a first step, the Bluesky team did this internally. Users noticed nothing of this transition, which was intentional, and Bluesky was then federated! Proving that federation worked was a large milestone.
內部聯邦。為了準備適當的聯邦，下一個重構是添加對多個個人數據服務器的支持。作為第一步，Bluesky 團隊在內部完成了這個任務。用戶對這一過渡一無所知，這是有意為之的，然後 Bluesky 就被聯邦起來了！證明聯邦運作正常是一個重要的里程碑。
As a reminder, federation was critical to Bluesky because it made the network truly distributed. With federation, any user can run their own Bluesky server.
作為提醒，聯邦對 Bluesky 至關重要，因為它使網絡真正分佈式。有了聯邦，任何用戶都可以運行自己的 Bluesky 伺服器。
在聯邦成立之前，Bluesky 創建了 10 個 PDS 服務，包裝成一個 Entryway 介面。
The “internally federated” PDS servers worked exactly like a self-hosted PDS. Bluesky made one addition, to wrap the internal PDS servers into a new service called “Entryway,” which provides the “bsky.social” identity to the PDSes. Entryway will become the “official” Bluesky OAuth authorization server for users who choose bsky.social servers, and one operated as a self-hosted server.
這些「內部聯邦」的 PDS 伺服器的運作方式與自託管的 PDS 完全相同。Bluesky 做了一個補充，將內部 PDS 伺服器包裝成一個名為「Entryway」的新服務，該服務為 PDS 提供「bsky.social」身份。Entryway 將成為選擇 bsky.social 伺服器的用戶的「官方」Bluesky OAuth 授權伺服器，以及一個作為自託管伺服器運作的伺服器。
Later, Bluesky increased the number of internal PDS servers from 10 to 20 for capacity reasons, and to test that adding PDS servers worked as expected.
後來，Bluesky 將內部 PDS 伺服器的數量從 10 增加到 20，以應對容量需求，並測試增加 PDS 伺服器是否按預期運作。
External federation. With everything ready to support self-hosted Personal Data Servers, Bluesky flipped to switch, and started to “crawl” those servers in February 2024:
外部聯邦。隨著一切準備就緒以支持自託管的個人數據服務器，Bluesky在2024年2月開始“爬行”這些服務器：
支援「正確」聯邦化。任何人都可以在 PDS 形式中自行託管「Bluesky 實例」。
To date, Bluesky has more than 300 self-hosted PDSs. This change has made the network properly distributed, anyone wanting to own their data on Bluesky can self-host an instance. Over time, we could also see services launch which self-host instances and allow for full data ownership in exchange for a fee.
迄今為止，Bluesky 擁有超過 300 個自行託管的 PDS。這一變化使網絡得以適當分佈，任何希望在 Bluesky 上擁有自己數據的人都可以自行託管一個實例。隨著時間的推移，我們還可能看到服務推出，這些服務將自行託管實例並以費用換取完整的數據所有權。
Appview: further refactoring
Appview:進一步重構
Recently, Bluesky further refactored its Appview service, and pulled out the moderation functionality into its own service, called Ozone:
最近，Bluesky 進一步重構了其 Appview 服務，並將審核功能提取到自己的服務中，稱為 Ozone:
將Appview中的適度移動和帖子標籤功能到Ozone
Users can run their own Ozone service – meaning to be a moderator in the Bluesky system. Here are details on how to self-host this service, and more about Ozone.
用戶可以運行自己的臭氧服務 - 這意味著在 Bluesky 系統中成為一名版主。以下是有關如何自行託管此服務以及有關臭氧的更多詳細信息。
An architectural overview, with Martin Kleppman
由 Martin Kleppman 進行的架構概述
Martin is the author of the popular software engineering book, Designing Data Intensive Applications, and he also advises the Bluesky team in weekly calls.
Martin 是廣受歡迎的軟件工程書籍《設計數據密集型應用》的作者，他還在每週的通話中為 Bluesky 團隊提供建議。
Martin and the Bluesky team published a paper describing the Bluesky system, Bluesky and the AT Protocol: Usable decentralized social media. In it, they offer a detailed overview of the architecture:
Martin和Bluesky團隊發表了一篇描述Bluesky系統、Bluesky和AT協議的論文：可用的去中心化社交媒體。在其中，他們提供了對架構的詳細概述：
Bluesky的建築。圖片來源：Bluesky和AT協議
The diagram above shows how data flows occur in the application:
上面的圖表顯示應用程式中數據流動的過程：
Personal data server (PDS): these can be Bluesky-hosted (around 20 today) or self-hosted (around 300)
個人數據伺服器（PDS）：這些可以是 Bluesky 提供的（目前約有 20 個）或自行託管的（目前約有 300 個）Relays: these collect events from the PDSs. Bluesky has its “official” relay hosted in its own infrastructure, but other developers can set up alternative relays that listen to all PDSs.
轉發器：這些從 PDS 收集事件。Bluesky 在自己的基礎設施中託管了其“官方”轉發器，但其他開發人員可以設置聆聽所有 PDS 的替代轉發器。Firehose: the output of the relays.
消防栓：中繼器的輸出。Labelers and feed generators: these digest firehose events. They can be Bluesky-hosted, or be hosted independently of Bluesky.
標籤和餵養生成器：這些消化消防栓事件。它們可以由 Bluesky 托管，也可以獨立於 Bluesky 之外托管。App View: The Bluesky-hosted “official” app view, or alternate app views
應用視圖：Bluesky 托管的“官方”應用視圖，或替代應用視圖。Data flowing back to PDSs: feed generators hosted by Bluesky or externally, feed events data back to the PDSs.
數據流回 PDSs：由 Bluesky 或外部託管的餵養生成器，將事件數據反饋給 PDSs。
5. Scaling the database layer
5. 擴展數據庫層
Scaling issues with Postgres
Postgres 的擴展問題
Scaling issues emerged 2-3 months after the public beta launch in mid-2023.
在 2023 年中期公共測試推出後的 2-3 個月後出現了擴展問題。
Connection pool issues and lock contention. The Postgres connection pool backup and Node’s event loop got into a bad feedback loop. The team observed Postgres lock contention issues. This refers to multiple processes trying to access the same data simultaneously, but the data is locked to all except one process. For example, when multiple processes attempt to update the same row.
連接池問題和鎖競爭。Postgres 連接池備份和 Node 的事件循環進入了一個不良反饋循環。團隊觀察到 Postgres 鎖競爭問題。這指的是多個進程同時嘗試訪問相同的數據，但數據對所有進程都被鎖定，只有一個進程可以訪問。例如，當多個進程嘗試更新同一行時。Small Postgres outages. Postgres doesn’t give the developer much control over which query plan it will take. Bluesky had a few smaller outages due to a query plan randomly flipping to something that ran about 1,000x times slower.
小型Postgres中斷。Postgres並不給開發人員太多控制權，以決定採用哪種查詢計劃。Bluesky曾因查詢計劃隨機切換至運行速度約慢1000倍的情況而出現幾次較小的中斷。The need for horizontal scaling. Horizontal scaling is adding more machines to a service, so that the throughput of this system improves linearly with each new machine. But Postgres does not support horizontal scaling because it runs as a single database with transactional guarantees, meaning it becomes a bottleneck – if a necessary one – for the entire network.
水平擴展的需求。水平擴展是向服務添加更多機器，使得系統的吞吐量隨著每台新機器的增加而線性提高。但是 Postgres 不支持水平擴展，因為它運行為具有事務保證的單個數據庫，這意味著它成為整個網絡的瓶頸 - 如果是必要的話。
As a reminder, the team was still tiny when all these scaling challenges emerged. There were only 6 developers (Daniel, Devin, Bryan and Jake on the backend, and Paul and Ansh on the frontend). Then in summer 2023, Daniel had a dream:
提醒一下，當所有這些擴展挑戰出現時，團隊仍然很小。只有 6 名開發人員（後端的 Daniel、Devin、Bryan 和 Jake，前端的 Paul 和 Ansh）。然後在 2023 年夏天，Daniel 做了一個夢：
“After one stressful day, I dreamt that me, Jay [Bluesky’s CEO], and Devin were in my backyard. There were snakes everywhere you looked. We were going to wrangle and round up the snakes in a panic. But that that point, Devin stops and says to all of us: ‘wait, wait, guys, I think there’s a Postgres extension for this!’”
“在一個緊張的一天之後，我夢見我、Jay（Bluesky 的 CEO）和 Devin 在我的後院。到處都是蛇。我們準備在恐慌中捕捉和圍捕蛇。但在那個時候，Devin 停下來對我們所有人說：‘等等，等等，伙計們，我覺得這裡有一個 Postgres 擴展可以處理這個！’”
ScyllaDB replacing Postgres
ScyllaDB 取代 Postgres
The team knew they needed a horizontally scalable data storage solution, with fine-grained control of how data is indexed and queried.
團隊知道他們需要一個水平可擴展的數據存儲解決方案，可以對數據的索引和查詢進行精細控制。
ScyllaDB was an obvious choice because it supports horizontal scalability due to being a wide-column database (a NoSQL type.) Wide-column databases store data in flexible columns that can be spread across multiple servers or database rows. They can also support two rows having different columns, which gives a lot more flexibility for data storage!
ScyllaDB 是一個明顯的選擇，因為它支持水平擴展，這是由於它是一種寬列數據庫（一種 NoSQL 類型）。寬列數據庫將數據存儲在靈活的列中，可以分佈在多個服務器或數據庫行中。它們還可以支持兩行具有不同列，這為數據存儲提供了更多的靈活性！
寬列數據庫將數據存儲在列中，因此具有高度可擴展性和靈活性。一個表中的兩行可以具有不同類型或數量的列。來源：AWS
The biggest tradeoffs: 最大的折衷：
Data must be denormalized, meaning it isn’t stored as efficiently as in a relational database. Basically, you’ll store more data and require more storage space.
數據必須進行去正規化，這意味著它的存儲效率不如關係型數據庫高。基本上，您將存儲更多數據並需要更多存儲空間。Data needs to be indexed on write. Writing to a wide column database is more expensive than to a relational database. For each row and column changed, the relevant indexes need to be updated, which typically makes these databases more write-intensive than relational ones.
寫入時需要對數據進行索引。寫入寬列數據庫比寫入關係型數據庫更昂貴。對於每個更改的行和列，相應的索引需要更新，這通常使這些數據庫比關係型數據庫更注重寫入。
The team was satisfied with their early choice of Postgres, says Daniel:
團隊對他們早期選擇的 Postgres 感到滿意，Daniel 說：
“Postgres was great early on because we didn’t quite know exactly what questions we’d be asking of the data. It let us toss data into the database and figure it out from there. Now we understand the data and the types of queries we need to run, it frees us up to index it in Scylla in exactly the manner we need and provide APIs for the exact queries we’ll be asking.”
“Postgres 在早期非常好，因為我們並不確切知道我們將對數據提出什麼問題。它讓我們將數據放入數據庫並從中找出答案。現在我們了解數據和我們需要運行的查詢類型，這使我們能夠按照我們需要的方式在 Scylla 中進行索引並為我們將要提出的確切查詢提供 API。”
SQLite
ScyllaDB is used for the Appview, which is Bluesky’s most read-heavy service. However, the Personal Data Servers use something else entirely: SQLite. This is a database written in the C language which stores the whole database in a single file on the host machine. SQLite is considered “zero configuration,” unlike most other databases that require service management – like startup scripts – or access control management. SQLite requires none of this and can be started up from a single process with no system administrative privileges. It “just works.”
ScyllaDB 用於 Appview，這是 Bluesky 最讀取量最大的服務。然而，個人數據伺服器則使用完全不同的東西：SQLite。這是一個用 C 語言編寫的數據庫，將整個數據庫存儲在主機機器上的單個文件中。SQLite 被認為是“零配置”，不像大多數其他需要服務管理（如啟動腳本）或訪問控制管理的數據庫。SQLite 不需要這些，可以從單個進程啟動，無需系統管理權限。它“只是運作”。
Daniel explains why SQLite was ideal for the PDSs:
Daniel 解釋了為什麼 SQLite 對於 PDSs 是理想的：
“We took a somewhat novel approach of giving every user their own SQLite database. By removing the Postgres dependency, we made it possible to run a ‘PDS in a box’ without having to worry about managing a database. We didn’t have to worry about things like replicas or failover. For those thinking this is irresponsible: don’t worry, we are backing up all the data on our PDSs!”
“我們採取了一種相對新穎的方法，為每個用戶提供了他們自己的 SQLite 數據庫。通過去除對 Postgres 的依賴，我們使得運行一個‘盒中的 PDS’成為可能，而無需擔心管理數據庫。我們不必擔心像副本或故障轉移之類的事情。對於那些認為這樣做是不負責任的人：別擔心，我們正在對我們的 PDSs 上的所有數據進行備份！”SQLite worked really well because the PDS – in its ideal form – is a single-tenant system. We owned up to that by having these single tenant SQLite databases.
SQLite非常適用，因為PDS在其理想形式下是一個單租戶系統。我們通過擁有這些單租戶SQLite數據庫來承認這一點。We also leaned into the fact that we’re building a federated network. We federated our data hosting in the exact same manner that it works for non-Bluesky PDSs.”
我們還深入了解到我們正在建立一個聯邦網絡。我們以與非 Bluesky PDSs 相同的方式聯邦化了我們的數據主機。
Migrating the PDSs from Postgre to SQLite created fantastic improvement in operations, Daniel adds:
將 PDSs 從 Postgre 遷移到 SQLite 在運營方面帶來了極大的改善，Daniel 補充道：
“PDSs have been a dream to run since this refactor. They are cheap to operate (no Postgres service!) and require virtually no operational overhead!”
自從進行了這次重構後，運行PDSs已經成為一個夢想。它們運營成本低廉（無需Postgres服務！），幾乎不需要任何運營開支！
6. Infra stack: from AWS to on-prem
6. 基礎架構：從 AWS 到本地
Bluesky’s infrastructure was initially hosted on Amazon Web Services (AWS) and the team used infrastructure-as-a-code service, Pulumi. This approach let them move quickly early on, and also to scale their infra as the network grew. Of course, as the network grew so did the infrastructure bill.
Bluesky的基礎設施最初是托管在Amazon Web Services（AWS）上，團隊使用基礎設施即代碼服務Pulumi。這種方法讓他們在早期快速移動，並在網絡擴大時擴展基礎設施。當然，隨著網絡的擴大，基礎設施費用也在增加。
Move to on-prem 遷移至本地部署
Cost and performance were the main drivers in moving on-prem. The team got hardware that was more than 10x as powerful as before, for a fraction of the price. How was this decision made? A key hire played a big role.
成本和性能是將本地部署的主要驅動因素。團隊獲得的硬件比以前強大了 10 倍以上，價格只是之前的一小部分。這個決定是如何做出的？一位關鍵的新員工發揮了重要作用。
Bluesky’s first hire with large-scale experience was Jake Gold, who joined in January 2023, and began a cost analysis of AWS versus on-prem. He eventually convinced the team to make this big change.
Bluesky 的第一位具有大規模經驗的新員工是 Jake Gold，他於 2023 年 1 月加入，開始對 AWS 與本地部署進行成本分析。最終他說服了團隊做出這個重大改變。
But how did the team forecast future load, and calculate the hardware footprint they’d need? Daniel recalls:
但團隊如何預測未來的負載，並計算他們所需的硬件配置？Daniel 回憶道：
“We looked at the trends and tried to make a safe bet. We were thinking: ‘okay, today we're over-provisioned. We want to stay over-provisioned, so we have room to grow without upgrading the hardware, but also just so we have stability if something happens in the world, and everyone decides to post about it.’
我們研究了趨勢，並試圖打一個安全的賭注。我們在想：「好吧，今天我們超額供應了。我們想保持超額供應，這樣我們就有空間可以成長，而不需要升級硬體，同時也確保如果世界發生了什麼事，每個人都決定發帖，我們也能保持穩定。"We built our architecture to be horizontally scalable so that we can add more capacity just by throwing more machines at it. There is some lead time to buying new machines, but we have space in the rack. We have room in the network connections. The switches are good for it.
我們的架構是橫向擴展的，這樣我們只需增加更多機器就可以增加容量。購買新機器需要一些時間，但我們機架上有空間。我們的網絡連接有空間。交換機可以應對。If we need to scale, it’s really just about ‘get some more servers and hook them up!’ We can get to twice the capacity after doubling the machines we’re running in our data center. This is sweet!”
如果我們需要擴展，其實就是「再增加一些伺服器並連接它們！」我們可以在數據中心運行的機器數量翻倍後，將容量提高一倍。這太棒了！
Becoming cloud-agonistic was the first step in moving off AWS. By June 2023, six months after Jake joined, Bluesky’s infrastructure was cloud agonistic.
成為雲端不可知論者是搬離 AWS 的第一步。2023 年 6 月，Jake 加入後的六個月，Bluesky 的基礎設施已經是雲端不可知論者。
Bluesky always has the option of using AWS to scale if needed, and is designed in a way that it would not be overly difficult to stand up additional virtual machines on AWS, if the existing infrastructure has capacity or scaling issues.
Bluesky 總是有使用 AWS 進行擴展的選項，如果需要的話，並且設計成這樣的方式，如果現有基礎設施有容量或擴展問題，則在 AWS 上啟動額外的虛擬機器不會過於困難。
Today, the Personal Data Servers are bare-metal servers hosted by cloud infrastructure vendor, Vultr. Bluesky currently operates 20 and shards them so that each PDS supports about 300,000 users.
如今，個人數據伺服器是由雲基礎設施供應商 Vultr 托管的裸機伺服器。Bluesky 目前運營 20 台並將它們分片，以便每個 PDS 支持約 30 萬用戶。
Bluesky’s load by the numbers
Bluesky 的負載數字
Currently, Bluesky’s system sees this sort of load:
目前，Bluesky 的系統看到這種負載：
60-100 events/second received by the firehose service, which is the “main” service that emits messages sent on the network in real time. During the public launch of Bluesky in February, the peak was 400 events/second.
每秒 60-100 個事件被 firehose 服務接收，這是“主”服務，實時發送在網絡上的消息。在二月份 Bluesky 的公開發布期間，峰值達到每秒 400 個事件。400 timeline loads/second. A timeline load is when a user (or client) makes a request to fetch their current timeline.
每秒載入400個時間軸。時間軸載入是指當用戶（或客戶端）發出請求以獲取其當前時間軸時。3,500 requests/second across the network.
每秒在網絡上處理3,500個請求。
7. Reality of building a social network
7. 建立社交網絡的現實
To close, we (Gergely and Elin) asked the teams some questions on what it’s like to build a high-growth social network.
最後，我們（Gergely 和 Elin）向團隊提出了一些問題，詢問他們建立高增長社交網絡的感受。
What is a typical firefighting issue you often encounter?
你經常遇到的典型消防問題是什麼？
“Every influx of users brought new problems, and we found ourselves doing quite a bit of firefighting. One day, after a particularly notable incident, growth showed no signs of stopping, and we had to temporarily disable signups in order to keep the service running.” – Daniel
"每次用戶湧入都帶來新問題，我們發現自己不得不應對大量的應急情況。有一天，在一次特別引人注目的事件之後，增長勢頭沒有停止的跡象，我們不得不暫時停止註冊以保持服務運行。" - 丹尼爾
What were the events referred to as “Elon Musk?”
所謂的“埃隆·馬斯克”事件是指什麼事件？
“We never quite knew when a user bump was going to come, and invites were out in the wild waiting to be used. Then something would happen, and thousands of users suddenly joined. We started referring to these days as EMEs (Elon Musk Events) because they were normally precipitated by some change on Twitter.” – Daniel
"我們從未確切知道用戶激增何時會發生，邀請碼在外面等待使用。然後會發生某些事情，成千上萬的用戶突然加入。我們開始將這些日子稱為 EMEs（埃隆·馬斯克事件），因為它們通常是由 Twitter 上的某些變化引起的。" - 丹尼爾“It was a bit like throwing a party and everybody showing up 2 hours early, while you’re still setting up the chairs and telling people to get drinks from the fridge. And then about ten times more people show up than expected.” – Paul
這有點像辦派對時，每個人都提早兩小時到場，而你還在擺放椅子，告訴人們從冰箱拿飲料。然後出乎意料地多了大約十倍的人。- 保羅
How are outages different for a social network?
網絡社交平台的故障有何不同？
“Disabling signups or pausing the service is never fun to do, but it actually created a bunch of excitement and a strange sense of pride in the user base.” – Daniel
“禁用註冊或暫停服務從來不是一件有趣的事情，但實際上卻在用戶群中引起了一陣興奮和一種奇怪的自豪感。” – Daniel“Outages are not fun, but they’re not life and death, generally. And if you look at the traffic, usually what happens is after an outage, traffic tends to go up. And a lot of people who joined, they’re just talking about the fun outage that they missed because they weren’t on the network.” – Jake
“故障並不有趣，但通常並非是生死攸關。而且如果你看看流量，通常故障後，流量往往會上升。許多加入的人只是在談論他們錯過的有趣故障，因為他們當時不在網絡上。” – Jake
The whole developer team is on Bluesky, and actively responding to user feedback. How do you do this, and why?
整個開發團隊都在 Bluesky 上，並積極回應用戶反饋。你是如何做到這一點的，為什麼？
“People just pinging us in the app and explaining their problem, is so good. We can just respond, "Hey, can you give me a screenshot? What platform are you on?" It's such a fast support turnaround. The big benefit of building a social app is that your customers are right there, and will tell you if something's not working.
「人們只需在應用程序中聯繫我們並解釋問題，這樣很好。我們可以立即回應，『嘿，你能給我一個截圖嗎？你在哪個平台上？』這樣的支援反饋速度很快。建立社交應用程序的一大好處是，您的客戶就在那裡，並且會告訴您如果有什麼問題。Real time user feedback was how mute words got prioritized, recently. In terms of a signal about how important something is, when you start getting PRs to add the feature, and you get a ton of people plus-oneing the issue – not to mention people asking for it in the app – that tells you a lot.” – Paul
實時用戶反饋是如何最近優先處理靜音詞的。就某事物的重要性發出的信號而言，當您開始收到要求添加該功能的PR時，以及有大量用戶對該問題表示支持，更不用說在應用程序中有人要求該功能時，這些都告訴您很多。- 保羅
Takeaways 外賣
Gergely here. Many thanks to Daniel and Paul for part one of this deep dive into how Bluesky works! You can try out Bluesky for yourself, learn more about Bluesky’s AT Protocol, or about its architecture. And I’m also on Bluesky.
Gergely在這裡。非常感謝Daniel和Paul為我們深入探討Bluesky運作方式的第一部分！您可以自行嘗試Bluesky，了解更多關於Bluesky的AT協議，或者關於其架構。而我也在Bluesky上。
Decentralized architectures require a different way of thinking. I’ll be honest, I’m so used to building and designing “centralized” architecture, that the thought of servers being operated outside of the company is very alien. My immediate thoughts were:
去中心化的架構需要不同的思維方式。坦白說，我習慣於構建和設計“中心化”的架構，因此公司外運營伺服器的想法對我來說非常陌生。我的第一反應是：
Is it secure enough? Malicious actors could run anything on those servers and attempt to overload the network or exploit vulnerabilities in the system. The Bluesky team also stressed how the security model is something you thoroughly need to consider as you design APIs for such a system.
這是否足夠安全？惡意行為者可能在這些伺服器上運行任何內容，並嘗試過載網絡或利用系統中的漏洞。Bluesky團隊還強調了安全模型是您在為這樣的系統設計API時需要仔細考慮的事項。What about external nodes that don’t ever update the version of the software? How do they get bug fixes? And what about versioning? How to ensure “outdated clients” are cut off from the network?
那些從不更新軟體版本的外部節點怎麼辦？它們如何獲得錯誤修復？版本控制又如何確保「過時的客戶端」被切斷與網絡的聯繫？Finally, I thought; “wow, this kind of reminds me of the confusion I initially felt about Skype’s peer-to-peer network”
最後，我想：“哇，這有點讓我想起我最初對Skype的點對點網絡感到困惑的時候”。
I’m delighted we did a deep dive about Bluesky because it has forced me to think more broadly. A server drawing on a diagram no longer just means “a group of our servers,” it can also mean “plus, a group of external servers.” Once this is understood, it’s easy. And this skill of designing distributed and federated systems may be useful in the future, as I expect the concept of distributed architecture to become more popular.
我很高興我們對Bluesky進行了深入探討，因為這迫使我更加廣泛地思考。在圖表上繪製的伺服器不再僅僅意味著“我們的一組伺服器”，它也可以意味著“再加上一組外部伺服器”。一旦理解了這一點，就很容易了。而設計分佈式和聯邦系統的這種技能可能在未來很有用，因為我預計分佈式架構的概念將變得更加流行。
It’s impressive what a tiny team of experienced engineers can build. I had to triple-check that Bluesky’s core team was only two engineers for almost nine months, during which time they built the basics of the protocol, and made progress with the iOS and Android apps. Even now, Bluesky is a very lean team of around 12 engineers for the complexity they build with and the company’s growth.
一支經驗豐富的小型工程團隊所能建造的令人印象深刻。在接近九個月的時間裡，我不得不三次確認Bluesky的核心團隊只有兩名工程師，他們在此期間建立了協議的基礎，並在iOS和Android應用程式上取得了進展。即使現在，Bluesky仍然是一支非常精簡的團隊，大約有12名工程師，他們處理的複雜性和公司的成長。
In the next part of this deep dive into Bluesky, we cover more on how the team works.
在這次深入探討 Bluesky 的下一部分中，我們將更多地探討團隊的工作方式。
Owning your own infrastructure instead of using the cloud seems a rational choice. Bluesky found large savings by moving off AWS once they could forecast the type of load they needed. Jake Gold, the engineer driving this transition, has been vocal about how cloud providers have become more expensive than many people realize. Speaking on the podcast, Last Week in AWS, he said:
擁有自己的基礎設施而不使用雲端看起來是一個理性的選擇。Bluesky 發現，一旦他們能夠預測所需的負載類型，從 AWS 離開後節省了大量費用。推動這一轉變的工程師 Jake Gold 對於雲端服務提供商變得比許多人意識到的更昂貴一事一直有所發言。在播客節目《上週 AWS》中，他說：
“With the original vision of AWS I first started using in 2006, or whenever launched, they said they would lower your bill every so often, as Moore’s law makes their bill lower. And that kind of happened a little bit here and there, but it hasn’t happened to the same degree as I think we all hoped it would.”
憑著 AWS 最初的願景，我在 2006 年或者推出時開始使用，他們說他們會不時降低您的費用，因為摩爾定律使他們的費用降低。這種情況有時候確實發生了一點，但我認為我們都希望的程度並沒有實現。
Don’t forget, it’s not only Bluesky which rejects cloud providers for efficiency. We previously did a deep dive into travel booking platform Agoda, and why it isn’t on the cloud.
不要忘記，不僅是Bluesky因效率而拒絕雲服務提供商。我們之前深入研究過旅行預訂平台Agoda，以及它為何不使用雲端。
I’m slowly changing my mind about decentralized and federated social networks. I also tried out Mastodon, which is another federated social network, when it launched. At the time, Mastodon felt a lot more clunky in onboarding than Bluesky. You had to choose a server to use, but different servers have different rules, whereas Bluesky was much smoother. Still, as a user, I was blissfully unaware of how different these social networks are from the dominant platforms.
我對去中心化和聯邦式社交網絡的看法正在慢慢改變。當Mastodon推出時，我也試用過這個另一個聯邦式社交網絡。當時，Mastodon 的入門體驗比Bluesky 更加笨拙。你必須選擇一個伺服器來使用，但不同的伺服器有不同的規則，而Bluesky 則順暢得多。然而，作為用戶，我對這些社交網絡與主流平台有多大不同毫不知情。
It was only by learning about Bluesky’s architecture that I appreciated the design goals of a decentralized social network. Currently, mainstream social networks are operated exclusively by the company that owns them. But a decentralized network allows servers to be operated by other teams/organizations/individuals. This might not seem like a big deal, but it means a social network is no longer dependent on the moderation policies of a parent company.
只有通過了解 Bluesky 的架構，我才能欣賞去中心化社交網絡的設計目標。目前，主流社交網絡僅由擁有它們的公司運營。但去中心化網絡允許其他團隊/組織/個人運營服務器。這可能看起來不是什麼大不了的事，但這意味著社交網絡不再依賴於母公司的管理政策。
Decentralized social networks also allows users to use custom algorithms, websites and mobile apps, which creates opportunities for developers to build innovative experiences. In contrast, you cannot build a custom third-party client for X, Threads, or LinkedIn.
去中心化社交網絡也允許用戶使用自定義算法、網站和移動應用程序，這為開發人員構建創新體驗創造了機會。相比之下，你無法為X、Threads或LinkedIn構建自定義第三方客戶端。
I’m still unsure how much mainstream appeal decentralized social networks hold for non-technical people, but I’m rooting for Bluesky, Mastodon, and the other decentralized social apps. Perhaps they can challenge Big Tech’s dominance of social media, or at least change people’s understanding of what a social network can be.
我仍然不確定去中心化社交網絡對非技術人員有多少主流吸引力，但我支持 Bluesky、Mastodon 和其他去中心化社交應用。也許它們可以挑戰大型科技公司對社交媒體的主導地位，或者至少改變人們對社交網絡的理解。
In a follow-up issue, we’ll look deeper into the engineering culture at Bluesky: the company culture, a deeper look at the tech stack, and how they are building seemingly so much with a surprisingly small team and company. I suspect we can all learn a lot in how a dozen engineers help a startup scale to more than 5 million users.
在後續問題中，我們將更深入地研究 Bluesky 的工程文化：公司文化、技術堆棧的更深入了解，以及他們如何用一支看似很小的團隊和公司建立如此多的東西。我懷疑我們都可以從十幾名工程師如何幫助一家初創公司擴展到超過 500 萬用戶中學到很多。
Enjoyed this issue? Subscribe to get this newsletter every week 👇
喜歡這期嗎？訂閱以每週收到這份通訊👇
 | A guest post by 由一位訪客發表
|
