【后端開發】系統設計101——Devops，Git與CICD，云服務與云原生，Linux，安全性，案例研究（30張圖詳解）

用圖像和簡單語言解釋復雜系統。
參考資料： 1, 2， 3

文章目錄
1、Devops
DevOps與SRE與平臺工程的區別是什么？
什么是k8s（Kubernetes）？
Docker與Kubernetes。我們應該使用哪個？
Docker是如何工作的？
開發者生產力工具
2、Git與CICD
Git命令的工作原理
Git是如何工作的？
Git合并與Git變基
簡單介紹CI/CD流程
Netflix技術棧（CI/CD流程）
3、云服務與云原生
各種云服務的好用備忘單（2023版）
什么是云原生？
4、Linux
解釋Linux文件系統
你應該知道的18個最常用的Linux命令
5、安全性
HTTPS是如何工作的？（非對稱傳秘鑰，對稱傳數據）
用簡單的術語解釋 Oauth2.0（第三方wx/qq登錄）
認證機制的四種主要形式（SSH，Oauth，SSL，Cert）
Session、cookie、JWT、token、SSO和OAuth 2.0 - 它們是什么？
如何安全地在數據庫中存儲密碼以及如何驗證密碼？
用通俗易懂的語言解釋JSON Web Token（JWT）
Google Authenticator（或其他類型的兩步驗證器）是如何工作的？
6、常見架構（9張）
Netflix的技術棧
Twitter 2022年的架構
Airbnb過去15年中微服務架構的演變
Monorepo vs. Microrepo
你會如何設計Stack Overflow網站？
為什么Amazon Prime Video的監控從無服務器轉向單體應用？如何節省90%的成本？
Disney Hotstar如何在錦標賽期間捕捉50億個表情符號？
Discord如何存儲數萬億條消息
YouTube、TikTok Live或Twitch上的視頻直播是如何工作的？

1、Devops

DevOps與SRE與平臺工程的區別是什么？

DevOps、SRE和平臺工程的概念是在不同的時間出現的，并由各個個人和組織進行了發展。

• DevOps作為一個概念于2009年由Patrick Debois和Andrew Shafer在敏捷大會上提出。他們試圖通過促進協作文化和共同負責整個軟件開發生命周期來彌合軟件開發和運營之間的差距。
• SRE或站點可靠性工程是由Google在2000年代初引入的，旨在解決管理大規模復雜系統的運營挑戰。Google開發了SRE實踐和工具，例如Borg集群管理系統和Monarch監控系統，以提高其服務的可靠性和效率。
• 平臺工程是一個更為新近的概念，建立在SRE工程的基礎之上。平臺工程的確切起源不太清楚，但它通常被理解為DevOps和SRE實踐的擴展，重點是提供一個全面支持整個業務視角的產品開發平臺。

值得注意的是，盡管這些概念在不同的時間出現，但它們都與改進軟件開發和運營中的協作、自動化和效率的廣泛趨勢相關。

什么是k8s（Kubernetes）？

K8s是一個容器編排系統，用于容器的部署和管理。它的設計受到了Google內部系統Borg的影響。

• 一個k8s集群
  由一組運行容器化應用程序的工作節點（稱為節點）組成。每個集群至少有一個工作節點。

• 工作節點托管Pod
  這些Pod是應用程序工作負載的組成部分。
  控制平面管理集群中的工作節點和Pod。
  在生產環境中，控制平面通常跨多臺計算機運行，集群通常運行多個節點，提供容錯和高可用性。

• 控制平面組件

• API服務器：
  API服務器與k8s集群中的所有組件進行通信。所有pod的操作都通過與API服務器通信執行。

• 調度器：
  調度器觀察Pod的工作負載，并將負載分配給新創建的Pod。

• 控制器管理器
  控制器管理器運行控制器，包括Node Controller，Job Controller，EndpointSlice Controller和ServiceAccount Controller等。

• Etcd
  etcd是一個鍵值存儲，用作Kubernetes的后備存儲器，用于存儲所有集群數據。

• 節點 Pod
  Pod是一組容器，是k8s管理的最小單位。Pod具有應用于Pod中每個容器的單個IP地址。

