# Instagram 提高了其應用程序的性能。 這是如何做。
> 原文: [http://highscalability.com/blog/2014/9/29/instagram-improved-their-apps-performance-heres-how.html](http://highscalability.com/blog/2014/9/29/instagram-improved-their-apps-performance-heres-how.html)

[平面設計](http://en.wikipedia.org/wiki/Flat_UI_Design)只是另一張漂亮的面孔,還是作為 UI 革命掩蓋的巨大性能突破? 事實證明,扁平化設計是贏得冷戰的堅石。
Instagram 工程師 [Tyler Kieft](http://tylerkieft.com/) 在他在 [@scale 會議](http://atscaleconference.com/)上發表的簡短且內容豐富的演講中,對上述內容進行了詳盡的解釋:[在典型 Android](https://www.youtube.com/watch?v=GHTO2WKDO6I#t=8927) 上的 Instagram ]。 該演講是[系列演講](/blog/2014/9/22/how-facebook-makes-mobile-work-at-scale-for-all-phones-on-al.html)的一部分,該演講由 Facebook 進行,主題是如何為全球范圍內的移動應用程序設計現實,與美國相比,這種手機的速度較慢,屏幕較小,網絡速度較慢。 。
為典型的手機而不是高端手機進行設計需要 Instagram 團隊深入思考其設計。 泰勒(Tyler)演講的啟示之一是**向平面設計**的轉移極大地提高了應用程序的美觀性,可用性和實用性,并且極大地提高了性能。
這真是一個驚喜。 我只是將平面設計視為思考如何構建漂亮的 UI 的一種方式。 傻我 感謝泰勒(Tyler)如此清晰,有力地解釋了平面設計的好處,并使用 Instagram 作為可能的典范。
平面設計是反擬態的,它是數字化本地人,避免了對現實外觀的癡迷,采用簡單的元素,簡單的版式,平面顏色和簡單的設計。
使用平面設計,Instagram 可以從冷啟動時間縮短 120 毫秒。 它還能夠將顯示提要屏幕所需的資產數量從 29 個減少到 8 個。 同時,使應用程序更美觀,更易用,并更加關注不同手機尺寸的內容。
平面設計如何使這一切成為可能?
## 轉向平面設計
* Instagram 改寫了他們的 UI,以專注于 Android 上提供的各種 UI 的更好性能。
* Instagram 于 2012 年在 Android 上發布時,它是由 3 個人在大約 4 個月內建成的。 兩名工程師和一名設計師。 Android 版本使用與 iOS 版本相同的設計。
* 該設計使用了甜美的漸變色和許多 UI 元素。
* 向 iOS7 過渡到平面設計,使產品變得更加簡單和美觀。 沒有更多的漸變。 拿出箱子。 沒有更多的陰影。
* 他們從適應平面設計**的經驗中學到了**:
* **平面設計是減少**,更快開發代碼和更快交付產品的機會。 這對開發人員來說很棒。
* **平面設計的性能更高**。 開發人員不僅做得更少,而且手機在顯示 UI 方面也做得更少。
* 使用從 iOS7 平面設計重新設計中學到的新 Android 版本的目標:
* **使其平坦,使其更快**。 這不是重寫。 導航模式沒有改變。
* **注意屏幕空間**。 重新瀏覽每個屏幕,并弄清楚如何更好地適應所有屏幕尺寸。
* **變得漂亮**。 這是他們在 Instagram 上所做的一切的基礎。
* 總體效果是極大的簡化。 進行了哪些更改?
* **將所有內容從 Chrome** 中刪除。 拿出所有漸變和光澤按鈕。 去勾勒形狀而不是圖標的漸變按鈕。 剩下的是純色和扁平形狀。 希望用戶界面淡入背景。
* **拿出注釋圖標**,使注釋全屏顯示,為注釋文本留出更多空間。 使內容在屏幕上脫穎而出。 用戶界面越少,使用小屏幕的人就有更多的空間閱讀文本。
* **分叉了用于拍照的手機布局**。 在小型電話上,他們使用在屏幕頂部帶有動作按鈕的設計。 對于較大的屏幕,所有命令都在底部。
* **刪除了整個應用程序不必要的 UI,以使內容更加集中**。 搜索屏幕上的三層鉻減少到兩層。 這在小型電話上騰出了很多空間。 由于三星 Galaxy 的按鈕纖薄,采用扁平化設計很容易以編程方式進行操作,從而為內容騰出了很多空間。
* 請注意,演講中有很多關于不同設計的精美圖片,因此非常值得觀看之前和之后的圖片。
## 為什么要進行平面設計?
* **使用資產著色**運送更少的資產。 這意味著 APK 的大小較小,這在小型網絡上非常有用。 魔術是**資產著色** **(**我以前從未聽說過)。 [資產著色](http://blog.danlew.net/2014/08/18/fast-android-asset-theming-with-colorfilter/)表示資產(在這種情況下為圖像)可以通過程序進行著色。 例如,可以通過編程方式將灰色的心臟染成紅色。 資產著色意味著需要運輸的資產更少。 傳統上,每種按鈕狀態(按下,未按下,選擇等)都需要單獨的圖像。通過著色,可以將不同狀態的所有圖像都不再需要運送了。 僅需要圖像,并且可以設置不同的狀態。
* **加載更少的資產**。 這意味著 UI 顯示速度更快,并且用于存儲位圖的內存更少。 必須從閃存中讀取每個需要顯示的資產,并將其解碼為位圖。 完成的次數越少,應用程序變得越快。
* **更快的迭代時間**。 如果您要更改顏色或進行新開發,則不再需要設計師。 只需更改代碼并重新編譯即可。
* 結果:
* **在進行平面設計之前,需要 29 種不同的資源來顯示供稿屏幕**。 平面設計后, **8 個資產**顯示同一頁面。 僅需要形狀即可顯示圖標和徽標。 其他所有內容均以代碼形式繪制為純色和矩形。 僅僅是從所有設備的冷啟動時間起將**縮短了 120ms** 。
* **采用扁平化設計,整個應用變得更快**。 每個屏幕的工作量都減少了。 更少的資產被加載,整個應用變得更加生氣。 評論中的用戶評論了應用程序在重新設計后的感覺。 人們真的很喜歡它。 人們贊賞與平臺匹配的設計所帶來的速度提升。
## 縮短冷啟動時間
* 冷啟動時間是應用程序啟動并變得響應所需的時間。 從點擊圖標到在應用程序周圍單擊,它均有效。 我們的目標是讓**應用能夠超快速地啟動**,以便使用低端手機的用戶擁有豐富的體驗。
* 幾年前,在低端 Galaxy Y 上,Instagram 的啟動時間為 3 秒。 在高端 Galaxy S5 上,啟動時間為 750 毫秒。
* 現在,在 Galaxy Y 上,Instagram 需要 1.5 秒才能啟動。 在 Galaxy S5 上,需要花費 **400 毫秒**。
* 怎么樣? (除去資產)
* **對應用程序**進行配置。
* 找出導致應用速度下降的原因。
* 在 Android 上,您可以使用**方法跟蹤**,并且可以在代碼中放置計時語句。 方法跟蹤數較小的方法。 **時序聲明**是墻上時鐘時間,而不是機器時間。 同時使用這兩種功能可以讓您對緩慢的情況有良好的感覺。
* **解決最慢的問題**。
* **延遲加載**。 從冷啟動路徑中刪除項目。
* **重寫慢速代碼**。 例如,慢速 JSON 解析代碼被重寫為更快。
* **延遲到后臺線程**。 不要在 UI 線程中執行操作,而可以在后臺執行。
* **迭代**。 再次開始配置文件步驟。
* **應用范圍內的單身人士發現速度很慢**。 通過計時發現。
* 在應用啟動之前,已經啟動了許多**重單例**:HTTP 客戶端,Cookie 存儲,圖像緩存,視頻緩存。 確實不需要這些東西即可向用戶顯示用戶界面。 它們可以并行加載到后臺。
* **兩部分延遲加載**
* 想要**在后臺**中初始化單例,但程序員仍將其視為始終可用于該應用的單例。 不想讓程序員必須檢查單例是否可用,因為那不是單例。
* **在 UI 線程**上創建足夠的對象,以便公共 API 完全起作用,并且可供程序員使用。 將艱苦的工作推遲到后臺線程。 對于高速緩存,這意味著打開和讀取磁盤存儲。 對于客戶端,證書將在后臺加載。 Cookies 在后臺反序列化和解碼。 通過這些更改,UI 可以更快地出現在屏幕上。
* **Newsview 運行緩慢**。 通過方法跟蹤找到。
* 新聞視圖最初顯示為網絡視圖,其中顯示了您的所有喜歡和評論。 需要在啟動時加載它以盡快向用戶顯示其數據。
* 問題是無法控制 Webview。 它具有自己的堆棧和緩存系統。 **將其轉換為本地**。 花了 2-4 周的時間。 原始轉換后,冷啟動時間將**降低了 30%**。
## 得到教訓
* **可以實現快速的冷啟動時間**。 如果他們很快,他們甚至會變得更快。 剖析,修復,迭代。
* **謹慎使用像素**。 查看每個屏幕,查看不需要的內容。 與美國相比,其他國家/地區的用戶使用的手機要小得多。
* 移動電話喜歡簡單的設計,移動開發人員也喜歡。 這要容易得多,也要快得多。
## 相關文章
* [在 Reddit 上](http://www.reddit.com/r/programming/comments/2iqfr7/how_instagram_improves_their_apps_performance/)
* [Facebook 斥資 10 億美元收購 Instagram 架構](http://highscalability.com/blog/2012/4/9/the-instagram-architecture-facebook-bought-for-a-cool-billio.html)
* [Instagram 體系結構更新:Instagram 有何新功能?](http://highscalability.com/blog/2012/4/16/instagram-architecture-update-whats-new-with-instagram.html)
* [有人可以表達 Google 的材料設計與蘋果公司的平面設計嗎?](http://www.quora.com/Can-someone-articulate-Googles-material-design-vs-Apples-flat-design)
我發現有趣的是,這種平面設計運動是由 Microsoft 與 Windows Phone 一起發起的。
總是會有更多的高檔用戶界面(如游戲中),但從總體上看,功能正在取代形式。 我喜歡那個。
它以功能為基礎,對我有很多幫助。 直到觀看了這個出色的演示,我才知道平面設計是什么。 現在,在許多不同的層次上它變得更加有意義。
正如文章所提出的那樣,功能必須戰勝視覺障礙。 但是作為仍然使用 iOS6.1.3 的匕首,我必須要求您承認,自 iOS7 以來,奇怪而與眾不同的選擇令人困惑:白色文本的鮮綠色背景,窄字體,細膩的灰色陰影以及總體而言太多了 屏幕上呈鮮亮的白色,而對于發現此效果實際上令人痛苦的用戶則無能為力。 而且,即使使用 iOS8.0.2,提供的修改也是如此之小,以至于令人懷疑。
好吧,漸變對處理程序征稅-如果處理器不能比程序員領先一步,就消除漸變。 但是至少要為用戶提供背景顏色選項。 給一些真實的對比度控制。 為需要的人提供一些粗細的字體。
我們生活在一個這樣的世界中,所有用戶都將以正確的視線來到餐桌上,這一假設和期望越來越普遍。 但這是一個精英主義的假設。 使它精簡,使其快速,但不要把我們中的很多人甩在后面。
- LiveJournal 體系結構
- mixi.jp 體系結構
- 友誼建筑
- FeedBurner 體系結構
- GoogleTalk 架構
- ThemBid 架構
- 使用 Amazon 服務以 100 美元的價格構建無限可擴展的基礎架構
- TypePad 建筑
- 維基媒體架構
- Joost 網絡架構
- 亞馬遜建筑
- Fotolog 擴展成功的秘訣
- 普恩斯的教訓-早期
- 論文:Wikipedia 的站點內部,配置,代碼示例和管理問題
- 擴大早期創業規模
- Feedblendr 架構-使用 EC2 進行擴展
- Slashdot Architecture-互聯網的老人如何學會擴展
- Flickr 架構
- Tailrank 架構-了解如何在整個徽標范圍內跟蹤模因
- Ruby on Rails 如何在 550k 網頁瀏覽中幸存
- Mailinator 架構
- Rackspace 現在如何使用 MapReduce 和 Hadoop 查詢 TB 的數據
- Yandex 架構
- YouTube 架構
- Skype 計劃 PostgreSQL 擴展到 10 億用戶
- 易趣建筑
- FaceStat 的禍根與智慧贏得了勝利
- Flickr 的聯合會:每天進行數十億次查詢
- EVE 在線架構
- Notify.me 體系結構-同步性
- Google 架構
- 第二人生架構-網格
- MySpace 體系結構
- 擴展 Digg 和其他 Web 應用程序
- Digg 建筑
- 在 Amazon EC2 中部署大規模基礎架構的六個經驗教訓
- Wolfram | Alpha 建筑
- 為什么 Facebook,Digg 和 Twitter 很難擴展?
- 全球范圍擴展的 10 個 eBay 秘密
- BuddyPoke 如何使用 Google App Engine 在 Facebook 上擴展
- 《 FarmVille》如何擴展以每月收獲 7500 萬玩家
- Twitter 計劃分析 1000 億條推文
- MySpace 如何與 100 萬個并發用戶一起測試其實時站點
- FarmVille 如何擴展-后續
- Justin.tv 的實時視頻廣播架構
- 策略:緩存 404 在服務器時間上節省了洋蔥 66%
- Poppen.de 建筑
- MocoSpace Architecture-一個月有 30 億個移動頁面瀏覽量
- Sify.com 體系結構-每秒 3900 個請求的門戶
- 每月將 Reddit 打造為 2.7 億頁面瀏覽量時汲取的 7 個教訓
- Playfish 的社交游戲架構-每月有 5000 萬用戶并且不斷增長
- 擴展 BBC iPlayer 的 6 種策略
- Facebook 的新實時消息系統:HBase 每月可存儲 135 億條消息
- Pinboard.in Architecture-付費玩以保持系統小巧
- BankSimple 迷你架構-使用下一代工具鏈
- Riak 的 Bitcask-用于快速鍵/值數據的日志結構哈希表
- Mollom 體系結構-每秒以 100 個請求殺死超過 3.73 億個垃圾郵件
- Wordnik-MongoDB 和 Scala 上每天有 1000 萬個 API 請求
- Node.js 成為堆棧的一部分了嗎? SimpleGeo 說是的。
- 堆棧溢出體系結構更新-現在每月有 9500 萬頁面瀏覽量
- Medialets 體系結構-擊敗艱巨的移動設備數據
- Facebook 的新實時分析系統:HBase 每天處理 200 億個事件
- Microsoft Stack 是否殺死了 MySpace?
- Viddler Architecture-每天嵌入 700 萬個和 1500 Req / Sec 高峰
- Facebook:用于擴展數十億條消息的示例規范架構
- Evernote Architecture-每天有 900 萬用戶和 1.5 億個請求
- TripAdvisor 的短
- TripAdvisor 架構-4,000 萬訪客,200M 動態頁面瀏覽,30TB 數據
- ATMCash 利用虛擬化實現安全性-不變性和還原
- Google+是使用您也可以使用的工具構建的:閉包,Java Servlet,JavaScript,BigTable,Colossus,快速周轉
- 新的文物建筑-每天收集 20 億多個指標
- Peecho Architecture-鞋帶上的可擴展性
- 標記式架構-擴展到 1 億用戶,1000 臺服務器和 50 億個頁面視圖
- 論文:Akamai 網絡-70 個國家/地區的 61,000 臺服務器,1,000 個網絡
- 策略:在 S3 或 GitHub 上運行可擴展,可用且廉價的靜態站點
- Pud 是反堆棧-Windows,CFML,Dropbox,Xeround,JungleDisk,ELB
- 用于擴展 Turntable.fm 和 Labmeeting 的數百萬用戶的 17 種技術
- StackExchange 體系結構更新-平穩運行,Amazon 4x 更昂貴
- DataSift 體系結構:每秒進行 120,000 條推文的實時數據挖掘
- Instagram 架構:1400 萬用戶,1 TB 的照片,數百個實例,數十種技術
- PlentyOfFish 更新-每月 60 億次瀏覽量和 320 億張圖片
- Etsy Saga:從筒倉到開心到一個月的瀏覽量達到數十億
- 數據范圍項目-6PB 存儲,500GBytes / sec 順序 IO,20M IOPS,130TFlops
- 99designs 的設計-數以千萬計的綜合瀏覽量
- Tumblr Architecture-150 億頁面瀏覽量一個月,比 Twitter 更難擴展
- Berkeley DB 體系結構-NoSQL 很酷之前的 NoSQL
- Pixable Architecture-每天對 2000 萬張照片進行爬網,分析和排名
- LinkedIn:使用 Databus 創建低延遲更改數據捕獲系統
- 在 30 分鐘內進行 7 年的 YouTube 可擴展性課程
- YouPorn-每天定位 2 億次觀看
- Instagram 架構更新:Instagram 有何新功能?
- 搜索技術剖析:blekko 的 NoSQL 數據庫
- Pinterest 體系結構更新-1800 萬訪問者,增長 10 倍,擁有 12 名員工,410 TB 數據
- 搜索技術剖析:使用組合器爬行
- iDoneThis-從頭開始擴展基于電子郵件的應用程序
- StubHub 體系結構:全球最大的票務市場背后的驚人復雜性
- FictionPress:在網絡上發布 600 萬本小說
- Cinchcast 體系結構-每天產生 1,500 小時的音頻
- 棱柱架構-使用社交網絡上的機器學習來弄清您應該在網絡上閱讀的內容
- 棱鏡更新:基于文檔和用戶的機器學習
- Zoosk-實時通信背后的工程
- WordPress.com 使用 NGINX 服務 70,000 req / sec 和超過 15 Gbit / sec 的流量
- 史詩般的 TripAdvisor 更新:為什么不在云上運行? 盛大的實驗
- UltraDNS 如何處理數十萬個區域和數千萬條記錄
- 更簡單,更便宜,更快:Playtomic 從.NET 遷移到 Node 和 Heroku
- Spanner-關于程序員使用 NoSQL 規模的 SQL 語義構建應用程序
- BigData 使用 Erlang,C 和 Lisp 對抗移動數據海嘯
- 分析數十億筆信用卡交易并在云中提供低延遲的見解
- MongoDB 和 GridFS 用于內部和內部數據中心數據復制
- 每天處理 1 億個像素-少量競爭會導致大規模問題
- DuckDuckGo 體系結構-每天進行 100 萬次深度搜索并不斷增長
- SongPop 在 GAE 上可擴展至 100 萬活躍用戶,表明 PaaS 未通過
- Iron.io 從 Ruby 遷移到 Go:減少了 28 臺服務器并避免了巨大的 Clusterf ** ks
- 可汗學院支票簿每月在 GAE 上擴展至 600 萬用戶
- 在破壞之前先檢查自己-鱷梨的建筑演進的 5 個早期階段
- 縮放 Pinterest-兩年內每月從 0 到十億的頁面瀏覽量
- Facebook 的網絡秘密
- 神話:埃里克·布魯爾(Eric Brewer)談銀行為什么不是堿-可用性就是收入
- 一千萬個并發連接的秘密-內核是問題,而不是解決方案
- GOV.UK-不是你父親的書庫
- 縮放郵箱-在 6 周內從 0 到 100 萬用戶,每天 1 億條消息
- 在 Yelp 上利用云計算-每月訪問量為 1.02 億,評論量為 3900 萬
- 每臺服務器將 PHP 擴展到 30,000 個并發用戶的 5 條 Rockin'Tips
- Twitter 的架構用于在 5 秒內處理 1.5 億活躍用戶,300K QPS,22 MB / S Firehose 以及發送推文
- Salesforce Architecture-他們每天如何處理 13 億筆交易
- 擴大流量的設計決策
- ESPN 的架構規模-每秒以 100,000 Duh Nuh Nuhs 運行
- 如何制作無限可擴展的關系數據庫管理系統(RDBMS)
- Bazaarvoice 的架構每月發展到 500M 唯一用戶
- HipChat 如何使用 ElasticSearch 和 Redis 存儲和索引數十億條消息
- NYTimes 架構:無頭,無主控,無單點故障
- 接下來的大型聲音如何使用 Hadoop 數據版本控制系統跟蹤萬億首歌曲的播放,喜歡和更多內容
- Google 如何備份 Internet 和數十億字節的其他數據
- 從 HackerEarth 用 Apache 擴展 Python 和 Django 的 13 個簡單技巧
- AOL.com 體系結構如何發展到 99.999%的可用性,每天 800 萬的訪問者和每秒 200,000 個請求
- Facebook 以 190 億美元的價格收購了 WhatsApp 體系結構
- 使用 AWS,Scala,Akka,Play,MongoDB 和 Elasticsearch 構建社交音樂服務
- 大,小,熱還是冷-條帶,Tapad,Etsy 和 Square 的健壯數據管道示例
- WhatsApp 如何每秒吸引近 5 億用戶,11,000 內核和 7,000 萬條消息
- Disqus 如何以每秒 165K 的消息和小于 0.2 秒的延遲進行實時處理
- 關于 Disqus 的更新:它仍然是實時的,但是 Go 摧毀了 Python
- 關于 Wayback 機器如何在銀河系中存儲比明星更多的頁面的簡短說明
- 在 PagerDuty 遷移到 EC2 中的 XtraDB 群集
- 擴展世界杯-Gambify 如何與 2 人組成的團隊一起運行大型移動投注應用程序
- 一點點:建立一個可處理每月 60 億次點擊的分布式系統的經驗教訓
- StackOverflow 更新:一個月有 5.6 億次網頁瀏覽,25 臺服務器,而這一切都與性能有關
- Tumblr:哈希處理每秒 23,000 個博客請求的方式
- 使用 HAProxy,PHP,Redis 和 MySQL 處理 10 億個請求的簡便方法來構建成長型啟動架構
- MixRadio 體系結構-兼顧各種服務
- Twitter 如何使用 Redis 進行擴展-105TB RAM,39MM QPS,10,000 多個實例
- 正確處理事情:通過即時重放查看集中式系統與分散式系統
- Instagram 提高了其應用程序的性能。 這是如何做。
- Clay.io 如何使用 AWS,Docker,HAProxy 和 Lots 建立其 10 倍架構
- 英雄聯盟如何將聊天擴大到 7000 萬玩家-需要很多小兵。
- Wix 的 Nifty Architecture 技巧-大規模構建發布平臺
- Aeron:我們真的需要另一個消息傳遞系統嗎?
- 機器:惠普基于憶阻器的新型數據中心規模計算機-一切仍在變化
- AWS 的驚人規模及其對云的未來意味著什么
- Vinted 體系結構:每天部署數百次,以保持繁忙的門戶穩定
- 將 Kim Kardashian 擴展到 1 億個頁面
- HappyPancake:建立簡單可擴展基金會的回顧
- 阿爾及利亞分布式搜索網絡的體系結構
- AppLovin:通過每天處理 300 億個請求向全球移動消費者進行營銷
- Swiftype 如何以及為何從 EC2 遷移到真實硬件
- 我們如何擴展 VividCortex 的后端系統
- Appknox 架構-從 AWS 切換到 Google Cloud
- 阿爾及利亞通往全球 API 的憤怒之路
- 阿爾及利亞通往全球 API 步驟的憤怒之路第 2 部分
- 為社交產品設計后端
- 阿爾及利亞通往全球 API 第 3 部分的憤怒之路
- Google 如何創造只有他們才能創造的驚人的數據中心網絡
- Autodesk 如何在 Mesos 上實施可擴展事件
- 構建全球分布式,關鍵任務應用程序:Trenches 部分的經驗教訓 1
- 構建全球分布式,關鍵任務應用程序:Trenches 第 2 部分的經驗教訓
- 需要物聯網嗎? 這是美國一家主要公用事業公司從 550 萬米以上收集電力數據的方式
- Uber 如何擴展其實時市場平臺
- 優步變得非常規:使用司機電話作為備份數據中心
- 在不到五分鐘的時間里,Facebook 如何告訴您的朋友您在災難中很安全
- Zappos 的網站與 Amazon 集成后凍結了兩年
- 為在現代時代構建可擴展的有狀態服務提供依據
- 細分:使用 Docker,ECS 和 Terraform 重建基礎架構
- 十年 IT 失敗的五個教訓
- Shopify 如何擴展以處理來自 Kanye West 和 Superbowl 的 Flash 銷售
- 整個 Netflix 堆棧的 360 度視圖
- Wistia 如何每小時處理數百萬個請求并處理豐富的視頻分析
- Google 和 eBay 關于構建微服務生態系統的深刻教訓
- 無服務器啟動-服務器崩潰!
- 在 Amazon AWS 上擴展至 1100 萬以上用戶的入門指南
- 為 David Guetta 建立無限可擴展的在線錄制活動
- Tinder:最大的推薦引擎之一如何決定您接下來會看到誰?
- 如何使用微服務建立財產管理系統集成
- Egnyte 體系結構:構建和擴展多 PB 分布式系統的經驗教訓
- Zapier 如何自動化數十億個工作流自動化任務的旅程
- Jeff Dean 在 Google 進行大規模深度學習
- 如今 Etsy 的架構是什么樣的?
- 我們如何在 Mail.Ru Cloud 中實現視頻播放器
- Twitter 如何每秒處理 3,000 張圖像
- 每天可處理數百萬個請求的圖像優化技術
- Facebook 如何向 80 萬同時觀看者直播
- Google 如何針對行星級基礎設施進行行星級工程設計?
- 為 Mail.Ru Group 的電子郵件服務實施反垃圾郵件的貓捉老鼠的故事,以及 Tarantool 與此相關的內容
- The Dollar Shave Club Architecture Unilever 以 10 億美元的價格被收購
- Uber 如何使用 Mesos 和 Cassandra 跨多個數據中心每秒管理一百萬個寫入
- 從將 Uber 擴展到 2000 名工程師,1000 個服務和 8000 個 Git 存儲庫獲得的經驗教訓
- QuickBooks 平臺
- 美國大選期間城市飛艇如何擴展到 25 億個通知
- Probot 的體系結構-我的 Slack 和 Messenger Bot 用于回答問題
- AdStage 從 Heroku 遷移到 AWS
- 為何將 Morningstar 遷移到云端:降低 97%的成本
- ButterCMS 體系結構:關鍵任務 API 每月可處理數百萬個請求
- Netflix:按下 Play 會發生什么?
- ipdata 如何以每月 150 美元的價格為來自 10 個無限擴展的全球端點的 2500 萬個 API 調用提供服務
- 每天為 1000 億個事件賦予意義-Teads 的 Analytics(分析)管道
- Auth0 體系結構:在多個云提供商和地區中運行
- 從裸機到 Kubernetes
- Egnyte Architecture:構建和擴展多 PB 內容平臺的經驗教訓
- 縮放原理
- TripleLift 如何建立 Adtech 數據管道每天處理數十億個事件
- Tinder:最大的推薦引擎之一如何決定您接下來會看到誰?
- 如何使用微服務建立財產管理系統集成
- Egnyte 體系結構:構建和擴展多 PB 分布式系統的經驗教訓
- Zapier 如何自動化數十億個工作流自動化任務的旅程
- Jeff Dean 在 Google 進行大規模深度學習
- 如今 Etsy 的架構是什么樣的?
- 我們如何在 Mail.Ru Cloud 中實現視頻播放器
- Twitter 如何每秒處理 3,000 張圖像
- 每天可處理數百萬個請求的圖像優化技術
- Facebook 如何向 80 萬同時觀看者直播
- Google 如何針對行星級基礎設施進行行星級工程設計?
- 為 Mail.Ru Group 的電子郵件服務實施反垃圾郵件的貓捉老鼠的故事,以及 Tarantool 與此相關的內容
- The Dollar Shave Club Architecture Unilever 以 10 億美元的價格被收購
- Uber 如何使用 Mesos 和 Cassandra 跨多個數據中心每秒管理一百萬個寫入
- 從將 Uber 擴展到 2000 名工程師,1000 個服務和 8000 個 Git 存儲庫獲得的經驗教訓
- QuickBooks 平臺
- 美國大選期間城市飛艇如何擴展到 25 億條通知
- Probot 的體系結構-我的 Slack 和 Messenger Bot 用于回答問題
- AdStage 從 Heroku 遷移到 AWS
- 為何將 Morningstar 遷移到云端:降低 97%的成本
- ButterCMS 體系結構:關鍵任務 API 每月可處理數百萬個請求
- Netflix:按下 Play 會發生什么?
- ipdata 如何以每月 150 美元的價格為來自 10 個無限擴展的全球端點的 2500 萬個 API 調用提供服務
- 每天為 1000 億個事件賦予意義-Teads 的 Analytics(分析)管道
- Auth0 體系結構:在多個云提供商和地區中運行
- 從裸機到 Kubernetes
- Egnyte Architecture:構建和擴展多 PB 內容平臺的經驗教訓