# Vinted 體系結構：每天部署數百次，以保持繁忙的門戶穩定 > 原文： [http://highscalability.com/blog/2015/2/9/vinted-architecture-keeping-a-busy-portal-stable-by-deployin.html](http://highscalability.com/blog/2015/2/9/vinted-architecture-keeping-a-busy-portal-stable-by-deployin.html)  *這是 [Vinted](https://www.vinted.com/) 的 [NerijusBend?iūnas](https://www.linkedin.com/profile/view?id=48589106)和 [Tomas Varaneckas](https://twitter.com/spajus) 的來賓帖子。* [Vinted](https://www.vinted.com/) 是一個對等市場，用于出售，購買和交換衣服。 它允許成員直接通信，并具有社交網絡服務的功能。 它始于 2008 年，最初是一個立陶宛女孩的小社區，后來發展成為一個全球性項目，為 8 個不同國家/地區的 700 萬用戶提供服務，并且這一需求正在不斷增長，每天處理超過 2 億個請求。 ## 統計資料 * 700 萬用戶，并且還在不斷增長 * 每月 250 萬活躍用戶 * 每天 2 億個請求（瀏覽量+ API 調用） * 9.3 億張照片 * 80 TB 原始空間用于圖像存儲 * 60 TB HDFS 原始空間用于分析數據 * 70％的流量來自移動應用（API 請求） * 每位成員每周花費 3 個小時以上的時間 * 2500 萬個上市項目 * 超過 220 臺服務器： * 47 用于內部工具（vpn，廚師，監視，開發，制圖，構建，備份等） * Hadoop 生態系統 38 * 34 用于圖像處理和存儲 * 獨角獸和微服務 30 * 28 個用于 MySQL 數據庫，包括副本 * 19 用于獅身人面像搜索 * 10 個用于背景工作 * 10 用于使用 Nginx 進行負載平衡 * 卡夫卡 6 * Redis 4 * 4 用于電子郵件傳遞 ## 技術棧 ### 第三方服務 * [GitHub](https://github.com/) ，用于代碼，問題和討論 * [NewRelic](http://newrelic.com/) 用于監視應用程序響應時間 * [CloudFlare](https://www.cloudflare.com/) 用于 DDoS 保護和 DNS * [Amazon Web Services](http://aws.amazon.com/) （SES，Glacier），用于通知和長期備份 * [閑暇](https://slack.com/)用于工作對話和“聊天操作” * [Trello](https://trello.com/) 完成任務 * [Pingdom](http://pingdom.com/) 用于正常運行時間監控 ### 核心應用和服務 * [Ruby](https://www.ruby-lang.org/) 用于服務，腳本和主應用 * [主應用程序和內部應用程序的 Rails](http://rubyonrails.org/) * [獨角獸](http://unicorn.bogomips.org/)服務于主應用 * [Percona MySQL 服務器](http://www.percona.com/software/percona-server/ps-5.6)作為主數據庫 * [Sphinx 搜索](http://sphinxsearch.com/)用于全文搜索并減少 MySQL 的負載（測試 [ElasticSearch](http://www.elasticsearch.org/) ） * [Capistrano](http://capistranorb.com/) 用于部署 * [Jenkins](http://jenkins-ci.org/) 用于運行測試，部署和其他各種任務 * [Memcached](http://memcached.org/) 用于緩存 * [請求](http://resquework.org/)進行后臺作業 * [Redis](http://redis.io/) 用于 Resque 和 Feed * [RabbitMQ](http://www.rabbitmq.com/) 用于將消息傳遞到服務 * [HAproxy](http://www.haproxy.org/) 提供高可用性和負載平衡 * [GlusterFS](http://www.gluster.org/) 用于分布式存儲 * [Nginx](http://nginx.org/) 投放 Web 請求 * [Apache Zookeeper](http://zookeeper.apache.org/) 用于分布式鎖定 * [Flashcache](https://github.com/facebook/flashcache/) 可提高 I / O 吞吐量 ### 數據倉庫堆棧 * [Clojure](http://clojure.org/) 用于數據提取服務 * [Apache Kafka](http://kafka.apache.org/) ，用于存儲飛行中的數據 * [Camus](https://github.com/linkedin/camus) 用于將數據從 Kafka 卸載到 HDFS * [Apache Hive](https://hive.apache.org/) 作為 SQL-on-Hadoop 解決方案 * [Cloudera CDH](http://www.cloudera.com/content/cloudera/en/products-and-services/cdh.html) Hadoop 發行版 * [Cloudera Impala](http://www.cloudera.com/content/cloudera/en/products-and-services/cdh/impala.html) 作為低延遲 SQL-on-Hadoop 解決方案 * [Apache Spark](https://spark.apache.org/) 處于實驗階段 * [Apache Oozie](http://oozie.apache.org/) 作為工作流調度程序（研究替代方案） * [擴展](https://github.com/twitter/scalding)用于數據轉換 * [Avro](http://avro.apache.org/) 用于數據序列化 * [Apache Parquet](http://parquet.incubator.apache.org/) 用于數據序列化 ### 服務器和資源調配 * 多為裸金屬 * 多個數據中心 * [CentOS](http://www.centos.org/) * [廚師](https://www.chef.io/)用于配置幾乎所有內容 * [Berkshelf](http://berkshelf.com/) ，用于管理 Chef 依賴項 * [測試廚房](http://kitchen.ci/)，用于在 VM 上運行基礎結構測試 * [Ansible](http://www.ansible.com/) 用于滾動升級 ### 監控方式 * [Nagios](http://www.nagios.org/) 用于常規操作監控 * [仙人掌](http://www.cacti.net/)用于圖形和容量規劃 * [Graylog2](https://www.graylog2.org/) 適用于應用程序日志 * 用于服務器日志的 [Logstash](http://logstash.net/) * [Kibana](http://www.elasticsearch.org/overview/kibana/) 用于查詢 logstash * [統計信息](https://github.com/etsy/statsd)，用于從應用程序收集實時指標 * [石墨](http://graphite.wikidot.com/)，用于存儲應用程序中的實時指標 * [Grafana](http://grafana.org/) 用于創建帶有應用指標的精美儀表板 * [集線器](https://hubot.github.com/)用于基于聊天的監視 ## 架構概述 * 裸機服務器被用作云提供商的更便宜，更強大的替代產品。 * 在歐洲和美國的 3 個不同數據中心托管服務器。 * Nginx 前端將 HTTP 請求路由到獨角獸工作者并執行 SSL 終止。 * [Pacemaker](http://clusterlabs.org/) 用于確保 Nginx 服務器的高可用性。 * 在不同的國家/地區，每個 Vinted 門戶網站都有自己單獨的部署和資源集。 * 為了提高機器利用率，屬于多個門戶的大多數服務可以在單個裸機服務器上彼此并行運行。 主廚配方負責唯一的端口分配和其他分離問題。 * 通過為每個門戶網站使用單獨的數據庫來避免 MySQL 分片。 * 在我們最大的門戶中，功能性分片已經在發生，距離單個最大表無法容納在服務器中的點還差幾個月。 * Rails 應用程序中的緩存使用帶有 L2 緩存的自定義機制，可以防止主緩存過期時出現峰值。 使用了幾種緩存策略： * 遠程（在 memcached 中） * 本地（在獨角獸工作者的記憶中） * 半本地（在獨角獸工作器內存中，當本地緩存到期時回退到 memcached）。 * 圍繞核心 Rails 應用程序構建了幾個微服務，它們都有明確的用途，例如發送 iOS 推送通知，存儲和提供品牌名稱，存儲和提供標簽。 * 微服務可以是按端口，按數據中心或全局的。 * 每個微服務的多個實例正在運行以實現高可用性。 * Nginx 平衡了基于 HTTP 的微服務。 * 使用 Redis 實現每個成員的自定義 feed。 * 使用過濾器（自定義大小，顏色等）時，從 Sphinx 索引而不是 MySQL 加載目錄頁面。 * 圖像由單獨的 Rails 應用處理。 * 處理后的圖像存儲在 GlusterFS 中。 * 第 3 次匹配后會緩存圖片，因為前幾次匹配通常來自上傳者，并且圖片可能會旋轉。 * 使用 [twemproxy](https://github.com/twitter/twemproxy) 分割 Memcached 實例。 ## 球隊 * 超過 150 名全職員工 * 30 位開發人員（后端，前端，移動） * 5 名現場可靠性工程師 * 立陶宛維爾紐斯的總部 * 在美國，德國，法國，捷克共和國和波蘭設有辦事處 ## 公司的運作方式 * 幾乎所有信息對所有員工開放 * 使用 GitHub 進行幾乎所有操作（包括討論公司問題） * Slack 中的實時討論 * 每個人都可以自由參加他們感興趣的事情 * 自治隊 * 沒有資歷等級 * 跨職能開發團隊 * 沒有強制執行的流程，團隊可以決定如何管理自己 * 團隊致力于解決高層問題，并決定如何解決它們 * 每個團隊都決定如何，何時何地工作 * 團隊在需要時自行雇用 ## 開發周期 * 開發人員從主人處分支。 * 更改成為 GitHub 中的請求請求。 * Jenkins 運行 [Pronto](https://github.com/mmozuras/pronto) 進行靜態代碼和樣式檢查，在 pull request 分支上運行所有測試，并使用狀態更新 GitHub pull request。 * 其他開發人員查看更改，添加評論。 * 拉取請求可能會使用各種修復程序多次更新。 * 每次更新后，Jenkins 都會運行所有測試。 * 在與 master 合并之前清理 Git 歷史，以保持 master 歷史的簡潔性。 * 接受的請求請求將合并到主服務器中。 * Jenkins 使用所有測試運行主版本，并觸發部署作業以推出新版本。 * 幾分鐘后，代碼到達 master 分支后，將其應用于生產中。 * 拉取請求通常很小。 * 每天部署約 300 次。 ## 避免失敗 每天部署數百次并不意味著總是必須破壞所有東西，但是保持站點穩定需要一定的紀律。 * 如果測試失敗，則不會進行部署。 沒有方法可以覆蓋它，母版必須為綠色才能進行部署。 * 每天晚上和周末自動部署鎖定。 * 任何人都可以通過 Slack 聊天手動鎖定部署。 * 部署鎖定后，可以從 Slack 聊天中手動“強制”部署。 * 在審查代碼時，團隊非常挑剔。 質量標準設置得很高。 測試是強制性的。 * 在 Unicorn 重新加載代碼之前，將在生產中進行預熱。 它包括對門戶網站各個關鍵部分的若干請求。 * 在預熱期間，如果任何一個請求均未返回 200 OK，則舊代碼將保留，并且部署將失敗。 * 有時，測試/預熱未發現問題，并且已損壞的代碼發布到了生產環境中。 * 錯誤將流式傳輸到 Graylog 服務器。 * 如果錯誤率超過閾值，則會觸發警報。 * 錯誤率警報和失敗的構建通知會立即報告給 Slack 聊天。 * 所有錯誤都包含額外的元數據：Unicorn worker 主機和 pid，HTTP 請求詳細信息，導致問題的代碼的 git 修訂版，錯誤回溯。 * 某些類型的“致命”錯誤也直接報告給 Slack 聊天。 * 每個部署日志都包含帶有所有更改的 GitHub 差異 URL。 * 如果生產中出現問題，由于變更集和即時錯誤反饋的原因，很容易快速查明問題。 * 部署詳細信息會報告給 NewRelic，從而可以輕松解決性能瓶頸的引入。 ## 減少生產時間 快速發布和穩定發布都非常受關注，團隊一直在努力使構建和部署時間盡可能短。 * 完整的測試套件包含> 7000 個測試，運行時間約為 3 分鐘。 * 不斷添加新的測試。 * Jenkins 在具有 32 個 CPU，128G RAM 和 SSD 驅動器的裸機上運行。 * Jenkins 將所有測試分成多個塊，并并行運行它們，以匯總最終結果。 * 在沒有并行化的情況下，測試將在一臺普通計算機上運行 1 個小時以上。 * 在 Jenkins 中，對于 master 分支中的每次提交，Rails 資產都是預先構建的。 * 在部署期間，從 jenkins 下載預建資產，并將其上載到所有目標服務器。 * 將版本上載到目標服務器時使用 BitTorrent。 ## 運行實時數據庫遷移 在大多數情況下，即使在高峰時間，我們也可以在不停機的情況下更改生產 MySQL 數據庫的結構。 * 在任何部署期間都可能發生數據庫遷移 * Percona 工具箱的 pt-online-schema-change 用于在表的副本上運行更改，同時使其與原始副本保持同步，并在更改完成后將副本與原始副本切換 # 運作方式 ## 服務器配置 * Chef 用于提供我們基礎架構的幾乎所有方面。 * SRE 團隊確實會提出對基礎結構更改的請求，就像開發團隊對代碼更改所做的一樣。 * 詹金斯（Jenkins）正在驗證所有 Chef 拉取請求，運行交叉依賴關系檢查，食品評論等。 * 團隊在 GitHub 上審查了廚師代碼的更改。 * 開發人員可以向 Chef 存儲庫發出基礎結構更改請求請求。 * 合并拉取請求時，Jenkins 上載更改后的 Chef 食譜并將其應用于生產中。 * 計劃產生 DigitalOcean 小滴以與 Jenkins 一起進行 Chef 廚房測試。 * Jenkins 本身是使用 Chef 配置的，而不是使用 Web UI。 ## 監控方式 * 仙人掌圖服務器端指標 * Nagios 檢查可能出現的所有故障 * Nagios 健康檢查，用于我們的某些應用程序和服務 * Statsd / Graphite，用于跟蹤應用程序指標，例如成員登錄，注冊，數據庫對象創建 * Grafana 用于漂亮的儀表板 * 可以使用 Chef 動態描述和創建 Grafana 儀表板 ## 聊天操作 * Hubot 坐在 Slack 中。 * 松弛房間通過 [hubot-pubsub](https://github.com/spajus/hubot-pubsub) 訂閱了各種事件通知。 * #deploy 會議室顯示有關部署的信息，并提供指向 GitHub diff，Jenkins 控制臺輸出等的鏈接。在這里，可以使用簡單的聊天命令來觸發，鎖定和解鎖部署。 * ＃deploy-fail 會議室僅顯示部署失敗。 * #failboat 會議室顯示有關錯誤率和生產中個別錯誤的公告。 * 有多個＃failboat- *房間，其中提供有關 cron 故障，卡住的 resque 作業，nagios 警告，newrelic 警報的信息。 * 每天兩次將 Graylog 錯誤與 GitHub 進行處理和交叉檢查，生成報告并將其提交給開發團隊。 * 如果有人在 GitHub 上提到您，Hubot 會在 Slack 上的私人消息中為您提供該問題的鏈接。 * 在 GitHub 中創建問題或請求請求時，提到的團隊會在其適當的 Slack 會議室中收到 ping 命令。 * 可以通過 Hubot 在 Slack 聊天中查詢并顯示石墨圖。 * 您可以向 Hubo??t 詢問有關基礎設施的問題，即有關部署特定服務的機器的問題。 Hubot 查詢 Chef 服務器以獲取數據。 * 開發人員將 Hubot 通知用于我們應用中發生的某些事件。 例如，向客戶支持聊天室自動通知可能的欺詐案件。 * Hubot 與 Office [netatmo](https://www.netatmo.com/) 模塊集成在一起，可以告訴所有人什么是 CO2，噪聲，溫度和濕度水平。 # 數據倉庫堆棧 * 我們從兩個來源提取數據： * 網站事件跟蹤數據：印象數，點擊數等 * 數據庫（MySQL）更改。 * 大多數事件跟蹤數據都從 JavaScript / Android / iOS 前端應用程序發布到 HTTP 端點。 一些事件由我們的核心 Ruby on Rails 應用程序發布到本地 UDP 套接字。 我們選擇 UDP 以避免阻塞請求。 * 有一種服務可以監聽 UDP 套接字上的新事件，對它們進行緩沖，并定期在 Kafka 中發出原始事件的主題。 * 流處理服務使用原始事件主題，驗證事件，將它們編碼為 Avro 格式，然后發出特定于事件的主題。 * 我們將事件的 Avro 模式保存在單獨的集中式模式注冊表服務中。 * 無效事件被置于單獨的 Kafka 主題中，以進行可能的更正。 * 我們使用 LinkedIn 的 Camus 作業將事件從特定于事件的主題逐步轉移到 HDFS。 事件到 Hadoop 的時間通常最多為一個小時。 * 使用 Hive 和 Impala 進行臨時查詢和數據分析。 * 研究基于伸縮的數據處理解決方案。 * 報告使用我們內部開發的，用 Ruby 編寫的類似 OLAP 的報告系統運行。 # 得到教訓 ## 產品開發 * 投資代碼質量。 * 通過測試涵蓋所有內容。 * 發布小更改。 * 使用功能開關將未完成的功能部署到生產中。 * 開發某些東西時，不要保留長時間運行的代碼分支。 * 投資一個快速的發布周期。 * 首先構建移動產品。 * 設計 API 從一開始就很好，以后很難更改。 * 在 RabbitMQ 消息中包含發件人主機名和應用程序名稱可以節省生命。 * 不要猜測或做假設，請進行 [AB](https://github.com/vinted/ab) 測試并檢查數據。 * 如果您打算將 Redis 用于更大的事情，請從一開始就考慮分片。 * 如果您計劃使 Rails 保持最新狀態，則切勿使用叉狀和稍作修飾的紅寶石寶石。 * 通過社交網絡盡可能輕松地共享您的內容。 * 搜索引擎優化是一項全職工作。 ## 基礎設施和運營 * 經常部署以提高系統穩定性。 起初聽起來可能違反直覺。 * 自動化一切。 * 監視所有可能發生的故障。 * 網絡交換緩沖區很重要。 * 容量規劃很困難。 * 從一開始就考慮 HA。 * RabbitMQ 集群不值得付出努力。 * 測量并繪制所有圖形：HTTP 響應時間，Resque 隊列大小，模型持久率，Redis 響應時間。 您無法改善無法衡量的東西。 ## 數據倉庫堆棧 * Hadoop 生態系統中有許多工具。 很難選擇合適的。 * 如果您正在為 Hive 編寫用戶定義函數（UDF），那么該考慮使用非 SQL 解決方案進行數據轉換了。 * “ Hadoop 應用程序”概念含糊不清。 通常，我們需要手動將應用程序組件粘合在一起。 * 每個人都編寫自己的工作流管理器。 并且有充分的理由。 * 分布式系統監視非常困難。 異常檢測和作圖很有幫助。 * 核心 Hadoop 基礎架構（HDFS，YARN）堅如磐石，但較新的工具通常會有細微差別。 * 卡夫卡很棒。 這個網站是關于高可擴展性還是如何浪費服務器？ 您是否真的需要 220 臺服務器來服務?2300req / sec？ 他了解了其中一些服務器使用情況。 這是 Ruby on Rails，所以這就是原因。 您能否詳細說明“ RabbitMQ 集群不值得付出”？ 您在運行時遇到問題嗎？ @Peter-與其他高可用性站點一樣，它們可以使用少于十個服務器來為流量提供服務。 從文章看來-其余內容涉及（a）收集和分析數據； （b）監督和監督系統； （c）確保高可用性。 在三個區域中只有 10 臺邊緣（緩存/ nginx）服務器（由于 HA，30 臺獨角獸是自然擴展）。 鑒于流量不統一（因此 200M req / day 不能轉換為 2300 req / s），這似乎是適中的，因為在任何區域中，請求都只能由幾個端點服務器之一來處理。 再次-這就是您在 HA 設置中所期望的-2 個以上的服務器用于任何潛在的傳入（請求）請求。 我必須同意彼得的觀點。 在最近閱讀了此處的 Stack Exchange 文章之后，很難不認為此設置會浪費一些資源。 感謝分享。 您似乎正在使用大量的開源項目。 我對你的決定感到好奇。 團隊成員一開始是否已經熟悉大多數技術？ 如果沒有，那么在這么多方面加強工作是否有點勢不可擋？ 大家好， Vaidotas，這里的 Vinted 工程師之一。 想對服務器數量發表評論。 如果您查看詳細信息，將會看到很多服務器專用于分析數據收集。 而且我認為分析數據可能是單獨的主題。 如果您查看運行 Vinted 應用程序所需的服務器及其所有內容，則會看到以下內容： 34 個用于圖像處理和存儲（9.3 億張照片） 30 個用于 Unicorn 和微服務（每天 2 億個請求） 28 個用于 MySQL 數據庫，包括副本 19 個用于 Sphinx 搜索（2500 萬個列出的項 索引） 10，用于可處理的后臺作業 10，用于與 Nginx 進行負載平衡（充當代理和一些緩存，可能會更少，但在我們運營所在的不同國家/地區需要它們）。 Redis 4 因此，這就是 135 臺運行應用程序基礎結構的服務器。 現在請記住，所有內容都必須具有高可用性。 這意味著至少所有內容的 2 倍，即使您目前不需要/不使用它也是如此。 希望能解釋一下服務器數量。 另外，您的行動小組的規模如何，才能維持這種運營/基礎架構？ 僅列出了 SRE。5\. DevOps 工程師，系統管理員和/或 DBA 怎么樣？ 您的 Jenkins 并行化設置似乎很有趣。 你是如何做到的？ 也許不久之后還會有另一篇專門針對此的博客文章？ 喬恩，我們有 5 位站點可靠性工程師來維護所有基礎架構。 我們執行從服務器引導到數據庫管理的所有工作。 我們嚴重依賴自動化:) 我真正無法理解的是-每天 200 M 的請求如何轉換為實際的 Internet 流量？ StackExchange 的請求量為 1.5 億，在 Alexa 評分中排名第 53，vinted.com 在 38763 上排名較高，但 RPS 較高。 與 http://highscalability.com/blog/2014/11/10/nifty-architecture-tricks-from-wix-building-a-publishing-pla.html（wix）相同-他們要求 700M 請求/ 一天，但肯定無法將 Alexa 評級與 StackExchange 相比。 誰能澄清？ @tao，一開始只有一個開發人員（CEO，聯合創始人），而且技術堆棧要小得多。 您的問題的答案是否定的。 當項目開始發展時，出現了一些東西。 我們雇用了更多的開發人員，工程師等。我們選擇雇用最聰明的工程師。 之所以使用某些技術是因為他們具有經驗，而其他技術則是“試驗和錯誤”（尤其是大數據的東西）。 我們在解決問題的過程中一直在解決它們。 我們仍然有需要解決的問題。 這就是新技術出現的方式。 我相信，一年后，我們可以寫一篇關于我們如何做事的文章。 @lan：RabbitMQ 非常棒，我們正在使用它，但是在分析事件方面，我們遇到了一些限制，因此選擇 kafka 作為事件發射。 RabbitMQ 集群的東西很容易破解。 正如文檔所述-“ RabbitMQ 群集不能很好地容忍網絡分區”，這并不像我們希望的那樣罕見。 @Tim：我們使用 https://github.com/grosser/parallel_tests 的稍加修改版本 @安東：不確定“轉換”的含義，但我們為女孩提供了超過 10 Gigs 的流量。 在談論 Alexa 時，目前我們有 8 個不同的國家，例如，我們的一個國家（http://kleiderkreisel.de）的排名為 7,468，因此沒有一個匯總排名。 另一件事是，70％的流量來自移動應用程序，我不確定 Alexa 是否會對此進行計數。 希望大家，Vinted 回答了您所有的問題:)