• Kubelet
  在集群中的每個節點上運行的代理。它確保容器在Pod中運行。

• Kube Proxy
  Kube-proxy是一個網絡代理，運行在集群中的每個節點上。它將從服務進入節點的流量路由到正確的容器。它將請求轉發到正確的容器，以便執行工作。

Docker與Kubernetes。我們應該使用哪個？

什么是Docker？

• Docker是一個開源平臺，允許您在隔離的容器中打包、分發和運行應用程序。
• 它專注于容器化，提供輕量級環境，封裝應用程序及其依賴項。

什么是Kubernetes？

• Kubernetes，通常稱為K8s，是一個開源容器編排平臺。
• 它提供了一個框架，用于自動化部署、擴展和管理容器化應用程序跨節點的集群。

它們之間有什么不同？

• Docker：Docker在單個操作系統主機上的單個容器級別操作。
  您必須手動管理每個主機，為多個相關容器設置網絡、安全策略和存儲可能會很復雜。
• Kubernetes：Kubernetes在集群級別上運行。它管理多個容器化應用程序跨多個主機，提供自動化的任務，如負載平衡、擴展和確保應用程序的期望狀態。
  簡而言之，Docker專注于容器化和在單個主機上運行容器，而Kubernetes專門管理和編排容器在跨多個主機的集群中運行。

Docker是如何工作的？

Docker的架構以及當我們運行 “docker build”、“docker pull” 和 “docker run” 時它是如何工作的。

Docker架構有三個組件：

• Docker客戶端
  Docker客戶端與Docker守護進程通信。
• Docker宿主機
  Docker守護進程監聽Docker API請求，并管理Docker對象，如鏡像、容器、網絡和卷。
• Docker注冊表
  Docker注冊表存儲Docker鏡像。Docker Hub是一個公共注冊表，任何人都可以使用。

讓我們以“docker run”命令為例。

• Docker從注冊表中拉取鏡像。
• Docker創建一個新的容器。
• Docker為容器分配一個讀寫文件系統。
• Docker創建一個網絡接口，將容器連接到默認網絡。
• Docker啟動容器。

開發者生產力工具

自動將代碼轉換為架構圖？

• 用Python代碼繪制云系統架構。
• 圖表也可以在Jupyter筆記本中直接呈現。
• 不需要設計工具。
• 支持以下提供商：AWS、Azure、GCP、Kubernetes、阿里云、Oracle Cloud等。

可視化JSON文件

• 嵌套的JSON文件很難閱讀。
• JsonCrack從JSON文件生成圖形圖表，使其易于閱讀。
• 此外，生成的圖表可以下載為圖像。

2、Git與CICD

Git命令的工作原理

首先，必須確定我們的代碼存儲在哪里。

• 通常認為只有兩個位置 - 一個是在像Github這樣的遠程服務器上，另一個是在我們的本地計算機上。然而，這并不完全準確。

Git在我們的計算機上維護了三個本地存儲。這意味著我們的代碼可以在四個位置找到：

• 工作目錄：我們編輯文件的地方，此時會跟暫存區的文件做diff，git add以后丟到暫存區。
• 暫存區：一個臨時位置，文件被保存在這里以供下一次提交使用。commit以后丟到本地倉庫。
• 本地倉庫：包含已提交的代碼。
• 遠程倉庫：存儲代碼的遠程服務器。

大多數Git命令主要在這四個位置之間移動文件。

Git是如何工作的？

Git是一種分布式版本控制系統。

每個開發者都維護著主倉庫的本地副本，并對其進行編輯和提交。

由于操作不涉及遠程倉庫，因此提交非常快速。

如果遠程倉庫崩潰，可以從本地倉庫恢復文件。

Git合并與Git變基

當我們將一個Git分支的更改合并到另一個分支時，可以使用“git merge”或“git rebase”。
下面的圖表展示了這兩個命令的工作方式。

Git合并

• 這將在主分支中創建一個新的提交G’。G’將主分支和功能分支的歷史記錄聯系起來。
• Git合并是非破壞性的。主分支和功能分支都不會被更改。

Git變基

