# Egnyte Architecture：構建和擴展多 PB 內容平臺的經驗教訓 > 原文： [http://highscalability.com/blog/2019/11/25/egnyte-architecture-lessons-learned-in-building-and-scaling.html](http://highscalability.com/blog/2019/11/25/egnyte-architecture-lessons-learned-in-building-and-scaling.html)  這是 [Kalpesh Patel](https://www.linkedin.com/in/kpatelatwork) 的來賓帖子，工程師是為 [Egnyte](https://www.egnyte.com/) 在家工作的。 Egnyte 是專門為企業構建的安全內容平臺。 他和他的同事們花費大量的時間來擴展大型分布式文件系統。 您可以通過 [@kpatelwork](https://twitter.com/kpatelwork) 與他聯系。 ## 簡介 您的筆記本電腦有一個文件系統，該文件系統被數百個進程使用。 但是，如果您希望使用它來支持數以萬計的用戶在處理同時包含 PB 級數據的數億個文件時有一些缺點。 它受磁盤空間的限制； 它無法彈性擴展存儲空間； 如果您運行一些 I / O 密集型進程或嘗試與 100 個其他用戶進行協作，就會感到窒息。 讓我們來解決這個問題，并將其轉換為遍布全球的數百萬付費用戶使用的云原生文件系統，您將了解我們過山車的規模，可以擴展該系統以滿足每月的增長和 SLA 要求，同時提供嚴格的一致性和 我們都期望筆記本電腦具有出色的耐用性。 Egnyte 是一個安全的內容協作和數據治理平臺，成立于 2007 年，當時 Google 硬盤還沒有誕生，而 AWS S3 卻禁止了成本。 我們唯一的選擇是袖手旁觀，自己構建基本的云文件系統組件，例如對象存儲。 隨著時間的推移，S3 和 GCS 的成本變得合理，并且借助 Egnyte 的存儲插件架構，我們的客戶現在可以引入他們選擇的任何存儲后端。 為了幫助我們的客戶管理持續的數據爆炸，我們在過去幾年中設計了許多核心組件。 在本文中，我將分享當前的體系結構以及我們所學到的擴展它的一些經驗教訓，以及我們希望在不久的將來進行改進的一些內容。 ## Egnyte Connect 平臺 Egnyte Connect 平臺使用 3 個數據中心來滿足來自全球數百萬用戶的請求。 為了增加彈性，可靠性和耐用性，這些數據中心使用高速，安全的 Google 互連網絡連接到 Google Cloud 平臺。  Egnyte Connect 運行一個服務網格，該網格從我們自己的數據中心延伸到提供多種服務類別的 Google 云： ### 合作 * 文檔存儲區 * 預覽版 * 視頻轉碼 * 分享 * 鏈接 * 權限 * 標簽 * 評論 * 任務 * 建議 ### 混合同步 * 處理 Prem 數據時 * 大文件或低帶寬 * 離線訪問 * 邊緣緩存 ### 基礎架構優化 * 遷移到云 * 優化保鮮庫的成本 * 合并存儲庫 通常，Egnyte 連接架構分片并基于以下條件在不同級別緩存數據： * 數據量 * 數據相互依存 * 并發讀取的級別 * 并發寫入級別  ， ## Egnyte Connect 技術堆棧 ### 云平臺 1. Google 云端 2. Azure 3. 托管數據中心 ### 語言： 1. Java 2. Python 3. 轉到 4. C ### 對象存儲區 * Egnyte 對象存儲區 * GCS * S3 * Azure ### 應用服務器 * Tomcat ### 數據庫 * MySQL * Redis * BigTable * 數據存儲 * Elasticsearch ### 緩存 * Memcached * Redis * Nginx 用于基于磁盤的緩存 ### 負載平衡器/反向代理 * HAProxy * Nginx ### 消息隊列 * Google Pub / Sub * 兔子 * 抄寫員 * Redis ### 部署管理 * 人偶 * Docker * Ansible * 詹金斯 * Gitlab * 調速器 ### 分析 * 新遺物 * OpenTSDB / bosun * Grafana * MixPanel * 表格 * BigQuery ### 其他 * ZooKeeper * Nagios * Apache FTP 服務器 * 孔 * ReactJS / Backbone / Marionette / JQuery / npm / Nightwatch * Rsync * PowerDNS * 服裝 * 基于 REST API 的 SOA 體系結構。 * Java 用于驅動核心文件系統代碼 * 用于支持客戶端代碼，某些微服務，遷移腳本，內部腳本的 Python * 原生 Android 和 iOS 應用 * 本機桌面和服務器托管的客戶端，允許對整個名稱空間進行交互以及混合同步訪問 ## 統計信息 * 3 個主要地區（其中一個在歐洲）使用 Google 互連連接到相應的 GCP 地區 * 500 多個 Tomcat 服務 實例 * 由 Tomcat / Nginx 提供支持的 500 多個存儲節點 * 100 多個 MySQL 節點 * 100 多個 Elasticsearch 節點 * 50 多個文本提取 實例 （自動縮放） * 100 多個 HAProxy 實例 * 許多其他類型的服務 實例 * 存儲在我們服務器和其他對象存儲區（例如 GCS，S3 和 Azure Blobstore）中的數十 PB 數據 * 在 Elasticsearch 中建立索引的多個 TB 提取內容 * 數百萬個桌面客戶端與云同步文件以進行脫機訪問 * 數百萬臺式客戶端以交互方式訪問文件 ## 認識您 ### 您的系統名稱是什么，我們在哪里可以找到更多信息？ Egnyte Connect 是內容協作和數據管理平臺。 CFS（云文件系統），EOS（Egnyte 對象存儲），內容安全性，事件同步，搜索服務，基于用戶行為的推薦服務構成了系統的主要部分。 您可以在我們博客的 [對于技術人員](https://www.egnyte.com/blog/category/for-the-techies/) 部分中找到更多相關信息。 ### 您的系統使用什么功能？ 作為內容協作和數據管理平臺的 Egnyte Connect 被成千上萬的客戶用作唯一的 安全內容平臺來滿足他們的所有文檔管理需求。 它是為承載各種文件服務 并為它們的現有文件存儲庫啟用云而構建的。 可以從各種端點（例如 FTP，WebDAV，移動，公共 API 和瀏覽器）訪問它，并具有強大的審核和安全組件。 ### 您為什么決定構建此系統？ 在 2007 年，企業開始變得更加分散。 客戶正在使用多種設備來訪問他們的文件，因此需要使這種體驗盡可能地順暢。 我們構建了 Egnyte Connect-一種安全的分布式文件系統，該系統將 Hybrid Sync 與 Cloud File System 相結合，可以滿足各種業務需求中企業的內容協作需求。 隨著本地和云存儲庫中數據的分散，以及由于 GDPR 等舉措而增加的合規性需求，我們構建了 Egnyte Protect 來幫助客戶滿足其合規性和治理需求。 ### 您的項目經費如何？ Egnyte 最初是一家自舉公司。 后來，我們繼續從高盛，Google Ventures，KPCB，Polaris Partners 和 Seagate 的多輪融資中籌集了 1.375 億美元的 [](https://www.crunchbase.com/organization/egnyte#/entity)。 ### 您的收入模式是什么？ Egnyte 不提供免費帳戶。 客戶從 15 天的免費評估試用期開始，之后，他們將根據席位數量，存儲空間和其他企業功能轉換為帶有收入模型的付費帳戶。 ### 您如何銷售產品？ 我們從 SEM / SEO 開始，但隨著時間的增長，我們使用了許多渠道來為社會客戶，社交媒體，商務開發，貿易展覽，SEM，SEO，入站營銷和企業級客戶進行高接觸銷售。 ### 您從事這項工作多久了？ Egnyte 成立于 2007 年。它已有 12 年的歷史，現金流量為正。 ### 您的系統多大？ 嘗試感受一下系統的工作量。 我們存儲數十億個文件和數十 PB 的數據。 在“ Egnyte connect”中，根據 New Relic，我們平均觀察到平均每秒超過 10K API 請求，平均響應時間為< 60ms。 由于安全港規定和位置相近，我們允許從 3 個主要地區訪問。 有關更多信息，請參見統計信息部分。 我們的“ Egnyte Protect”解決方案還持續監控內容和對許多客戶的合規性，治理和安全漏洞的訪問。 ### 您提供多少份文件？ 多少張圖片？ 多少數據？ 我們存儲數十億個文件和數十 PB 的數據。 我們存儲各種文件。 Egnyte 存儲的前 5 個文件擴展名是 pdf，doc / docx，xl??s / xlsx，jpeg 和 png。 ### 免費用戶與付費用戶的比例是多少？ 我們所有的用戶均為付費用戶。 我們提供 15 天的免費試用期，然后將其轉換為付費帳戶。 ### 在過去一個月中有多少個帳戶處于活動狀態？ 我們所有的客戶都是付費帳戶，并且每個月幾乎所有人都活躍。 我們滿足他們安全的內容平臺需求，誰在家不用電？ ## 您的系統如何設計？ ### 您的系統的體系結構是什么？ 我們使用基于 REST 的面向服務的體系結構，它使我們能夠獨立擴展每個服務。 這也使我們能夠將某些后端服務移至公共云中托管。 所有服務都是無狀態的，并使用數據庫或我們自己的對象存儲進行存儲。 10000 英尺的 Egnyte Connect 服務概述如下所示。  [典型請求流](https://www.egnyte.com/blog/2015/02/handling-millions-of-requests-at-egnyte/) 的 10000 英尺總覽如下  約 10000 英尺的 [搜索架構](https://www.egnyte.com/blog/2015/06/scaling-elasticsearch-at-egnyte/) 如下  ### 您的系統面臨哪些特定的設計/架構/實施挑戰？ 最大的 架構 挑戰包括： 1. 節儉地擴展文件存儲 2. 擴展元數據訪問 3. 文件與桌面客戶端的實時同步 4. 帶寬優化 5. 沖擊隔離 6. 緩存（分布式和內存中） 7. 功能首次展示 ### 您是如何應對這些挑戰的？ 1. 對于存儲，我們編寫了自己的存儲，現在我們使用可插拔的存儲體系結構來存儲到任何公共云，例如 S3，GCS，Azure ... 2. 為了擴展元數據，我們移至 Mysql 并開始使用分片。 在某個時候，我們暫時投入了更多的硬件來騰出空間，以便一層一層地剝去“鱗屑洋蔥”。 3. 對于實時同步，我們必須更改同步算法，使其更像 Git，客戶端接收增量事件并嘗試與云狀態進行最終的一致同步。 4. 為了推出功能，我們構建了一個自定義設置服務，允許工程師在功能標志后面編寫代碼。 這樣，即使在睡眠者模式下，您也可以釋放代碼并收集數據，然后按客戶，用戶或主機組或 POD 或數據中心啟用功能。 有了這種控制水平，即使是新工程師也可以放心地在功能標記后面編寫代碼并將其發布到生產環境中，而不必擔心停機時間。 5. 監視，監視和監視。 您無法優化無法衡量的內容。 不利的一面是，在某些時候，我們監控得太多了，以致于我們無法專注于所有指標。 我們必須轉移注意力，并依靠諸如 New Relic，bosun，ELK，OpenTSDB 和自定義報告之類的異常檢測工具，使我們能夠專注于從綠色->黃色->紅色趨勢發展的問題。 目的是在客戶通知 之前，將它們捕獲為黃色并且 [時捕獲它們。](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) ### 您的系統如何發展以應對新的擴展挑戰？ 我們已經多次重新構造了許多層。 我將嘗試列出過去 7 年中核心元數據，存儲，搜索層的一些迭代。 1. 版本 1：在 Lucene 中搜索 Lucene 中的文件元數據，通過 NFS 安裝在 DRBD Filer 中存儲的文件。 關鍵點： Lucene 更新不是實時的，必須替換。 2. 版本 2：Berkeley DB 中的文件元數據，通過 NFS 掛載的 DRBD Filers 中存儲的文件，在 Lucene 中搜索。 關鍵點： 我們打破了 NFS 的限制，它左右 and 住，必須用 HTTP 代替。 3. 版本 3：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 中搜索。 這是當前的體系結構。 7. 版本 7（未來）：將所有計算移至公共云，提供更多服務以實現影響隔離，動態資源池以有效管理寵物和牛。 ### 您是否使用任何特別酷的技術或算法？ * 我們在核心服務和服務之間進行呼叫時使用指數補償，以使用斷路器來避免打雷。 * 我們使用核心服務節點資源上的公平份額分配來處理傳入請求。 核心服務節點上的每個傳入請求都被標記并分為各種組。 每個組都有專用的容量，如果一個客戶每秒發出 1000 個請求，而另一個客戶每秒發出 10 個請求，則此系統將確保其他客戶不會因為鄰居吵鬧而挨餓。 訣竅是，如果您是目前使用該系統的唯一客戶，則可以全力以赴，但是隨著更多客戶同時出現，您可以在其中共享容量。 對于某些大型客戶，我們會分配專用池以確保一致的響應時間。 * 帶有 SLA 的某些核心服務被隔離在 POD 中，這確保了一個不好的客戶不會阻塞整個數據中心，但是這可能很快就需要輪回。 * 我們在桌面同步客戶端代碼中使用基于事件的同步，因為發生服務器事件時，它們會從服務器推送到客戶端，并且客戶端會在本地重播它們。 * 我們采用大規模數據過濾算法，以使大型客戶端集群與 Cloud File System 同步。 * 我們根據問題陳述使用不同類型的緩存技術。 很少有以下口味： * 傳統 * 內存中的-簡單的 * 不可變的對象 * 內存中的大型數據集 * 用于在各個進程之間實現高度一致性的鎖 * 已實施部分更新，以避免出現 GC * 內存中-高容量變異數據集 * 粗粒度無效 * 細粒度無效 * 基于磁盤的緩存 ### 您做什么工作是與眾不同的，人們可以從中學到什么？ 專注于啟動的核心功能，如果您遇到技術難題，就必須為其構建自定義內容，然后卷起袖子繼續前進。 有很多獨特的東西，但是基于事件的同步存儲層絕對值得學習，這里有更多詳細信息。 [Egnyte 對象存儲庫](https://www.egnyte.com/blog/2013/07/how-egnyte-implements-hybrid-object-stores-using-public-clouds-to-enhance-customer-experience/) 和 Egnyte [規范文件系統](https://www.egnyte.com/blog/2015/04/egnyte-canonical-file-system/) 。 ### 您學到了什么？ * 您無法優化您無法測量的內容：測量所有可能且相關的內容，然后首先優化 80％處于使用狀態的系統部分。 * 當您身材矮小的時候，請慢慢介紹技術，不要試圖從中找到解決當前問題的理想工具。 編碼是生命周期中最簡單的部分，但是如果您擁有太多的技術，則其維護（如部署/操作/學習曲線）將非常困難。 隨著您變得更大，您的部署中將有足夠的脂肪來逐步進行服務劃分。 學習保留一個或兩個服務模板來實現微服務，不要為每個服務使用不同的技術堆棧。 * 作為初創企業，有時您必須快速行動。 介紹您現在可以做的最好的解決方案，如果發現有牽引力，請隨著時間的推移重新設計該解決方案。 您可以嘗試 10 種不同的方法，而只有 1 種方法可以看到牽引力，因此請快速進行一些操作，然后在看到牽引力的方法上重新架構，以適應業務規模。 * 尋找單點故障，并不懈地追查它們。 付出額外的努力來解決使您徹夜難眠的問題，并盡快從防御性轉變為進攻性模式。 * 在 SOA 中，構建斷路器以盡早減輕負載，如果服務受阻，則開始發送 503s。 與其懲罰所有人，不如看看您是否可以公平分配資源并僅懲罰濫用請求。 * 在服務使用者中添加了自動修復功能，服務可能會停止運行，并且像臺式機客戶端或其他服務這樣的使用者可以進行指數補償以釋放服務器上的壓力，并在服務再次起作用時自動修復。 * 始終可用：請客戶提供服務級別的斷路器和斷路器。 例如，如果通過 WebDAV 或 FTP 訪問文件系統存在性能問題，并且需要 4 個小時來修復，那么在這 4 個小時內，您可以在 kong / firewall 殺死 FTP / WebDAV 并要求客戶使用 Web UI 或其他 工作機制。 同樣，如果一個客戶造成了導致系統阻塞的異常，則可以暫時為該客戶禁用該客戶或服務，并在解決問題后重新啟用它。 為此，我們使用功能標志和斷路器。 * 對于高度可擴展的服務，離開 Java 進程的成本很高，即使去了 Memcache 或 Redis 也是如此，因此我們對某些高度使用的數據結構（如訪問控制計算，功能標志，路由元數據等）進行了具有不同 TTL 的內存中緩存。 。 * 我們看到一種有關處理大數據集的模式。 優化代碼并擠走檸檬中的每一滴都是徒勞的，我們最終可能會使代碼變得復雜且檸檬水苦澀。 通常，最簡單的解決方案來自返回到繪圖板，看看我們是否可以： * 通過使用啟發式方法來減少我們需要處理的數據集大小 * 重組了我們在內存或磁盤中存儲數據的方式。 * 在寫時對數據進行規范化，并避免聯接。 * 基于時間的過濾，例如存檔較早的數據。 * 在多租戶數據結構中創建較小的碎片。 * 使用事件更新緩存數據集，而不是完全重新加載。 * 保持簡單：每個月都有新工程師加入，因此目標是從第一周開始就提高他們的工作效率-簡單的架構可確保輕松上崗。 ### 您為什么成功？ 牽引力勝過一切。 當 EFSS 市場剛剛爆發時，我們達到了產品/市場契合度。 良好的執行力，以客戶為中心，管理團隊遵守財務紀律的時機可以成功。 許多競爭者采用了免費增值模式并籌集了一大筆資金，但是從第一天開始我們就開始收費，這使我們能夠專注于隨著市場需求的擴大而發展解決方案/團隊。 專注于付費客戶使我們能夠提供企業級解決方案，而無需支付免費增值罰金。 ### 您希望自己做些什么？ 我希望當我們開始時，公共云不會像成本那樣高。 我也希望我們從第一天開始就使用 SOA，花了一些時間才到達那里，但是現在我們就在那里。 ### 您不會更改什么？ 體系結構應具有延展性。 四年前，對于給定的問題，我有不同的答案，但是目前，我不確定。 我的意思是，隨著您規模的擴大，過去 2 年前有效的設計模式和策略可能使您從防御性定位轉向進攻性定位可能會在壓力下屈服或變得成本過高。 只要更改將使系統變得有彈性或帶來 10 倍的更改并為我們再購買 3-4 年的規模，我便會繼續嘗試更改它。 我不能在兩年后發表評論，我會有同樣的想法，他們可能會改變。 當您遇到下一個增長突增時，架構會發生變化。 ### 您應該做多少前期設計？ 很好的問題。 答案是“取決于”， * 如果您要設計核心存儲層或核心元數據層之類的東西，那么再多花 2 周的時間就不會有多大傷害。 當我們在核心元數據層上從 Berkeley DB 遷移到 MySQL 時，我承受著很大的壓力，我想到了一條捷徑，當我通過我們的 CTO 運行它時，他建議花一些時間，“做正確的事情”。 ”作為回顧，這是一個極好的決定。 * 對于公共 API，最好做一個不錯的前端設計，因為您沒有第二次機會對其進行更改，并且必須在未來 4-5 年內進行維護。 * 如果要處理其 PB 級數據并帶來巨大麻煩，那么我將再給它一個月的時間并進行更多的 POC。 * 但是，如果您要為內部服務設計一些東西并將其遷移到新的體系結構不會花費一年的時間，那么我建議您進行非常少的前端設計，并且只需快速構建版本并隨著使用量的增長對其進行迭代 。 ### 您如何考慮將來更改架構？ * 從靜態 POD 轉移到動態 POD，并無縫處理寵物和牛。 * 提供更具彈性的服務并隔離影響。 * 將我們的整個計算移至公共云，同時保留數據中心用于提供文件。 這將使我們能夠在負載到來時自動放大/縮小。 我們已經使用公共云來自動擴展一些異步處理，例如視頻轉碼，文本提取，數據遷移，搜索等。 * 一旦進入云，請使用更多自動縮放服務，例如 BigTable，PubSub，Spanner 等。 * 將我們的部署從 VM 遷移到 Kubernetes 中的容器，以提供掛起的服務。 * 自動化剩余數據庫的架構管理 * 通過重新構建從某些增長最快的表中刪除聯接。 * 重寫元數據的緩存層，并使用 Redis 數據結構代替 Memcache。 * 將頻繁使用的流從強一致性轉換為最終一致性。 ## 您的團隊如何設置？ ### 您的團隊中有多少人？ 大約 700 名員工和承包商。 有 200 名工程師（DevOps / OPS / QA / Developers /…），其余為銷售，市場營銷，支持，產品管理，人力資源等。 ### 他們在哪里？ 最初是一支分布相當分散的工程團隊，但現在主要吸引了印度波蘭山景城的人。 一些像我這樣的遠程員工 和其他一些員工在家工作。 ### 誰扮演什么角色？ 這是一個很大的團隊，我們有產品經理，UX 團隊，DevOps，Scrum 團隊，架構師，工程師扮演各種角色。 最初，工程團隊很平坦，每個人都會向工程副總裁報告，但現在我們在兩者之間增加了一層管理。 ### 您是否有特定的管理理念？ 如果您開發某些產品，那么您便擁有該產品的生命周期，這意味著您將與質量保證和 DevOps 一起使用，以確保產品經過測試/部署。 投入生產時，您可以使用各種內部工具（例如 New Relic / Grafana，Kibana）對其進行監視，如果存在回歸，則可以對其進行修復。 我也是 1 人 1 任務理念的忠實擁護者，通過這種方式，如果工程師碰壁，他將找到某種最終克服它的方法，而不是太早放棄。 ### 如果您有分散的團隊，該如何工作？ 自治，1-1 交流給他們帶來挑戰性的問題，親自照顧和直接挑戰，他們會受到激勵。 ### 您的開發環境是什么？ * 適用于服務器團隊的 Ubuntu * UI 團隊使用 Windows / mac 并連接到用于 REST API 服務器的本地 Ubuntu VM 或連接到共享的 QA 實例 * Eclipse /想法 * 適用于構建的 * Maven * 碼頭工人 * Gitlab * Jenkins * 匯合 * JIRA * Google 辦公套件 * 松弛 ### 您的開發過程是什么？ 我們使用 Scrum，并為云文件系統團隊提供每周發布。 我們使用 git-flow 的變體，對于每個票證，我們克隆存儲庫，并對每個合并請求運行自動化測試。 合并請求必須經過 2 位工程師的批準，然后才能解決 JIRA 故障單。 解決后，我們的管道將接管工作，而票務將接下去的下一班火車。 下一版本的培訓已通過自動化 REST API 測試和一些手動煙霧測試進行了驗證。 我們吃了自己的狗糧，代碼在發布前 2-3 天送達了 UAT（供所有員工使用），我們發現了自動測試未發現的任何意外情況。 我們每個星期三進行生產部署， [每天監視新文物，并報告任何異常](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) 的異常報告。 我們在一周中更改了部署，以實現工作與生活之間的平衡，并且通過這種方式，我們將讓所有工程師可用，以防發布出現問題。 如果這是一項長期運行的功能，則工程師通常會在功能標志后面進行工作，并在各個階段以 sleeper 模式提交代碼，因此，每周（而不是大爆炸）都要測試他的代碼。 我們也以一次遷移 1 個客戶并僅為該客戶打開功能的方式處理大型遷移，我們的一些大型遷移已運行 3-4 個月。 ### 您有什么可以做的不同還是感到驚訝？ 許多工程師在家工作，令人驚訝的是，有了自主權，許多遠程員工像總部員工一樣富有生產力和積極性。 ## 您使用什么基礎架構？ ### 您使用哪種語言來開發系統？ 主要是 Java / Python，以及 Go / C 中的一些小服務 ### 您有多少臺服務器？ 我們有約 3000 多個由人偶管理的實例。 * 500+ Tomcat service instances * 500+ Storage nodes powered by Tomcat/Nginx * 100+ MySQL nodes * 100+ Elasticsearch nodes * 50+ Text extraction instances(autoscaled) * 100+ HAProxy instances * 和許多其他類型的服務 實例 ### 如何將功能分配給服務器？ 我們使用面向服務的體系結構，并根據服務類型分配服務器。 一些頂級服務是： * 元數據 * 儲存空間 * 對象服務 * Web UI * 索引 * 同步 * 搜索 * 審核 * 內容智能 * 實時事件傳遞 * 文本提取 * 集成 * 縮略圖生成 * 防病毒軟件 * 垃圾郵件 * 預覽/縮略圖 * Rsync * API 網關 * 結算 * FTP / SFTP * 等等。  ### 如何配置服務器？ 大多數服務都是偽造的，并且可以在 VM 上運行，我們僅針對 MySQL，Memcached 和存儲節點等少數設備運行物理服務。 我們使用第三方根據模板來配置服務器，并將其放置在數據中心中，以供使用。 但是我們已經開始將一切遷移到公共云的工作，因此最終，一切都將在 Kubernetes 中運行。 但是，挑戰在于如何在不停機的情況下如何在比賽中更換賽車發動機。 ### 您使用什么操作系統？ CentOS7 ### 您使用哪個 Web 服務器？ Nginx，HAproxy。 在一些舊的流程中使用了 Apache，但隨著時間的流逝，它將被棄用。 ### 您使用哪個數據庫？ MySQL 和 Redis。 過去我們曾使用過其他數據庫，例如 Berkeley DB，Lucene，Cassandra，但由于其對工程師/操作人員的熟悉程度和可擴展性，我們逐漸將所有數據庫遷移到 MySQL。 有關更多信息，請參見 Egnyte 的 [MySQL](https://www.egnyte.com/blog/2012/10/mysql-at-egnyte/) 。 對于某些流，我們還使用 OpenTSDB，BigTable，Elasticsearch。 ### 您是否使用反向代理？ 是 Nginx 和 HAProxy ### 您是否并置，使用網格服務，使用托管服務等？ 我們并置，我們還使用公共云。 ### 您的存儲策略是什么？ 我們首先創建自己的服務器，然后在機器中打包盡可能多的硬盤驅動器，我們過去將它們稱為 DRBD Filers。 我們這樣做是因為 AWS 成本過高。 我們已經評估了 [GlusterFS](https://www.gluster.org/) ，但當時它無法擴展以滿足我們的需求，因此我們構建了自己的。 加班 S3 變得便宜了，GCS / Azure 誕生了，我們將存儲層設計為可插入的，因此現在客戶可以決定要使用哪個存儲引擎（例如，Egnyte，S3，GCS，Azure 等）。 此時，我們在公共云中存儲了 1 個 DR 副本，并與我們一起存儲了 1 個副本，但是最終我們將使用我們的數據中心作為直通緩存，因為云中的計算便宜，但是帶寬昂貴。 ### 您如何增加產能？ 我們已基于 Newrelic，Grafana 和其他統計數據提供了半自動化的容量規劃工具，并根據觀察監控報告中的關鍵指標并預定一些額外的容量，進行了定期的容量規劃會議。 現在，某些服務已啟用云服務，我們只是根據隊列大小自動縮放它們。 ### 您是否使用存儲服務？ 是 Egnyte，S3，GCS，Azure， ### 您如何處理會話管理？ 我們多次重寫了體系結構，目前，有 99％的服務是無狀態的。 僅服務 Web UI 的服務使用會話，我們在 [memcached-session-manager](https://code.google.com/archive/p/memcached-session-manager/) 支持的 tomcat 中使用粘性會話，但最終，我的計劃是也 使用 JWT 或類似方法實現無狀態。 ### 您的數據庫是如何設計的？ 主從？ 碎片？ 其他？ 我們幾乎對所有具有自動故障轉移功能的數據庫都使用了 Master-Master 復制，但是在一些突變程度很大的數據庫上的切換是手動完成的，我們遇到了一些問題，其中由于復制滯后，自動切換會導致應用程序數據不一致，我們 需要重新架構一些核心文件系統邏輯來解決此問題，我們最終將完成此工作。 下面是有關處理數據庫升級的問題，詳細回答了有關數據庫體系結構的更多詳細信息。 ### 您如何處理負載平衡？ 我們根據客戶使用 DNS 訪問系統的 IP 進行地理平衡，并在數據中心內使用 HAProxy 將其路由到相應的 POD，并在內部 POD 中再次使用 HAProxy 路由 ### 您使用哪個 Web 框架/ AJAX 庫？ 我們已經多次更改了 UI，這是一直在變化的一件事。 過去，我們不得不使用 ExtJS，YUI，JQuery，而不能使用其他東西。 最新的迭代基于 ReactJS / Redux 以及 Backbone / Marionette 上的一些舊代碼。 ### 您使用哪些實時消息傳遞框架？ 我們使用 [大氣](https://github.com/Atmosphere/atmosphere) ，但最終，我們將其替換為 NodeJS ### 您使用哪個分布式作業管理系統？ 為此，我們使用 Google Pubsub，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 /本地文件系統的緩存文件管理器節點，它以 LRU 方式運行。 我們可以彈性地增加減少緩存文件服務器的數量。 我們最大的問題之一是上傳速度，如何從世界任何地方盡可能快地將數據上傳到 Egnyte，為此，我們構建了特殊的 Network pops，如果您好奇的話可以在閱讀更多內容 [為 Egnyte 客戶加速數據訪問](https://www.egnyte.com/blog/2014/03/speeding-up-data-access-for-our-customers/) Memcached / Redis 用于緩存元數據，我們使用單獨的 Memcached 池來緩存長期存在的靜態數據和文件系統元數據。 核心文件系統元數據非常龐大，不適合當前的 Memcached 節點，并且會逐出最近使用的其他類型的數據。 為了防止這種情況，我們使用 3 種類型的池，應用程序代碼決定在哪里查找哪種數據。 我們允許在文件系統 Memcached 緩存中逐出，并在其他種類的 Memcached 池中爭取零逐出。 對于不同種類的數據，我們也使用不同的對象到期時間。 對于我們一些頻繁使用的數據（例如客戶信息或分片映射），即使每個請求都轉到 Memcache，也會因某些請求（例如文件夾列表）而減慢速度，因此我們在每個 JVM 上對該數據進行內存內緩存，并刷新數據 基于自定義 TTL 或我們使用某種 pub-sub 機制刷新它。 緩存中的兩個最大難題是權限和事件。 對于權限數據，我們已經多次重選了該層，最近我們編寫了一個 TRIE 來有效地緩存該層。 對于事件，我們將其緩存在 Memcache 中，但是有可能在夜間為客戶發布了約 10 萬個事件，而在早上 9:00 AM 突然有 3 萬個人打開了筆記本電腦，現在每個人都希望這些 10 萬個事件可以 使他們的系統一致。 這是一個有趣的規模問題，因為這將需要您在短時間內（例如 15 分鐘）處理 30B 事件，并且僅發送用戶有權訪問的事件。 由于事件是不可變的，我們將它們在 Memcache 中緩存了 12 個小時，但是即使它們從 Memcache 下載相同的事件那么多次也會導致網絡問題。 最終，我們在短時間內將事件緩存在內存中，并且隨著我們進行許多年輕一代的收集工作，還調整了這些節點上的 GC 設置。 與其他節點相比，我們還將這些節點放置在速度更快的網絡上，但仍然沒有解決這個問題:)。 ### 您的客戶端緩存策略是什么？ 對于我們的 Web UI，我們使用 requireJS 和其他各種方式來僅下載所需的模塊。 我們的 Mobile 和 Desktop 客戶端豐富使用本地文件系統作為緩存。 ### 您使用哪些第三方服務來幫助您構建系統？ 我們使用了一些 Google 服務，Azure，New Relic，Authy，MixPanel，Flurry，Tableau，但大多數核心組件都是由我們構建的。 ## 您如何管理系統？ ### 您如何檢查全局可用性并模擬最終用戶性能？ 我們使用不同 AWS 區域中的節點來一致地測試帶寬性能。 我們還使用內部 haproxy 報告來繪制客戶觀察到的上載/下載速度，并主動尋找它們，并使用網絡彈出消息和其他策略來加速數據包。  ### 您如何健康檢查服務器和網絡？ Nagios，Grafana 和 New Relic 以及一些內部主動異常分析被使用。 有關更多詳細信息，請參見此 [博客文章](https://www.egnyte.com/blog/2013/06/improving-service-reliability/) ### 如何繪制網絡和服務器統計數據以及趨勢圖？ 我們使用 Grafana，Kibana，Nagios 和 New Relic。   ### 您如何測試系統？ 硒，Junit，鼻子，Nightwatch 和手動測試。 單元，功能，集成和性能測試的組合。 ### 您如何分析效果？ New Relic 用于監視應用程序性能。 我們還使用本地框架生成了大量內部應用程序指標。 我們使用 Grafana / Nagios / Kibana，內部工具和其他工具來監視系統其他部分的性能。 有關更多詳細信息，請參見此博客文章 [分布式系統中的調試性能問題](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 / Ansible 用于部署大多數新代碼。 ### 您使用哪種防火墻產品？ 帕洛阿爾托網絡 ### 您使用哪個 DNS 服務？ NS1 ### 您使用哪些路由器？ 思科 ### 您使用哪些開關？ Arista ### 您使用哪個電子郵件系統？ 我們結合使用 SendGrid 和我們自己的 SMTP 服務器。 ### 如何備份和還原系統？ 對于 MySQL，我們使用 [Percona XTraBackup](https://www.percona.com/doc/percona-xtrabackup/2.3/index.html) ，對于 Elasticsearch，該數據被復制 3 次。 對于客戶文件，我們將其復制 3 次，并將 1 個副本存儲在 DR 公共云中。 如果存儲 Filer 無法恢復，我們將丟棄它，添加一個新 Filer 并再次復制副本。 對于某些客戶，我們還會將其數據復制到他們選擇的提供商。 對于使用 S3，Azure 或 GCS 作為可插拔存儲層的客戶，它將確保復制以防止數據丟失。 ### 如何進行軟件和硬件升級？ 大多數節點是無狀態的，并且有狀態組件具有主動-主動故障轉移。 通過將節點從池中取出并進行升級并將其放回池中來處理升級。 我們使用 jenkins + Ansible + puppet 和自定義自動化。 ### 您如何處理升級時數據庫架構的重大更改？ 不同的服務使用不同類型的數據庫，并且它們以不同的方式升級。 在 10000 英尺處，它們如下圖所示：  1. EOS DB 存儲對象元數據并且增長非常快，它經過分片，并且我們將繼續添加更多此類數據。 2. MDB 的增長速度更快，經過了分片，并且我們會繼續增加更多。 3. DC_central 是一個 DNS 數據庫，并且保持相當靜態。 我們運行了許多此副本以實現可伸縮性。 4. Pod_central 具有快速變異的數據，但每個表的增長量不超過 2000 萬行。 我們運行了許多此副本以實現可伸縮性。 * 每個數據庫模式始終是向前和向后兼容的，即我們絕不會在同一發行版中刪除列和代碼，我們首先在停止使用該列的發行版 1 中部署代碼，而在發行版 2 中我們刪除該列。 * 非分片數據庫每周更新一次。 它們是存儲各種功能驅動表的表。 我們目前在生產環境中使用腳本對其進行升級，但是我們在質量檢查中使用 Liquibase，并且正在逐步將其應用于生產環境 * 使用自動腳本進行分片的數據庫新列更改 * 分片數據庫遷移是一件痛苦的事情，因為我們有 12000 多個分片并且還在不斷增長，您無法在 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/) ， -4 個月完成。 * 模式一致性檢查器報告可確保升級后所有數據中心中的所有模式均相同。 ### 您是否有單獨的運營團隊來管理您的網站？ 是的，我們有一個專門的生產工程師，SRE 和一個 IT / Ops 團隊，負責監視和管理生產。 但是正如我之前所說，構建此功能的工程師負責制定決策，因此他們將深入參與監視指標并解決生產問題。 ## 其他 ### 您欣賞誰？ AWS ：他們的創新步伐令人贊嘆。 Google ：它們的工具如 BigQuery，Kubernetes 很棒。 Elasticsearch： 其余的 API 簡單性和架構很棒。 我們用一個 TB 的數據和一個工程師來管理一個 100 多個節點的集群。 MySQL / Memcache： 它們簡單，快速且很棒。 Eclipse / Jenkins ：插件架構很好。 ### 您是否模仿了其他人的公司/方法？ 我們是 [http://highscalability.com/](http://highscalability.com/) 的常規讀者，許多設計都受到它的啟發。 * POD 架構的靈感來自 Tumblr 的 Cell 架構。 這不是精確匹配，但是隔離故障的概念是相同的。 * 受 Facebook 啟發的架構在 12 個小時后會在 Memcached 和刷新鍵中產生抖動。 * 受 [http://highscalability.com/上一些文章的啟發，將](http://highscalability.com/) [指紋添加到每個數據庫查詢](https://www.egnyte.com/blog/2014/10/debugging-performance-issues-in-distributed-systems/) 我們正在招聘，請在 [職位頁面](https://www.egnyte.com/jobs/) 中查看我們，并在 [與我們聯系 [受電子郵件保護]](/cdn-cgi/l/email-protection) 。如果您有興趣成為 [Egnyte](https://www.egnyte.com) 令人驚嘆的團隊的一員。