# Salesforce Architecture-他們每天如何處理 13 億筆交易 > 原文： [http://highscalability.com/blog/2013/9/23/salesforce-architecture-how-they-handle-13-billion-transacti.html](http://highscalability.com/blog/2013/9/23/salesforce-architecture-how-they-handle-13-billion-transacti.html)  *這是由 [salesforce.com](http://www.linkedin.com/profile/view?id=3158913) 的首席站點可靠性工程師 [Claude Johnson](http://www.linkedin.com/profile/view?id=3158913) 撰寫的來賓帖子。* 以下是 salesforce.com 的核心平臺和應用程序的體系結構概述。 其他材料（例如，Heroku 的 Dyno 架構）或其他產品的子系統（例如，work.com 和 do.com）不在本材料中，盡管 database.com 不在其中。 想法是與技術社區分享有關 salesforce.com 如何執行工作的一些見解。 任何錯誤或遺漏是我的。 這絕不是全面的，但是如果有興趣，作者將很樂意解決 salesforce.com 運作的其他領域。 Salesforce.com 希望與以前未與之互動的技術社區更加開放。 這是關于“如何打開和服”的開始。 自 1999 年以來，salesforce.com 一直專注于構建通過 Internet 交付的業務技術，以取代傳統的企業軟件。 我們的客戶通過按月訂閱付費，以通過網絡瀏覽器隨時隨地訪問我們的服務。 我們希望這種對 salesforce.com 核心體系結構的探索將是對該社區做出的許多貢獻的第一步。 ## 定義 讓我們從一些基本的 salesforce.com 術語開始： * **實例**-共享和非共享的完整的系統，網絡和存儲基礎結構集，可為部分客戶提供 salesforce.com 服務。 例如，na14.salesforce.com 是一個實例。 * **Superpod** -一組系統，網絡和存儲基礎結構，包括出站代理服務器，負載平衡器，郵件服務器，SAN 結構和支持多個實例的其他基礎結構。 Superpods 在數據中心內提供服務隔離，因此共享或復雜組件的問題不會影響該數據中心中的每個實例。 * **機構**（又稱組織）-Salesforce 應用程序的單個客戶。 從 www.salesforce.com 或 developer.force.com 開始的每次試用都會產生一個新的組織。 組織是高度可定制的，并且可以具有不同的安全設置，記錄可見性和共享設置，UI 外觀，工作流，觸發器，自定義對象，標準 salesforce.com CRM 對象上的自定義字段，甚至是自定義 REST API。 組織可以支持從一百萬到數百萬個許可的個人用戶帳戶，門戶網站用戶帳戶和 Force.com 網站用戶帳戶。 * **沙箱**-salesforce.com 服務的一個實例，該實例托管用于客戶應用程序開發目的的生產組織的完整副本。 使用我們平臺的客戶可以擁有完整的應用程序開發生命周期。 這些是供客戶在將更改部署到其生產組織中之前對其應用程序進行用戶驗收測試的測試環境。 ## 統計信息（截至 2013 年 8 月） * 17 個北美實例，4 個 EMEA 實例和 2 個 APAC 實例 * 20 個沙箱實例 * 1,300,000,000 筆以上的每日交易 * 高峰時每秒 24,000 個數據庫事務（相當于其他站點上的頁面瀏覽） * 15,000 多個硬件系統 * > 22 PB 的原始 SAN 存儲容量 * > 5K SAN 端口 ## 使用的軟件技術 * 用于開發和初級生產系統的 Linux * 帶 ZFS 的 Solaris 10 * 碼頭 * 索爾 * 記憶快取 * Apache QPID * 質量體系 * 剃刀木偶 * Perl，Python * 納吉奧斯 * Perforce，Git，Subversion ## 硬件/軟件架構 ### 登錄到 salesforce.com 服務 我們維護一個服務器池來處理所有實例的登錄流量。 來自許多（但不是全部）實例的少數服務器接受登錄請求，并將會話重定向到用戶的家庭實例。 當您通過 login.salesforce.com 登錄時，會發生這種情況。 客戶流量始于我們的外部 DNS。 查找成功返回實例的 IP 地址后，標準 Internet 路由會將其定向到適當的數據中心。 一旦流量進入該數據中心中的網絡，它將被定向到該 IP 所在的負載平衡器對。 我們所有面向 Internet 的 IP 都是在一對主用/備用負載均衡器上配置的 VIP。 ### 在實例內部 負載平衡器將流量定向到給定實例的應用程序層。 在這一層，我們既提供標準網頁流量，也提供我們的 API 流量。 API 流量占我們應用程序層總體服務的流量的 60％以上。 根據客戶請求的需求，它將被定向到用于各種類型的后端處理的其他服務器層。 ### 核心應用 核心應用程序層包含十到 40 個應用程序服務器，具體取決于實例。 每個服務器運行一個配置有多達 14 GiB 堆的 Hotspot JVM，具體取決于服務器硬件配置。 批處理服務器負責在數據庫層上運行計劃的自動化過程。 例如，每周導出過程，該過程用于以單一存檔文件格式導出客戶數據作為備份形式。 Salesforce.com 提供許多服務，包括基本和高級內容管理。 我們有一個內容搜索服務器和一個內容批處理服務器，用于管理內容應用程序層上的異步過程。 內容批處理服務器計劃內容類型的處理，包括諸如某些文件類型的渲染預覽和文件類型轉換之類的功能。 ### 數據庫 主要數據流發生在核心應用服務器層和數據庫層之間。 從軟件的角度來看，所有內容都通過數據庫，因此數據庫性能至關重要。 每個主要實例（例如 NA，AP 或 EU 實例）都使用 8 節點集群數據庫層。 客戶沙箱（例如 CS 實例）具有 4 節點集群數據庫層。 由于 salesforce.com 是一個非常受數據庫驅動的系統，因此減少數據庫負載至關重要。 為了減少數據庫層的負載，我們開發了 ACS-API Cursor Server。 這是對兩個問題的解決方案，使我們能夠顯著提高核心數據庫性能。 首先，我們曾經將游標存儲在數據庫中，但是刪除操作會影響性能。 其次，在使用數據庫表保存游標之后，DDL 開銷變成了負面影響。 因此誕生了 ACS。 ACS 是在一對服務器上運行的游標緩存，提供了一種從數據庫層卸載游標處理的方法。 ### 搜索 我們的搜索層運行在商用 Linux 主機上，每臺主機上都配備了 640 GiB PCI-E 閃存驅動器，該驅動器充當搜索請求的緩存層。 這些主機通過 NFS 文件系統從共享的 SAN 陣列中獲取數據。 搜索索引存儲在閃存驅動器上，以提高搜索吞吐量的性能。 搜索索引當前在轉換服務器上進行，轉換服務器通過光纖通道 SAN 從存儲陣列安裝 LUN。 這些 LUN 組成一個 QFS 文件系統，該文件系統允許單寫程序但多讀程序訪問。 像大多數其他關鍵系統一樣，我們以主動/被動方式運行它們，而被動節點則執行一些低優先級的搜索索引工作。 然后將其結果發送給活動伙伴以寫入 QFS 文件系統。 當這些相同的 LUN 從一組在 SPARC 上運行 Solaris 10 的四個 NFS 服務器以只讀方式裝入時，就會發生轉換。 然后，這些通過 SAN 安裝的文件系統通過 NFS 共享到先前描述的搜索層。 ### Fileforce 我們維護一層提供對象存儲的服務器，其概念與亞馬遜的 S3 或 OpenStacks 的 Swift 項目相似。 Fileforce 這個系統是內部開發的，目的是減少數據庫層的負載。 在引入 Fileforce 之前，所有二進制大對象（BLOB）都直接存儲在數據庫中。 Fileforce 聯機后，所有大于 32 KiB 的 BLOB 都已遷移到其中。 小于 32 KiB 的 BLOB 繼續存在于數據庫中。 Fileforce 中的所有 BLOB 在數據庫中都有一個引用，因此為了從備份中還原 Fileforce 數據，我們必須基于來自同一還原點的數據庫備份來啟動數據庫實例。 Fileforce 包括捆綁程序功能，旨在減少 Fileforce 服務器上的磁盤查找負載。 如果數據庫中存儲了 100 個以上小于 32 KB 的對象，則將在應用服務器上運行一個進程，以將這些對象捆綁到一個文件中。 對捆綁文件的引用與捆綁中的查找偏移量一起保留在數據庫中。 這類似于 Facebook 的 Haystack 圖像存儲系統，但內置于對象存儲系統中。 ### 支持 每個實例包含其他各種支持角色的服務器，例如調試應用程序服務器和應用程序層中的“ Hammer 測試”應用程序服務器，監視每個實例運行狀況的中心服務器以及監視運行 Nagios 的服務器。 實例本身之外還包含支持服務器，例如存儲管理，數據庫管理，日志聚合，生產訪問身份驗證和其他功能。 ## 未來發展方向 在數據庫層，我們正在仔細檢查數據存儲系統的幾種選項。 我們還在評估更高速度，更低延遲的互連，例如與現有數據庫解決方案的集群互連的 Infiniband。 將來，我們希望使搜索主機能夠進行所有讀寫操作。 我們正在為搜索索引推出 Apache Solr。 Solr 在我們現有的搜索主機上本地運行。 SAN，NFS 服務器和基于 SPARC 的索引器主機將全部消失，這將大大降低整個搜索層的復雜性。 我們的應用程序容器以前是 Resin，但在過去的一年中，我們一直在遷移到 Jetty。 我們還在對應用層硬件進行硬件更新，這將使 RAM 大小增加 30％-266％，并將 Sandy Bridge 處理器引入我們的堆棧。 我希望對 salesforce.com 技術架構和堆棧的概述能使您有趣且有益。 如果您對其他訪客帖子感興趣，請深入評論我們廣泛的技術基礎架構的其他部分。 謝謝閱讀！ ## 相關文章 * [Force.com 多租戶架構的內部設計](http://www.infoq.com/presentations/SalesForce-Multi-Tenant-Architecture-Craig-Weissman) * [Salesforce.com 架構](http://www.scribd.com/doc/145879736/Salesforce-com-Architecture) * [單元架構](http://highscalability.com/blog/2012/5/9/cell-architectures.html) 克勞德 感謝您抽出寶貴時間發布此信息。 我想對您如何使用 Solaris 和 ZFS 的更多信息非常感興趣。 另外，如果必須全部這樣做，是否會再次使用 QFS？ 謝謝！ 你們正在使用什么數據庫？ 此外，您提到了 Resin 和 Jetty，但在語言列表中沒有提及 Java。 如果使用 Java，則正在使用 Java EE 的哪些部分？ 他們沒有提到它，但我可以想象它是神諭！ @MiddleAgedGeek 他們使用 Oracle 或曾經使用 Oracle：http://www.dbms2.com/2012/06/26/is-salesforce-com-going-to-stick-with-oracle/ ?？ 每秒有 24,000 個數據庫事務（24k TPS）由多少臺數據庫機處理？ 還是每個數據庫服務器處理多少 TPS？ 另外，我們是否在這里談論純 OLTP，OLAP 和混合液？ 韋斯 FIleforce 在 Solaris 10 上運行，并且 Fileforce 數據存儲在從鏡像 VDEV 創建的 ZFS 池中。 （鏡像 VDEV 的數量取決于服務器的型號。） 我開始之前就選擇了 QFS。 由于 salesforce.com 是 Sun 商店，并且搜索索引是在具有 SAN 存儲的 SPARC 服務器上運行的，因此 QFS 是操作人員輕松實現高吞吐量，可靠的搜索索引文件系統的方式。 NFS 將其安裝到搜索層的唯一原因是字節順序問題。 如前所述，我們正在轉向一種更易于推理，故障排除和支持的體系結構。 MiddleAgedGeek 和 ymo， 請參閱 http://www.salesforce.com/company/news-press/press-releases/2013/06/130625.jsp，但我們確實使用 Oracle 數據庫。 我們確實將其他數據存儲用于不同的應用程序，但是上述核心數據庫是 Oracle。 至于 Java，我們將 Jetty 用作容器，但是我們并未使用大多數核心 Java EE 功能。 Java 是我們內部構建的核心應用服務器的選擇語言。 普熱梅克 24000 個事務/秒是我們所有實例中高峰事務速率的平均值。 工作量主要是 OLTP，但是由于客戶使用我們服務的方式，肯定有 OLAP 組件。 Claude, 很棒的文章，感謝您在幕后進行的深入探尋，我期待更深入的潛水。 社區絕對可以從 SF 經驗中學習。 1.3B 事務...是否還可以將其定義為單個客戶端請求（網頁瀏覽，ajax 請求）以及服務器的相應響應？ 以后的文章建議對實例進行檢測和監視。 數據量，脫機處理，什么類型的數據（http 日志，代碼跟蹤語句，度量標準等）。 嗨，克勞德， 感謝您分享此信息。 它真的很有幫助:-) 彼得 是的，交易是對實例的應用層的請求/響應。 我也一定會通過這個建議。 我希望我的團隊和其他人能看到更多類似的帖子。 我很高興得到如此積極的回應。 謝謝你們！ 驚人的帖子比我以前看到的要詳細得多。 謝謝！ 您今年要參加 Dreamforce 嗎？ 我使用該平臺已有幾年了，我一直想知道它是如何在后臺運行的。 處理的數據量以及所有響應的響應速度簡直太瘋狂了。 很棒的帖子！ 感謝分享！ 驚人的帖子， 在注釋部分提到的是 Oracle DB。 我猜一個實例中的群集。 您如何處理 HA 和 DR？ 例如，如何將 Appexchange 部署添加到不同的位置，例如在同一地點？ 是否存在共享實例，還是僅在所有實例中都復制了？ 感謝您的評論。 有趣的文章-感謝分享。 您如何監視系統-性能和中斷。 除了 Nagios 之外，您還使用其他監視工具嗎？ Splunk，仙人掌等？ 感謝您分享知識。 有許多服務器可為來自不同大陸的客戶提供應用程序層服務。 您是否為每個新的注冊客戶端創建單獨的數據庫？ 或每個服務器的數據庫有一定限制。 在數據庫層部分找不到太多有關如何進行負載平衡的信息？ 引人入勝的文章，并保持他們的到來。 我經常推測出幕后的魔力，這絕對是一本好書。 我希望類似的帖子將繼續圍繞這樣的主題-它們不僅通過透明性建立信任-它們還有助于增進我們的集體工程知識。 謝謝！ 嗨 非常有啟發性的文章！ 我想深入了解 Force.com 網站如何與整個事情聯系在一起。 它托管在 DMZ 區域中嗎？ 謝謝！ 是否考慮過像事務服務器集群這樣的單獨層來減少會話負載？ 當然，我假設在數據庫層而不是在應用程序服務器層運行存儲過程。 您可以在以下位置找到 Salesforce.com 架構幻燈片：http://www.slideshare.net/gueste35dd2/salesforcecom-corporate-presentation-july-2009?next_slideshow=1-上面的劃線鏈接要求我注冊&，但要付費 。 很棒的架構概述！ 要求：這是 2 歲。 請分享過去兩年中的體系結構和基礎架構升級。 謝謝 ！ 現在的堆棧是什么樣的？ 它是如何成長的？ 什么是新的，什么掉了？ 軟件堆棧必須已大修幾次。 從接收的客戶數量來看，SFDC 的技術足跡必須每年增長 10-20％？