• Git變基將功能分支的歷史記錄移動到主分支的頭部。它為功能分支中的每個提交創建新的提交E’、F’和G’。
• 使用變基的好處是它具有線性的提交歷史記錄。
• 如果不遵循“Git變基的黃金法則”，它可能會帶來風險。

Git變基的黃金法則

• 永遠不要在公共分支上使用它！

簡單介紹CI/CD流程

第一部分 - 帶有 CI/CD 的 SDLC

• 軟件開發生命周期（SDLC）包括幾個關鍵階段：開發，測試，部署和維護。 CI / CD自動化并集成了這些階段，以實現更快速和可靠的發布。
• 當代碼被推送到git存儲庫時，它會觸發自動構建和測試過程。運行端到端（e2e）測試用例以驗證代碼。如果測試通過，則代碼可以自動部署到staging / production。如果發現問題，則將代碼發送回開發以修復錯誤。此自動化為開發人員提供了快速反饋，并減少了生產中錯誤的風險。

第二部分 - CI和CD之間的區別

• 持續集成（CI - Continuous Integration）自動化構建，測試和合并過程。每當提交代碼以盡早檢測集成問題時，它都會運行測試。這鼓勵頻繁的代碼提交和快速反饋。
• 持續交付（CD- Continuous Delivery）自動化發布流程，如基礎架構更改和部署。它確保軟件可以通過自動化工作流程可靠地隨時發布。 CD還可以自動化生產部署之前需要的手動測試和批準步驟。

第三部分 - CI/CD 管道
典型的 CI/CD 管道具有幾個連接的階段：

• 開發人員提交代碼更改以進行源控制
• CI服務器檢測更改并觸發構建
• 編譯代碼并進行測試（單元測試，集成測試）
• 測試結果報告給開發人員
• 成功后，工件將部署到staging環境
• 在發布之前可能會在staging上進行進一步測試
• CD系統將批準的更改部署到生產中

Netflix技術棧（CI/CD流程）

計劃：Netflix工程團隊使用JIRA進行計劃，使用Confluence進行文檔編寫。

編碼：Java是后端服務的主要編程語言，而其他語言則用于不同的用例。

構建：Gradle主要用于構建，而Gradle插件則用于支持各種用例。

打包：將包和依賴項打包成Amazon Machine Image（AMI）進行發布。

測試：測試強調生產文化對構建混沌工具的關注。

部署：Netflix使用其自行構建的Spinnaker進行金絲雀發布部署。

監控：監控指標集中在Atlas中，使用Kayenta檢測異常。

事件報告：事件按優先級分派，使用PagerDuty進行事件處理。

3、云服務與云原生

各種云服務的好用備忘單（2023版）

什么是云原生？

下面是一張圖表，展示了自1980年代以來體系結構和流程的演變。
組織可以使用云原生技術在公共、私有和混合云上構建和運行可擴展的應用程序。
這意味著應用程序被設計為利用云特性，因此它們對負載具有彈性并且易于擴展。

云原生包括四個方面：

• 開發流程：這已經從瀑布流發展到敏捷開發到DevOps。
• 應用程序架構：架構已經從單片式發展到微服務。每個服務都被設計為小巧，適應云容器中有限的資源。
• 部署和打包：應用程序曾經部署在物理服務器上。然后在2000年左右，那些不敏感于延遲的應用程序通常部署在虛擬服務器上。使用云原生應用程序，它們被打包成Docker鏡像并部署在容器中。
• 應用程序基礎設施：應用程序大規模部署在云基礎設施上，而不是自托管服務器上。

4、Linux

解釋Linux文件系統

Linux文件系統曾經類似于一個無組織的城鎮，個人可以在任何地方建造自己的房屋。然而，1994年引入了文件系統層次結構標準（FHS），以規范Linux文件系統。

通過實施像FHS這樣的標準，軟件可以確保在各種Linux發行版中具有一致的布局。然而，并不是所有的Linux發行版都嚴格遵循這個標準。它們經常包含自己獨特的元素或迎合特定的需求。

要熟練掌握這個標準，你可以從探索開始。利用“cd”命令進行導航和“ls”命令列出目錄內容。想象文件系統就像一棵樹，從根目錄（/）開始。隨著時間的推移，它將變得自然而然，使你成為一名熟練的Linux管理員。

