# 縮放原理 > 原文： [http://highscalability.com/blog/2020/5/14/a-short-on-how-zoom-works.html](http://highscalability.com/blog/2020/5/14/a-short-on-how-zoom-works.html)  整個晚上，Zoom 的規模從 2000 萬增加到 3 億。 令人難以置信的是，從外部看，他們并沒有表現出明顯的成長痛苦，盡管在內部，這是一個很好的押注，很多瘋狂還在發生。 當然，Zoom 做出了一些設計決策，這些決策對于一個小型的，不起眼的初創公司來說是有意義的，但作為事實上的標準并沒有多大意義，但這是可以預期的。 正如許多人所建議的，這并不是不良體系結構的跡象。 這實際上是產品的演變方式，尤其是當它們必須在數周，數天甚至數小時內提升時。 突然的成功需要進行仔細的審查，因此每個人都想知道 Zoom 的工作原理。 問題是我們了解的不多，但是我們確實有一些信息來源： * [縮放方式可提供業界領先的視頻容量](https://blog.zoom.us/wordpress/2019/06/26/zoom-can-provide-increase-industry-leading-video-capacity/) * [給我們用戶的消息](https://blog.zoom.us/wordpress/2020/04/01/a-message-to-our-users/) * 一年前的營銷視頻 [Zoom 獨特的體系結構如何為您的視頻帶來最大的 UC 未來](https://www.youtube.com/watch?v=5BMbsFqtD0A) * 2016 年關于[的文檔全球基礎設施和安全指南](https://zoom.us/docs/doc/Zoom_Global_Infrastructure.pdf) * 已有一年的新聞稿 [Zoom 借助 Equinix 擴展，以適應未來需求并擴展其視頻優先，云原生架構](https://www.prnewswire.com/news-releases/zoom-expands-with-equinix-to-future-proof-and-scale-its-video-first-cloud-native-architecture-300962299.html) * [Zoom CFO 解釋了公司如何應對不斷增長的需求](https://www.cnbc.com/2020/03/18/zoom-cfo-explains-how-the-company-is-grappling-with-increased-demand.html) * 在線問& A [問 Eric 任何問題](https://www.youtube.com/watch?v=tlC-sEdqY48) * AWS 說[大多數 Zoom 運行在 AWS 上，而不是 Oracle 上](https://www.datacenterdynamics.com/en/news/most-zoom-runs-aws-not-oracle-says-aws) 以下是其中一些來源的介紹： * 有關 Zoom 的數據中心使用情況有很多爭論。 最終的結果是，他們從自己的共享空間開始，然后隨著增長的高峰而擴展以使用多個云。 幾乎教科書的執行如何處理突如其來的增長。 * [大多數 Zoom 都在 AWS 上運行，而不是在 Oracle 上運行-AWS 說](https://www.datacenterdynamics.com/en/news/most-zoom-runs-aws-not-oracle-says-aws)：自大流行到來以來，該服務已將大量實時視頻會議流量移至 AWS 上，并且容量也有所減少 在 Oracle Cloud 上...首席執行官 Eric Yuan 進一步澄清了這一點，解釋說 Zoom 過去在“自己的數據中心”中處理實時視頻會議流量...我們的實時流量始終留在我們自己的數據中心內 對于我們的付費客戶...在這場大流行危機期間，每天都是新的記錄。 我們自己的現有數據中心實際上無法處理此流量...這意味著 AWS 每天都會為 Zoom 旋轉成千上萬的新服務器...因此最終，我們自己的數據中心（主要是 Amazon）以及 在 Oracle 云中，這三者共同為所有前所未有的流量提供服務。 * 我們對 Zoom 的架構知之甚少，但此營銷視頻進行了一些詳細介紹： [Zoom 獨特的架構如何為您的視頻帶來最大的 UC Future](https://www.youtube.com/watch?v=5BMbsFqtD0A) 。 * Zoom 將其架構視為競爭優勢。 每個人都將使用視頻，那么我們如何擴展到每個人？ 因此 Zoom 始于無處不在的視頻目標，并讓該目標塑造了他們的架構。 * 競爭對手通過數據中心進行長號通信，將其轉碼為其他人的普通視圖，然后將混合視頻發送給每個參與者。 這引入了延遲，使用了大量的 CPU 資源，并且很難擴展和部署新的數據中心來滿足增加的負載。 * Zoom 選擇了 AVC 上的 SVC（可伸縮視頻編解碼器）編解碼器。 AVC 是一種協議，您在其中發送單個流，并且單個流具有比特率。 如果要發送多個比特率，則必須發送多個流。 如果要發送多個比特率，這會增加帶寬利用率。 * SVC 是具有多個層的單個流。 這樣就可以發送 1.2 mbs 的流，該流具有您可能需要縮小到給定網絡條件的所有分辨率和比特率。 過去，您只能使用 ASIC 進行 SVC。 現在，由于摩爾定律，SVC 可以用軟件完成。 * Zoom 創建了多媒體路由，以解決傳統供應商在 AVC 中遇到的問題。 消除轉碼擺脫了等待時間并增加了規模。 * 多媒體路由會將用戶內容帶入他們的云中，當您作為客戶端遇到問題時，他們會將另一個視頻流切換給您。 如果您需要其他分辨率，則可以訂閱該人分辨率的另一層。 * 縮放不會轉碼或混合任何內容或形成任何視圖。 從字面上看，您實際上是從零處理的路由中直接提取多個人的多個流。 這就是為什么您會看到如此出色的用戶切換和語音切換體驗以及低延遲的原因。 * Zoom 開發了在云和客戶端之間工作的應用程序層 QoS（服務質量）。 它的工作是檢測網絡狀況。 收集的遙測數據確定將哪個流切換到客戶端。 該算法查看 CPU，抖動，數據包丟失等情況。 * 客戶與云對話。 云知道何時不返回某些數據包，因此它將做出決定并將另一種流切換到您。 * 如果網絡環境不好，客戶端可以自動縮小您自己的發送視頻的大小，因此您不會浪費自己的下行帶寬。 * 客戶端和云協同工作，以在正確的網絡上交付正確的音頻流，正確的視頻流，因此用戶體驗達到最佳狀態。 * 具備網絡意識意味著首先嘗試最佳體驗，即 UDP。 如果 UDP 不起作用，則嘗試 HTTPS。 如果 HTTPS 不起作用，則會退回到 HTTP。 客戶進行協商。 遙測表明為什么連接不良。 您能做的最糟糕的事情就是給用戶帶來不一致的體驗。 * 重點是使所有事情都盡可能簡單直觀地工作。 強調并重復了這一點，這可以解釋一些較早的設計決策。 * 在這一點上，討論朝著更加注重市場的方向發展。 * Zoom 通過 40 分鐘的視頻和聊天會議打亂了市場。 他們增加了免費的電話撥入式會議。 他們提供了市場上最好的 VOIP 體驗。 競爭對手的平均 VOIP 采納率不到 30％，縮放比例為 89％。 每年在音頻會議上花費 30 億美元，而 Zoom 免費提供它。 提供基于軟件的視頻會議室體驗。 為競爭對手提供了一鍵式推送。 放棄數字標牌和房間展示。 * Zoom 的競爭對手陷入了無法擺脫的收入模式。 不能創新，因為它們會破壞自己的收入模式。 * Zoom 破壞了會議市場，音頻市場，房間市場，現在他們想破壞電話。 盡管這是 2019 年，但隨著大流行，該策略可能正在重新考慮。 * Zooms 的目標是創建最大的互聯協作網絡。 他們希望兌現 20 年前 VOIP 的承諾，拆除人們相互協作的所有費用壁壘，推出 PSTN 連接性，通過聊天會議電話通過 IP 以任何網絡上最低的速率連接所有人。 Zoom 如何滿足如此巨大的帶寬需求。 我不認為這是視頻會議的中斷，因為許多其他播放器已經以合理的成本結構提供了不錯的視頻內容，并且有些免費。 讓我們不要將破壞與謀殺行業混為一談。 中斷是有價值的東西，因為它的第一款產品具有某些技術優勢，而該技術以前并未實現過，并且可以幫助用戶降低此類服務的成本或通過一些廣告收入流免費提供這種服務（盡管不會竊取數據）。 Zoom 并未中斷，但得到了貪婪的投資者的支持，先殺死了其他視頻會議公司，然后在殺死了所有其他小型競爭對手以與 bluejeans 或 google 見面之戰后，慢慢開始賺錢。