# Egnyte 體系結構：構建和擴展多 PB 分布式系統的經驗教訓 > 原文： [http://highscalability.com/blog/2016/2/15/egnyte-architecture-lessons-learned-in-building-and-scaling.html](http://highscalability.com/blog/2016/2/15/egnyte-architecture-lessons-learned-in-building-and-scaling.html)  *這是 [Kalpesh Patel](https://www.linkedin.com/in/kpatelatwork) 的來賓帖子，他是在家工作的建筑師。 他和他的同事們花費大量的工作時間擴展了那里最大的分布式文件系統之一。 他在 [Egnyte](https://www.egnyte.com/) （一家企業文件同步共享和分析啟動）中工作，您可以在 [@kpatelwork 與他聯系 ]](https://twitter.com/kpatelwork) 。* 您的筆記本電腦有一個文件系統，該文件系統被數百個進程使用，它受到磁盤空間的限制，無法彈性擴展存儲，如果您運行很少的 I / O 密集型進程或嘗試與 100 個其他用戶共享它，它會很麻煩。 現在解決這個問題，并將其放大為遍布全球的數百萬付費用戶使用的文件系統，您將可以通過云霄飛車擴展該系統，以滿足每月的增長需求并滿足 SLA 要求。 **Egnyte 是一家企業文件同步和共享創業公司**，成立于 2007 年，當時 Google 硬盤還沒有誕生，而 AWS S3 的成本卻很高。 我們唯一的選擇是放開袖子，自己建立一個對象存儲，S3 和 GCS 的超時成本變得合理，并且由于我們的存儲層基于插件體系結構，因此我們現在可以插入任何便宜的存儲后端。 我們已經多次重新架構了許多核心組件的架構，在本文中，我將嘗試分享當前的架構是什么，我們學到的擴展規模的經驗教訓以及我們仍需改進的內容。 ## 平臺 * Tomcat * MySQL * HAProxy * Nginx * Memcached * Apache * [Elasticsearch](https://www.elastic.co/) * Redis * RabbitMQ * CentOS * 人偶 * 新遺物 * AppDynamics * ZooKeeper * LDAP * Nagios * 石墨 * 仙人掌 * Apache FTP 服務器 * OpenTSDB * Google BigQuery * Google BigTable * Google Analytics * MixPanel * 表格 * ReactJS /主干/木偶/ jQuery / npm / nighwatch * Rsync * [PowerDNS](https://www.powerdns.com/) * 服裝 * 基于 REST API 的 SOA 體系結構。 * Java 用于驅動核心文件系統代碼 * Python 通常用于驅動大多數客戶端代碼，遷移腳本，內部腳本。 一些 python 代碼仍然駐留在服務器上，但是由于我們有更多的 Java 熟悉和擴展經驗的服務器開發人員，大多數 python 代碼已遷移到 Java。 * 原生 Android / iOS 應用 * 適用于各種平臺的桌面和服務器同步客戶端 * GCE * GCS / S3 / Azure /...。 ## 統計信息 * 3 個主要數據中心，包括歐洲的 1 個（由于安全港規定） * 200 多個 Tomcat 服務節點 * 由 Tomcat / nginx 提供支持的 300 多個存儲節點 * 100 多個 MySQL 節點 * 50 多個 Elasticsearch 節點 * 20 多個 HAProxy 節點 * 和許多其他類型的服務節點 * 我們服務器和 GCS 中存儲了數 PB 的數據 * 在 Elasticsearch 中建立索引的數 PB 數據內容 * 許多桌面客戶端將文件與云同步 ## 認識您 ### 您的系統名稱是什么，我們在哪里可以找到更多信息？ Egnyte 是啟動公司的名稱，核心系統有很多主要部分，例如 CFS（云文件服務器），EOS（Egnyte 對象存儲），事件同步和...。您可以在中找到更多關于這些的內容 [對于技術人員](https://www.egnyte.com/blog/category/for-the-techies/) 部分，在我們的博客中。 ### 您的系統是干什么的？ 它推動了成千上萬企業的同步和共享需求，而云使它們現有的文件系統可以被 FTP，webdav，移動，公共 api，Web UI 和...等各種端點使用。 ### 您為什么決定構建此系統？ 在 2007 年，企業/員工隊伍開始變得更加分散，客戶正在使用多個設備來訪問相同的文件，并且有必要使這種體驗盡可能的順暢 ### 您的項目經費如何？ 這是一家自負盈虧的公司，后來我們在過去 8 年中進行了 5 輪募集，籌集了 6250 萬美元的 [。](https://www.crunchbase.com/organization/egnyte#/entity) ### 您的收入模式是什么？ 我們沒有免費用戶，但是我們提供 15 天免費試用，之后客戶無需支付席位即可付費。 ### 您如何銷售產品？ 我們從 SEM / SEO 開始，但隨著時間的增長，我們通過許多渠道為企業客戶爭取了諸如社交媒體，Biz 開發，貿易展覽，SEM，SEO，入站營銷和高聯系銷售的客戶。 ### 您從事這項工作多久了？ 它成立于 2007 年，目前已有 8 年的歷史。 ### 您的系統多大？ 嘗試感受一下系統的工作量。 我們存儲數十億個文件和多個 PB 的數據。 根據 New Relic，我們平均每秒觀察到超過 2K 的 api 請求。 由于安全港規定和位置相近，我們將數據存儲在 3 個主要數據中心中。 有關更多信息，請參見統計信息部分。 ### 您的輸入/輸出帶寬使用量是多少？ 我沒有確切的數字，因為它一直在增長，但是客戶上個月下載了接近 1 PB 的壓縮/未壓縮數據。 ### 您提供多少份文件？ 多少張圖片？ 多少數據？ 我們存儲數十億個文件和多個 PB 的數據。 我們存儲各種文件，而我們的前 5 個文件擴展名是 pdf，doc / docx，xl??s / xlsx，jpeg 和 png。 ### 免費用戶與付費用戶的比例是多少？ 我們所有的用戶均為付費用戶。 我們提供 15 天的免費試用期，之后將其轉換或將其禁用。 ### 在過去一個月中有多少個帳戶處于活動狀態？ 我們所有的客戶都是付費帳戶，并且每個月幾乎所有人都處于活動狀態。 我們滿足他們文件系統的需求，誰在家不用電？ ## 您的系統如何設計？ ### 您的系統的體系結構是什么？ 我們使用基于 REST 的面向服務的體系結構，它使我們能夠獨立擴展每個服務。 這也使我們能夠將某些后端服務移至公共云中托管。 所有服務都是無狀態的，并使用數據庫或我們自己的對象存儲進行存儲。 由于服務眾多，因此很難將所有服務都繪制在一張圖中。 10,000 英尺的 [典型請求流](https://www.egnyte.com/blog/2015/02/handling-millions-of-requests-at-egnyte/) 的外觀如下  大約 10000 英尺的 [搜索架構](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) 如下  ### 您的系統面臨哪些特定的設計/架構/實施挑戰？ 最大的 架構 挑戰包括：- 1. 節儉地擴展文件存儲 2. 擴展元數據訪問 3. 文件與桌面客戶端的實時同步 ### 您是如何應對這些挑戰的？ 1. 對于存儲，我們編寫了自己的存儲，現在我們使用可插拔的存儲體系結構來存儲到任何公共云，例如 S3，GCS，Azure...。 2. 為了擴展元數據，我們移至 Mysql 并開始使用分片。 在某個時候，我們暫時投入了更多的硬件來騰出空間，以便一層一層地剝去鱗屑洋蔥。 3. 對于實時同步，我們必須更改同步算法，使其更像 Svn，客戶端接收增量事件并嘗試與云狀態進行最終的一致同步。 4. 監視，監視和監視。 您無法優化無法衡量的內容。 在某個時刻，我們監控太多，無法專注于所有指標，我們不得不依靠異常檢測工具，例如 New Relic，AppDynamics，OpenTSDB 和自定義報告，以使我們能夠專注于從綠色變為[...] >黃色->紅色。 目的是在客戶通知 之前，將它們捕獲為黃色， [時捕獲它們。](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) ### 您的系統如何發展以應對新的擴展挑戰？ 我們已經多次重新構造了許多層。 我無法在本文中全部說明，但我將嘗試列出過去 7 年中核心元數據，存儲，搜索層的幾次迭代。 1. 版本 1：在 Lucene 中搜索文件元數據，通過 NFS 安裝在 DRBD Filers 中存儲的文件，在 Lucene 中搜索。 阻塞點 ：Lucene 更新不是實時的，必須替換。 2. 版本 2：Berkeley db 中的文件元數據，通過 NFS 安裝在 DRBD Filers 中的文件，在 lucene 中搜索。 阻塞點 ：我們突破了 NFS 的限制，它在左右兩側都阻塞了，必須用 http 代替。 3. Version3：Berkeley db 中的文件元數據，通過 HTTP 服務的 EOS Filers 中存儲的文件，在 lucene 中搜索。 阻塞點 ：即使分片的 Berkeley DB 在壓力下也阻塞，并且數據庫崩潰，恢復工作數小時，必須更換它。 4. 版本 4：MySQL 中的文件元數據，通過 HTTP 服務的 EOS Filers 中存儲的文件，在 lucene 中搜索。 阻塞點 ：公共云開始變得便宜。 5. 版本 5：MySQL 中的文件元數據，存儲在 EOS / GCS / S3 / Azure 中并通過 HTTP 提供的文件，在 lucene 中進行搜索。 阻塞點 ：搜索開始阻塞，必須更換。 6. 版本 6：MySQL 中的文件元數據，通過 HTTP 服務的 EOS / GCS / S3 / Azure 中存儲的文件，在 Elasticsearch 中搜索。 這是當前的體系結構，很快，其中一個可能需要另一個輪回：)。 ### 您是否使用任何特別酷的技術或算法？ * 在核心服務之間進行呼叫時，我們使用 [指數退避](https://en.wikipedia.org/wiki/Exponential_backoff) 指數斷路器，以避免斷路器打雷。 * 我們在核心服務節點資源上使用公平分配分配方式來處理傳入請求。 標記核心服務節點上的每個傳入請求并將其分類為不同的組。 每個組都有專用的容量，如果一個客戶每秒發出 1000 個請求，而另一個客戶每秒發出 10 個請求，則此系統將確保第二個客戶不會遇到嘈雜的鄰居問題。 訣竅是，由于散列，兩個客戶都可能偶然巧合地落在某個節點上的同一組上，但是他們不會在所有節點上都落在同一組上，因此我們將節點名稱添加為哈希值。 * 帶有 SLA 的某些核心服務被隔離在 POD 中，這確保了一個不好的客戶不會阻塞整個數據中心。 * 我們在桌面同步客戶端代碼中使用基于事件的同步，因為發生服務器事件時，它們會從服務器推送到客戶端，并且客戶端會在本地重播它們。 ### 您做什么工作是與眾不同的，人們可以從中學到什么？ 專注于啟動的核心功能，如果您必須構建自定義功能，則可以這樣做。 有很多獨特的東西，但是存儲層，基于事件的同步絕對值得學習，在這里有更多詳細信息。 [規范文件系統](https://www.egnyte.com/blog/2015/04/egnyte-canonical-file-system/) 。 ## 您學到了什么？ * 您無法優化您無法測量的內容：測量所有可能的結果，然后優化系統中使用率最高為 80％的部分。 * 當您身材矮小的時候，請慢慢介紹技術，不要試圖從中找到解決當前問題的理想工具。 編碼是生命周期中最簡單的部分，但是如果您最初擁有太多技術，則其維護（如部署/操作/學習曲線）將非常困難。 當您很大時，您將有足夠的脂肪來劃分服務，并讓每個服務使用其自己的技術并進行維護。 * 當您是一家初創公司時，有時您需要快速采取行動，介紹您現在可以做的最好的解決方案，如果發現有牽引力，請加班對其進行重新設計。 * 尋找單點故障，并不懈地尋找下來。 付出額外的努力來解決使您徹夜難眠的問題，并盡快從防御模式轉變為進攻模式。 * 在 SOA 中，如果您的服務受阻，則構建斷路器以開始發送 503s。 與其懲罰每個人，不如看看是否可以公平分配資源并僅懲罰濫用用戶。 * 在服務使用者中添加了自動修復功能，服務可能會阻塞，并且桌面客戶端或其他服務之類的消費者可以進行指數補償以釋放服務器壓力，并在該服務再次運行時自動修復。 * 始終可用：請提供服務級別的斷路器和客戶提供的斷路器。 例如 如果通過 webdav 或 FTP 訪問文件系統存在性能問題，并且需要 4 個小時進行修復，那么在這 4 個小時內，您只需在防火墻處殺死 FTP / webdav 并要求客戶使用 Web ui 或其他機制即可工作。 同樣，如果一個客戶造成了異常而使系統窒息，則可以暫時禁用該客戶或該客戶的服務，并在問題解決后重新啟用它。 為此，我們使用功能標志和斷路器。 * 保持簡單：每個月都有新工程師加入，因此目標是從第一周開始就提高他們的生產力，簡單的架構可確保輕松上崗。 ### 您為什么成功？ 牽引力勝過一切。 當 EFSS 市場剛剛爆發時，我們達到了 [產品/市場適合度](https://www.linkedin.com/pulse/marc-andreessen-product-market-fit-startups-marc-andreessen) 。 具有良好執行力的時機，管理團隊的財務紀律導致成功。 許多競爭對手采用了免費增值模式，并籌集了大量資金，但是從第一天開始我們就開始收費，這使我們能夠專注于根據市場需求發展解決方案/團隊。 專注于付費客戶使我們能夠交付企業級解決方案，而無需支付免費增值罰金。 ### 您希望自己做些什么？ 我希望當我們開始時公共云的成本不會過高。 我也希望我們從第一天開始就使用 SOA，花了一些時間才到達那里，但是現在我們就在那里。 ### 您不會更改什么？ 目前，我不會替換 MySQL / EOS，因為它允許我們從防御定位轉向進攻定位。 我不能在兩年后發表評論，我會有相同的想法，我們可能會更改或擴大其中一些想法。 當您遇到下一個增長突增時，架構會發生變化。 ## 您應該做多少前期設計？ 很好的問題。 答案是“取決于”， * 如果您要設計諸如核心存儲層或核心元數據層之類的東西，那么再多花 2 周的時間對設計就不會造成太大的影響。 當我們在核心元數據層上從 Berkeley DB 遷移到 MySQL 時，我承受著很大的壓力，我曾想過要走捷徑，當我通過首席技術官運行時，他建議花一些時間并“做正確的事”。 作為回顧，這是一個極好的決定。 * 對于公共 API，最好做一個不錯的前端設計，因為您沒有第二次機會對其進行更改，并且必須將其維護 4-5 年。 * 但是，如果您要為內部服務設計一些東西并將其遷移到新架構將不會花費一年，那么我建議您進行非常少的前端設計，并快速構建版本并隨著使用量的增加對其進行迭代。 ## 您如何考慮將來更改架構？ * 在一周中進行部署（我們快到了） * 將更多公共云用于任何新服務，并將更多服務遷移到公共云。 * 將其余的源代碼從 svn 移至 git * 使當前的開發環境盡可能接近生產環境（可以使用 docker 或…）。 * 自動化架構管理 * 添加更多性能基準測試 * 建立持續的交付渠道，以便我們可以將部署增加為每周或每天，而不是每兩周一次。 * 通過重新構建從某些增長最快的表中刪除聯接。 * 為 Mysql 分片添加自動平衡器，因此我不必擔心偶爾出現的熱點。 * 將某些脂肪服務分成顆粒狀 * 使用內存緩存代理 ## 您的團隊如何設置？ ### 您的團隊中有多少人？ 大約有 100 名工程師（devops / ops / qa / developers /…），其余是銷售，市場營銷，支持和人力資源。 ### 他們在哪里？ 最初是分布相當分散的工程團隊，但現在主要吸引人是孟買的 [波茲南](https://en.wikipedia.org/wiki/Pozna%C5%84) 。 一些像我這樣的遠程員工 和其他一些員工在家工作。 ### 誰扮演什么角色？ 這是一個很大的團隊，我們有產品經理，UX 團隊，開發人員，Scrum 團隊，架構師，工程師扮演各種角色。 最初，工程團隊很平坦，每個人都會向工程副總裁報告，但現在我們在兩者之間增加了一層管理。 ### 您是否有特定的管理理念？ 如果您開發某些產品，那么您擁有該產品的生命周期，這意味著您將與 QA，devops 一起確保其測試/部署。 投入生產時，您可以使用各種內部工具（例如 New Relic / Nagios）對其進行監視，如果存在回歸，則可以對其進行修復。 ### 如果您有分散的團隊，該如何工作？ 自治，1-1 交流，黑客馬拉松使他們具有挑戰性，他們會受到激勵。 ### 您的開發環境是什么？ * 適用于服務器團隊的 Ubuntu * UI 團隊使用 Windows / mac 并連接到用于 REST API 服務器的本地 Ubuntu VM 或連接到共享的 QA 實例 * Eclipse /想法 * 適用于構建的 * Maven * Git / SVN * 詹金斯 * ReviewBoard / Sonar * JIRA * Google 文檔 * Jabber / Slack / Hangouts / Skype ### 您的開發過程是什么？ 我們在服務器團隊中使用 Scrum，并且每兩周發布一次。 長期功能開發人員/團隊在沙盒上工作，完成后通過單元測試/硒/手動 QA 對它進行測試，然后合并到主干以捕獲 2 周的發布流程。 我們吃了自己的狗糧，代碼在發布前 1 周發布到了 UAT（所有員工使用的 egnyte.egnyte.com），我們發現了自動測試未發現的任何意外情況。 我們每個星期五晚上進行生產部署， [每天監視新文物，并報告任何異常的異常報告](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) 。 我們正在將部署更改為即將在一周中完成。 ### 您有什么可以做的不同還是感到驚訝？ 許多工程師在家工作，令人驚訝的是，有了自主權，許多遠程員工像總部員工一樣富有生產力和積極性。 ## 您使用什么基礎架構？ ### 您使用哪種語言來開發系統？ 大多數是 Java / Python ### 您有多少臺服務器？ 最后，我知道我們有 700 多個。 100 多個 MySQL 服務器，50 多個 Elasticsearch，200 多個 tomcat 服務節點，300 多個本地存儲節點，20 多個 HAProxy 節點和緩存文件管理器，nginx，python 服務器以及其他各種節點。 ### 如何將功能分配給服務器？ 我們使用面向服務的體系結構，并根據服務類型分配服務器。 一些頂級服務是： * 元數據 * 儲存空間 * 對象服務 * Web UI * 索引 * EventSync * 搜索 * 審核 * 快照/數據監視器 * 內容智能 * 實時事件傳遞 * 文本提取 * 集成 * 縮略圖生成 * 防病毒軟件 * 垃圾郵件 * 預覽版 * rsync * API 網關 * 結算 * 支持 * 銷售 * 等等。 ### 如何配置服務器？ 大多數服務都是偽造的，并在 VM 上運行，我們僅針對 MySQL，memcached，Metadata 服務器，索引之類的少數事物進行物理運行，但是除了數據庫/緩存/存儲節點之外，大多數服務都會轉換為 VM。 我們使用第三方根據模板來配置服務器，并將其放入數據中心，以供使用。 ### 您使用什么操作系統？ CentOS7 ### 您使用哪個 Web 服務器？ Nginx，Apache。 在一些舊的流程中使用了 Apache，但隨著時間的流逝，它將被棄用。 ### 您使用哪個數據庫？ MySQL。 我們過去曾使用過其他數據庫，例如 Berkeley DB，Lucene，Cassandra，但由于開發人員/操作人員的熟悉程度和可伸縮性，我們將所有數據庫都超時遷移到了 MySQL。 有關更多信息，請參見 Egnyte 的 [MySQL](https://www.egnyte.com/blog/2012/10/mysql-at-egnyte/) 。 ### 您是否使用反向代理？ 是 Nginx 和 HAProxy ### 您是否并置，使用網格服務，使用托管服務等？ 我們搭配。 ### 您的存儲策略是什么？ 我們首先創建自己的服務器，然后在機器中打包盡可能多的硬盤驅動器，我們過去將它們稱為 DRBD Filers。 我們這樣做是因為 AWS 成本過高。 我們已經評估了 [GlusterFS](https://www.gluster.org/) ，但當時它無法擴展以滿足我們的需求，因此我們構建了自己的。 加班 S3 變得便宜了，GCS / Azure 誕生了，我們將存儲層設計為可插入的，因此現在客戶可以決定要使用哪個存儲引擎（例如，Egnyte，S3，GCS，Azure 等）。 ### 您如何增加產能？ 我們進行能力計劃會議，并根據監控指標中的關鍵指標并預定一些額外的能力得出了一些指標。 現在，某些服務已啟用云服務，我們只需單擊一下按鈕即可提供更多服務。 ### 您是否使用存儲服務？ 是 Egnyte，S3，GCS，Azure 和 ### 您如何處理會話管理？ 我們多次重寫了體系結構，目前 99％的服務是無狀態的。 只有服務 Web UI 的服務使用會話，我們在 [memcached-session-manager](https://code.google.com/archive/p/memcached-session-manager/) 支持的 tomcat 中使用粘性會話，但最終我的計劃是使它也變得無狀態 。 ### 您的數據庫是如何設計的？ 主從？ 碎片？ 其他？ 我們幾乎對所有具有自動故障轉移功能的數據庫都使用了 Master-Master 復制，但是在一些突變程度很大的數據庫上的切換是手動完成的，我們遇到了一些問題，其中由于復制滯后，自動切換會導致應用程序數據不一致，我們 需要重新架構一些核心文件系統邏輯來解決此問題，我們最終將完成此工作。 下面是有關處理數據庫升級的問題，詳細回答了有關數據庫體系結構的更多詳細信息。 ### 您如何處理負載平衡？ 我們根據客戶使用 DNS 訪問系統的 IP 進行地理平衡，并在數據中心內使用 HAProxy 將其路由到相應的 POD，并在內部 POD 中再次使用 HAProxy 路由他們 ### 您使用哪個 Web 框架/ AJAX 庫？ 我們已經多次更改了 UI，這是一直在變化的一件事。 過去我們曾經使用過 ExtJS，YUI，JQuery，而沒有使用過。 最新的迭代基于 ReactJS / Backbone / Marionette 。 ### 您使用哪種實時消息框架？ 我們使用 [大氣](https://github.com/Atmosphere/atmosphere) ，但最終我們將其替換為 NodeJS ### 您使用哪個分布式作業管理系統？ 為此，我們使用 RabbitMQ 和基于 Java / python 的消費者服務。 ### 您的網站是否有標準 API？ 如果是這樣，您將如何實施？ 我們的 API 分為 3 種類型：- 1. 公共 API： 這是我們向第三方應用程序開發人員和集成團隊以及我們的移動應用程序公開的 api。 我們會按照正確的棄用工作流程棄用/升級 api 簽名，并且更改始終向后兼容。 我們使用 Mashery 作為網關，API 記錄在 [https://developers.egnyte.com/docs](https://developers.egnyte.com/docs) 2. 適用于我們客戶的 API： 此 API 對我們客戶而言是內部的，如果我們以外的人使用此 api，則我們不保證向后兼容。 3. 服務之間的內部受保護的 API ：這是服務在我們的數據中心內部用于彼此通信的 API，無法從外部防火墻調用。 ### 您的對象和內容緩存策略是什么？ 我們存儲 PB 的數據，但無法緩存所有數據，但是如果客戶在給定的 15 天時間內擁有 5000 萬個文件，則他可能只使用其中的 100 萬個文件。 我們有基于 tomcat / nginx / local 文件系統的緩存文件管理器節點，它以 LRU 方式運行。 我們可以彈性增加減少緩存文件服務器的數量。 我們最大的問題之一是上傳速度，如何從世界任何地方盡可能快地將數據上傳到 Egnyte，為此，我們構建了特殊的 Network pops。 [為 Egnyte 客戶加速數據訪問](https://www.egnyte.com/blog/2014/03/speeding-up-data-access-for-our-customers/) Memcached 用于緩存元數據，我們使用單獨的 memcached 池來緩存長期存在的靜態數據和文件系統元數據。 核心文件系統元數據非常龐大，不適合當前的內存緩存節點，并且會逐出最近使用的其他類型的數據。 為防止這種情況，我們使用 2 種池，應用程序代碼決定在哪里查找哪種數據。 我們允許在文件系統 Memcached 緩存中逐出，并在其他種類的 Memcached 池中爭取零逐出。 ### 您的客戶端緩存策略是什么？ 對于我們的 Web ui，我們使用 PageSpeed 進行資源優化，緩存，并使用 requireJS 和其他各種方式僅下載所需的模塊。 我們的 Mobile 和 Desktop 客戶端豐富使用本地文件系統作為緩存。 ### 您使用哪些第三方服務來幫助您構建系統？ Google BigQuery，New Relic，AppDynamics，MixPanel，Flurry，Tableau 是我們使用的一些分析服務，但大多數核心組件均由我們構建。 ## 您如何管理系統？ ### 如何檢查全局可用性并模擬最終用戶性能？ 我們使用不同 AWS 區域中的節點來一致地測試帶寬性能。 我們還使用內部 haproxy 報告來繪制客戶觀察到的上載/下載速度，并主動尋找它們，并使用網絡彈出消息和其他策略來加速數據包。  ### 您如何健康檢查服務器和網絡？ 使用 Nagios 監視器和 New Relic 以及一些內部主動異常分析。 有關更多詳細信息，請參見此 [博客文章](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) ### 如何繪制網絡和服務器統計數據以及趨勢圖？ 我們使用石墨，仙人掌，Nagios 和 New Relic，AppDynamics。   ### 您如何測試系統？ 硒，Junit，鼻子，睡表和手動測試。 ### 您如何分析效果？ New Relic，AppDynamics 用于監視生產 tomcat 節點的性能。 我們使用石墨/ nagios /內部工具和其他工具來監視系統其他部分的性能。 有關此問題的更多詳細信息，請參見此博客文章 [分布式系統中的調試性能問題](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) ### 您如何處理安全性？ 專用安全團隊在每個版本之前都會運行自動化的安全基準測試。 連續自動化筆測試已在生產中運行。 我們還使用漏洞賞金計劃并與 Whitehat 測試公司合作。 一些客戶使用第三方進行自己的安全性測試。 ### 您如何處理客戶支持？ 我們有專門的 24X7 分布式客戶成功團隊，我們使用 Zendesk 和 JIRA ### 您是否實施網絡分析？ 我們使用 Google Analytics（分析），Mixpanel，Flurry 來衡量功能使用情況 ### 您是否進行 A / B 測試？ 是的，我們使用功能標記進行 A / B 測試。 有關更多信息，請參見 [在 Egnyte 使用功能標志](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) ### 您要運行多少個數據中心？ 3 個主要數據中心，其中一個在歐洲（由于安全港規定） ，網絡遍布世界各地。 ### 您的系統如何部署在數據中心中？ Puppet 用于部署大多數新代碼。 我們仍在重寫架構中最后的幾篇文章，這些文章目前都是使用 Shell 腳本部署的。 ### 您使用哪種防火墻產品？ 我們混合使用了瞻博網絡 SRX 和 Fortigate 防火墻。 ### 您使用哪個 DNS 服務？ PowerDNS ### 您使用哪些路由器？ 思科 ### 您使用哪些開關？ Arista ### 您使用哪個電子郵件系統？ 我們使用自己的 SMTP 服務器來處理出站電子郵件，對于一些內部工具，我們使用 SendGrid，對于入站電子郵件，我們使用 GMail。 ### 如何備份和還原系統？ 對于 MySQL，我們使用 [Percona XTraBackup](https://www.percona.com/doc/percona-xtrabackup/2.3/index.html) ，對于 Elasticsearch，該數據被復制 3 次，并且我們還使用 ElasticSearch GCS 備份插件將數據備份到 GCS。 對于客戶文件，我們將其復制 3 次。 如果存儲 Filer 無法恢復，我們將丟棄它，添加一個新 Filer 并再次復制副本。 對于某些客戶，我們還會將其數據復制到他們選擇的提供者。 對于使用 S3，Azure 或 GCS 作為可插拔存儲層的客戶，它將確保復制以防止數據丟失。 ### 如何進行軟件和硬件升級？ 大多數節點是無狀態的，并且有狀態組件具有主動-主動故障轉移。 通過將節點從池中取出并進行升級并將其放回池中來處理升級。 ### 您如何處理升級時數據庫架構的重大更改？ 不同的服務使用不同類型的數據庫，并且它們以不同的方式升級。 在 10000 英尺處，它們如下圖所示：  1. EOS db 存儲對象元數據并且增長非常快，它經過分片，并且我們將繼續添加更多此類數據。 2. MDB 的增長速度更快，經過了分片，并且我們會繼續增加更多。 3. DC_central 是 dns 數據庫，并且保持相當靜態。 我們運行了許多此副本以實現可伸縮性。 4. Pod_central 具有快速變異的數據，但每個表的增長量不超過 2000 萬行。 我們運行了許多此副本以實現可伸縮性。 * 每個數據庫架構始終是向前和向后兼容的，即我們絕不會在同一發行版中刪除列和代碼，我們首先在發行版 1 中部署停止使用該列的代碼，而在發行版 2 中兩周后，我們刪除該列。 * 非分片數據庫每 2 周更新一次。 它們是存儲各種功能驅動表的表。 我們目前正在使用腳本升級它們，但現在已更改為使用 [Sqitch](http://sqitch.org/) * 使用自動腳本進行分片 db 新列更改 * 分片數據庫遷移是一件痛苦的事情，因為我們有 7000 多個分片并且還在不斷增長，您無法在 1 小時的升級窗口中完成。 方法是： * 實時代碼根據需要遷移行。 這意味著遷移可能會持續數年。 * 使用功能標記遷移，您同時擁有新舊代碼，并且在后臺遷移客戶，然后翻轉標記以將其切換到新代碼路徑而無需停機，更多的是 [ [此處](https://www.egnyte.com/blog/2014/01/how-we-migrated-millions-of-users-from-ldap-to-mysql-using-feature-flags/) 和 [此處](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) * 當我們從 lucene 遷移到 ElasticSearch 時，除了重新索引所有內容外，我們別無選擇，我們使用 [功能標記](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) 進行了檢索，大約花了 3 -4 個月完成。 * 模式一致性檢查器報告可確保升級后所有數據中心中的所有模式均相同。 ### 您是否有單獨的運營團隊來管理您的網站？ 是的，我們有一個專門的 devops 團隊和一個 IT / Ops 團隊，負責監視和管理系統。 ## 其他 ### 您欣賞誰？ AWS ：他們的創新步伐令人贊嘆。 Google ：他們的工具，例如 BigQuery，Analytics（分析）都很棒。 Elasticsearch ：其余 api 的簡單性和架構很棒。 MySQL： 即可。 Eclipse / Jenkins ：插件架構很好。 ### 您是否模仿了其他人的公司/方法？ 我們是 [http://highscalability.com/](http://highscalability.com/) 的常規讀者，許多設計都受到它的啟發。 * POD 架構的靈感來自 Tumblr 的 Cell 架構，雖然不完全匹配，但是隔離故障的概念是相同的。 * 受 Facebook 啟發的架構在 12 小時后會在內存緩存和刷新鍵中產生抖動。 * 受 [http://highscalability.com/上一些文章的啟發，將](http://highscalability.com/) [指紋添加到每個數據庫查詢](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) 我們正在招聘，請在 [職位頁面](http://www.egnyte.com/jobs/engineering.html) 中查看我們，然后在 [與我們聯系 [電子郵件保護的]](/cdn-cgi/l/email-protection) 。 [關于 HackerNews](https://news.ycombinator.com/item?id=11104555)