你應該知道的18個最常用的Linux命令

Linux命令是與操作系統交互的指令。它們有助于管理文件、目錄、系統進程和系統的許多其他方面。為了有效地導航和維護基于Linux的系統，你需要熟悉這些命令。

以下圖表顯示了常用的Linux命令：

• ls - 列出文件和目錄
• cd - 更改當前目錄
• mkdir - 創建新目錄
• rm - 刪除文件或目錄
• cp - 復制文件或目錄
• mv - 移動或重命名文件或目錄
• chmod - 更改文件或目錄權限
• grep - 在文件中搜索模式
• find - 搜索文件和目錄
• tar - 操作tarball歸檔文件
• vi - 使用文本編輯器編輯文件
• cat - 顯示文件內容
• top - 顯示進程和資源使用情況
• ps - 顯示進程信息
• kill - 通過發送信號終止進程
• du - 估算文件空間使用量
• ifconfig - 配置網絡接口
• ping - 在主機之間測試網絡連接

5、安全性

HTTPS是如何工作的？（非對稱傳秘鑰，對稱傳數據）

超文本傳輸安全協議（HTTPS）是超文本傳輸協議（HTTP）的擴展。HTTPS使用傳輸層安全協議（TLS）傳輸加密數據。如果數據在在線上被劫持，劫持者只能獲得二進制代碼。

數據是如何加密和解密的？

• 步驟1 - 客戶端（瀏覽器）和服務器建立TCP連接。
• 步驟2 - 客戶端向服務器發送“客戶端hello”消息。該消息包含一組必要的加密算法（密碼套件）和它支持的最新TLS版本。
  服務器響應一個“服務器hello”，以使瀏覽器知道它是否支持這些算法和TLS版本。
  然后，服務器向客戶端發送SSL證書。該證書包含公鑰、主機名、過期日期等。客戶端驗證證書。
• 步驟3 - 在驗證SSL證書后，客戶端生成一個會話密鑰，并使用公鑰對其進行加密。服務器接收加密的會話密鑰，并使用私鑰對其進行解密。
• 步驟4 - 現在，客戶端和服務器都持有相同的會話密鑰（對稱加密），加密數據在一個安全的雙向通道中傳輸。

為什么HTTPS在數據傳輸期間要切換到對稱加密？ 有兩個主要原因：

• 安全性：非對稱加密只能單向進行。這意味著如果服務器試圖將加密數據發送回客戶端，任何人都可以使用公鑰解密數據。（同時任何人都可以用服務器的公鑰偽造返回數據）
• 服務器資源：非對稱加密增加了相當多的數學開銷。它不適用于長時間會話中的數據傳輸。

用簡單的術語解釋 Oauth2.0（第三方wx/qq登錄）

OAuth 2.0 是一個強大且安全的框架，可以讓不同的應用程序代表用戶在不共享敏感憑證的情況下安全地互相交互。

OAuth 涉及的實體有用戶、服務器和身份提供者（IDP）。

OAuth Token 可以做什么？

• 當您使用 OAuth 時，您會獲得一個代表您身份和權限的 OAuth Token。該 Token 可以做一些重要的事情：
• 單點登錄（SSO）：使用 OAuth Token，您可以只使用一個登錄即可登錄多個服務或應用程序，讓您的生活更加輕松和安全。
• 系統間授權：OAuth Token 允許您在各個系統之間共享您的授權或訪問權限，因此您不必在各處單獨登錄。
• 訪問用戶資料：具有 OAuth Token 的應用程序可以訪問您允許的某些用戶資料的部分內容，但不會查看全部。
• 請記住，OAuth 2.0 的目的是在不同的應用程序和服務之間使您的在線體驗無縫、無憂，并保護您和您的數據的安全。

1

認證機制的四種主要形式（SSH，Oauth，SSL，Cert）

• SSH 密鑰： 用于安全地訪問遠程系統和服務器的加密密鑰
• OAuth Tokens : 提供對第三方應用程序上用戶數據的有限訪問權限的令牌
• SSL 證書： 數字證書確保服務器和客戶端之間的通信安全和加密
• Credentials憑證： 用戶身份驗證信息用于驗證并授予對各種系統和服務的訪問權限

Session、cookie、JWT、token、SSO和OAuth 2.0 - 它們是什么？

這些術語都與用戶身份管理相關。
當您登錄網站時，您聲明了自己的身份（識別）。您的身份將得到驗證（認證），并被授予必要的權限（授權）。
過去提出了許多解決方案，這個列表還在不斷增長。

從簡單到復雜，這是我對用戶身份管理的理解：

• WWW-Authenticate是最基本的方法。瀏覽器會要求您輸入用戶名和密碼。由于無法控制登錄生命周期，它現在很少使用。
• Session-Cookie可以更細致地控制登錄生命周期。服務器維護會話存儲，瀏覽器保留會話ID。Cookie通常只適用于瀏覽器，不適用于移動應用程序。
• 為了解決兼容性問題，可以使用Token。客戶端將Token發送到服務器，服務器驗證Token。缺點是Token需要加密和解密，可能會耗費時間。
• JWT是表示Token的標準方式。這些信息可以得到驗證和信任，因為它們是數字簽名的。由于JWT包含簽名，因此不需要在服務器端保存會話信息。
• 通過使用SSO（單點登錄），您只需登錄一次即可登錄多個網站。它使用CAS（中央認證服務）來維護跨站點信息。
• 通過使用OAuth 2.0，您可以授權一個網站訪問另一個網站上的您的信息。

如何安全地在數據庫中存儲密碼以及如何驗證密碼？

不應該做的事情

• 存儲明文密碼不是一個好主意，因為任何有內部訪問權限的人都可以看到它們。
• 直接存儲密碼哈希不足夠安全，因為它容易受到預計算攻擊，如彩虹表攻擊。
• 為了減輕預計算攻擊，我們對密碼進行加鹽處理。

什么是鹽？

• 根據OWASP指南，“鹽是在哈希過程中作為唯一隨機生成的字符串添加到每個密碼中的一部分”。

如何存儲密碼和鹽？

• 哈希結果對于每個密碼都是唯一的。
• 可以使用以下格式將密碼存儲在數據庫中：hash(password + salt)。

如何驗證密碼？

• 要驗證密碼，可以進行以下過程：
• 客戶端輸入密碼。
• 系統從數據庫中獲取相應的鹽。
• 系統將鹽附加到密碼上并進行哈希處理。我們稱哈希值為H1。
• 系統比較H1和H2，其中H2是存儲在數據庫中的哈希值。如果它們相同，則密碼有效。

用通俗易懂的語言解釋JSON Web Token（JWT）

想象一下，你有一個特殊的盒子，叫做JWT。在這個盒子里，有三個部分：頭部、載荷和簽名。

• 頭部就像盒子外面的標簽。
  它告訴我們盒子的類型和如何保證安全。
  它通常采用JSON格式編寫，JSON是一種使用花括號{ }和冒號:來組織信息的方式。

• 載荷就像你想要發送的實際信息或數據。
  它可以是你的姓名、年齡或任何你想要分享的數據。
  它也以JSON格式編寫，因此易于理解和處理。

• 現在，簽名是使JWT安全的關鍵。
  它就像一個特殊的印章，只有發送者知道如何創建。
  簽名是使用秘密代碼創建的，有點像密碼。
  這個簽名確保沒有人可以在發送者不知道的情況下篡改JWT的內容。

當你想要將JWT發送到服務器時，你將頭部、載荷和簽名放在盒子里。
然后你將它發送到服務器。
服務器可以輕松地讀取頭部和載荷，以了解你是誰以及你想要做什么。

Google Authenticator（或其他類型的兩步驗證器）是如何工作的？

Google Authenticator通常用于啟用2因素身份驗證時登錄我們的帳戶。它如何保證安全？
Google Authenticator是一種基于軟件的驗證器，實現了2FA兩步驗證服務。以下圖表提供了詳細信息。

這里涉及到兩個階段：

• 階段1 - 用戶啟用谷歌兩步驗證。
• 階段2 - 用戶使用驗證器進行登錄等操作。

階段1

• 步驟1和2：Bob打開網頁啟用兩步驗證。前端請求一個秘密密鑰。認證服務為Bob生成秘密密鑰并將其存儲在數據庫中。
• 步驟3：認證服務向前端返回一個URI。URI由密鑰發行者、用戶名和秘密密鑰組成。URI以QR碼的形式顯示在網頁上。
• 步驟4：然后Bob使用Google Authenticator掃描生成的QR碼。秘密密鑰存儲在驗證器中。

階段2

• 步驟1和2：Bob想要使用谷歌兩步驗證登錄網站。為此，他需要密碼。每30秒，Google Authenticator使用TOTP（基于時間的一次性密碼）算法生成一個6位數字密碼。
  Bob使用密碼進入網站。
• 步驟3和4：前端將Bob輸入的密碼發送到后端進行身份驗證。認證服務從數據庫中讀取秘密密鑰，并使用與客戶端相同的TOTP算法生成一個6位數字密碼。
• 步驟5：認證服務比較客戶端和服務器生成的兩個密碼，并將比較結果返回給前端。只有兩個密碼匹配時，Bob才能繼續登錄過程。

這種身份驗證機制安全嗎？其他人能否獲取秘密密鑰？

• 我們需要確保使用HTTPS傳輸秘密密鑰。
• 驗證器客戶端和數據庫存儲秘密密鑰，我們需要確保秘密密鑰已加密。

黑客能否猜測6位數字密碼？

• 不行。密碼有6位數字，因此生成的密碼有100萬個潛在組合。
• 此外，密碼每30秒變一次。如果黑客想在30秒內猜測密碼，他們需要每秒輸入30,000個組合。

6、常見架構（9張）

Netflix的技術棧

移動端和Web端：Netflix采用Swift和Kotlin構建本地移動應用程序。對于Web應用程序，它使用React。

前端/服務器通信：Netflix使用GraphQL。

后端服務：Netflix依賴于ZUUL、Eureka、Spring Boot框架和其他技術。

數據庫：Netflix利用EV Cache、Cassandra、CockroachDB和其他數據庫。

消息/流處理：Netflix使用Apache Kafka和Fink進行消息和流處理。

視頻存儲：Netflix使用S3和Open Connect進行視頻存儲。

數據處理：Netflix利用Flink和Spark進行數據處理，然后使用Tableau進行可視化。Redshift用于處理結構化數據倉庫信息。

CI/CD：Netflix采用各種工具，如JIRA、Confluence、PagerDuty、Jenkins、Gradle、Chaos Monkey、Spinnaker、Atlas等進行CI/CD流程。

Twitter 2022年的架構

是的，這是真正的 Twitter 架構。它由 Elon Musk 發布，我們重新繪制以提高可讀性。

Airbnb過去15年中微服務架構的演變

Airbnb的微服務架構經歷了三個主要階段。

單體架構（2008-2017）

• Airbnb最初只是一個簡單的房東和客人市場。這是在Ruby on Rails應用程序中構建的 - 單體架構。
• 面臨的挑戰是什么？
  團隊所有權混淆+未擁有的代碼
  部署緩慢

微服務（2017-2020）

• 微服務旨在解決這些挑戰。
• 在微服務架構中，關鍵服務包括：
  數據獲取服務
  業務邏輯數據服務
  寫工作流服務
  UI聚合服務
  每個服務都有一個擁有團隊
• 面臨的挑戰是什么？
  數百個服務和依賴項對人類來說很難管理。

微服務+宏服務（2020-現在）

• 這是Airbnb目前正在研究的。微服務和宏服務混合模型的重點是API的統一。

Monorepo vs. Microrepo

微服務倉庫Microrepo 和 宏服務倉庫Monorepo

Monorepo 和 Microrepo 是兩種不同的代碼庫管理方法。
哪個是最好的？為什么不同的公司選擇不同的選項？

對比

• Monorepo并不是新的概念，Linux和Windows都是使用Monorepo創建的。
  為了提高可擴展性和構建速度，谷歌開發了內部專用工具鏈以更快地擴展，同時采用了嚴格的編碼質量標準來保持一致性。
  亞馬遜和Netflix是微服務哲學的主要代表。這種方法自然地將服務代碼分成不同的存儲庫。它可以更快地擴展，但后期可能會出現治理痛點。

• 在Monorepo中，每個服務都是一個文件夾，每個文件夾都有BUILD配置和OWNERS權限控制。每個服務成員都負責自己的文件夾。
  另一方面，在Microrepo中，每個服務都負責自己的存儲庫，構建配置和權限通常設置為整個存儲庫。

• 在Monorepo中，無論您的業務如何，依賴關系都是在整個代碼庫中共享的，因此，當有版本升級時，每個代碼庫都會升級其版本。
  在Microrepo中，依賴關系是在每個存儲庫中控制的。業務可以根據自己的時間表選擇何時升級版本。

• Monorepo有一個標準的簽入流程。谷歌的代碼審查流程因設定了高標準而聞名，確保了Monorepo的一致質量標準，無論業務如何。
  Microrepo可以自己設置標準，也可以采用最佳實踐并采用共享標準。它可以更快地為業務擴展，但代碼質量可能會有所不同。

• 谷歌工程師構建了Bazel，Meta構建了Buck。還有其他開源工具可用，包括Nix、Lerna和其他工具。
  多年來，Microrepo支持的工具越來越多，包括Java的Maven和Gradle、NodeJS的NPM以及C/C++的CMake等。

你會如何設計Stack Overflow網站？

基于現場服務器和單體架構（在下面的圖像中），這就是實際構建的方式！

人們認為它應該是什么樣子

• 上圖的頂部部分。
• 微服務用于將系統分解為小組件。
• 每個服務都有自己的數據庫。大量使用緩存。
• 服務被分片。
• 服務通過消息隊列異步交互。
• 服務使用事件溯源和CQRS實現。
• 展示分布式系統方面的知識，例如最終一致性、CAP定理等。

實際情況

• Stack Overflow僅使用9個現場Web服務器處理所有流量，而且它是一個單體架構！它有自己的服務器，不運行在云上。
• 這與我們當今的所有流行信仰相反。

為什么Amazon Prime Video的監控從無服務器轉向單體應用？如何節省90%的成本？

亞馬遜Prime Video監控服務是什么？

• Prime Video服務需要監控數千個實時流的質量。
• 監控工具自動分析實時流并識別質量問題，如塊損壞、視頻凍結和同步問題。
• 這是客戶滿意度的重要流程。

有三個步驟：媒體轉換器、缺陷檢測器和實時通知。

舊架構存在什么問題？

• 舊架構基于Amazon Lambda構建，用于快速構建服務。
• 然而，在高規模運行架構時，它并不具備成本效益。
• 最昂貴的兩個操作是：
  1、編排工作流程 - AWS步驟函數按狀態轉換收費，編排每秒執行多個狀態轉換。
  2、分布式組件之間的數據傳遞 - 中間數據存儲在Amazon S3中，以便下一個階段可以下載。當數據量很大時，下載可能很昂貴。

單體架構節省90%的成本

• 單體架構旨在解決成本問題。
  仍然有三個組件，但媒體轉換器和缺陷檢測器部署在同一進程中，節省了通過網絡傳遞數據的成本。
  令人驚訝的是，這種部署架構變更方法導致了90%的成本節約！
• 這是一個有趣且獨特的案例研究，因為微服務已成為技術行業的首選和時尚選擇。
  很高興看到我們正在更多地討論如何發展架構，并更加誠實地討論其優缺點。將組件分解為分布式微服務會帶來成本。

亞馬遜領袖對此有何看法？

• 亞馬遜首席技術官Werner Vogels： “構建可發展的軟件系統是一種策略，而不是一種宗教。以開放的心態重新審視您的架構是必須的。”
• 前亞馬遜可持續性副總裁Adrian Cockcroft： “Prime Video團隊已經遵循了我稱之為Serverless First的路徑…我不贊成Serverless Only。”

遷移前后的架構比較：

Disney Hotstar如何在錦標賽期間捕捉50億個表情符號？

• 1、客戶端通過標準HTTP請求發送表情符號。您可以將Golang服務視為典型的Web服務器。選擇Golang是因為它很好地支持并發。Golang中的線程是輕量級的。

• 2、由于寫入量非常高，使用Kafka（消息隊列）作為緩沖區。

• 3、表情符號數據由名為Spark的流處理服務聚合。它每2秒聚合一次數據，這是可配置的。根據間隔需要進行權衡。較短的間隔意味著表情符號將更快地傳遞給其他客戶端，但這也意味著需要更多的計算資源。

• 4、聚合數據被寫入另一個Kafka。

• 5、PubSub消費者從Kafka中拉取聚合的表情符號數據。

• 6、表情符號通過PubSub基礎架構實時傳遞給其他客戶端。PubSub基礎架構很有趣。Hotstar考慮了以下協議：Socketio、NATS、MQTT和gRPC，并選擇了MQTT。

LinkedIn采用了類似的設計，可以每秒流式傳輸一百萬個贊。

Discord如何存儲數萬億條消息

下面的圖表顯示了Discord消息存儲的演變過程：

MongoDB => Cassandra => ScyllaDB

• 2015年，Discord的第一個版本建立在單個MongoDB副本之上。
  到了2015年11月，MongoDB存儲了1億條消息，內存無法再容納數據和索引。延遲變得不可預測，消息存儲需要遷移到另一個數據庫。他們選擇了Cassandra。
• 到了2017年，Discord有12個Cassandra節點，存儲著數十億條消息。
• 在2022年初，它擁有了177個節點，存儲著數萬億條消息。此時，延遲變得不可預測，維護操作的成本也變得太高。

Cassandra對比ScyllaDB（替換的原因）：

• Cassandra使用LSM樹作為內部數據結構。讀取比寫入更昂貴。在有數百個用戶的服務器上可能會有許多并發讀取，導致熱點問題。
  維護群集，如壓縮SSTables，會影響性能。 垃圾回收暫停會導致顯著的延遲峰值。
• ScyllaDB是一個用C++編寫的與Cassandra兼容的數據庫。
  Discord重新設計了其架構，擁有一個單體式API，一個用Rust編寫的數據服務和基于ScyllaDB的存儲。
  在ScyllaDB中，p99讀取延遲為15毫秒，而在Cassandra中為40-125毫秒。p99寫入延遲為5毫秒，而在Cassandra中為5-70毫秒。.

YouTube、TikTok Live或Twitch上的視頻直播是如何工作的？

直播流與常規流媒體不同，因為視頻內容是通過互聯網實時發送的，通常延遲只有幾秒鐘。

下面的圖示解釋了實現這一點的背后發生的事情。

• 第一步：原始視頻數據由麥克風和攝像頭捕捉。數據被發送到服務器端。
• 第二步：視頻數據被壓縮和編碼。例如，壓縮算法將背景和其他視頻元素分離。壓縮后，視頻被編碼為標準格式，例如H.264。經過這一步驟后，視頻數據的大小大大縮小。
• 第三步：編碼數據被分成更小的片段，通常是幾秒鐘的長度，以便下載或流媒體所需的時間更短。
• 第四步：分段數據被發送到流媒體服務器。流媒體服務器需要支持不同的設備和網絡條件。這被稱為“自適應比特率流媒體”。這意味著我們需要在步驟2和3中生成多個不同比特率的文件。
• 第五步：直播流數據被推送到由CDN（內容分發網絡）支持的邊緣服務器。數百萬觀眾可以從附近的邊緣服務器觀看視頻。CDN顯著降低了數據傳輸延遲。
• 第六步：觀眾設備解碼和解壓縮視頻數據，并在視頻播放器中播放視頻。
• 第七步和第八步：如果需要將視頻存儲以供重播，編碼數據將被發送到存儲服務器，觀眾稍后可以從中請求重播。

直播流的標準協議包括：

• RTMP（實時消息傳輸協議）：最初由Macromedia開發，用于在Flash播放器和服務器之間傳輸數據。現在它用于在互聯網上流傳視頻數據。請注意，像Skype這樣的視頻會議應用程序使用RTC（實時通信）協議以實現更低的延遲。
• HLS（HTTP Live Streaming）：需要H.264或H.265編碼。Apple設備只支持HLS格式。
• DASH（動態自適應流媒體）：DASH不支持Apple設備。
• HLS和DASH都支持自適應比特率流媒體。