# Facebook：用于擴展數十億條消息的示例規范架構 > 原文： [http://highscalability.com/blog/2011/5/17/facebook-an-example-canonical-architecture-for-scaling-billi.html](http://highscalability.com/blog/2011/5/17/facebook-an-example-canonical-architecture-for-scaling-billi.html)  可擴展，實時，高可用性服務的體系結構應該是什么樣？ 可供開發人員使用的選項太多，但是如果您要尋找通用模板，則該架構由[后端團隊的 Facebook](https://www.facebook.com/notes/facebook-engineering/scaling-the-messages-application-back-end/10150148835363920#) [消息](/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html)后端小組負責人 Prashant Malik 描述。 應用后端是一個很好的示例。 盡管 Messages 的任務是每月處理來自電子郵件，IM，SMS，文本消息和 Facebook 消息的 135 億多條消息，但您可能會認為這是 BigArchitecture 的示例，不適用于較小的站點。 不是這樣 這是一個很好的，經過深思熟慮的非云架構示例，展現了任何媽媽都會為之驕傲的許多品質： 1. **分層**-組件獨立且隔離。 2. **服務/ API 驅動的**-每個層都通過定義明確的接口連接，該接口是訪問該服務的唯一入口點。 這樣可以避免令人討厭的復雜相互依賴關系。 客戶端隱藏在應用程序 API 的后面。 應用程序使用數據訪問層。 3. **分布式**-層透明地分布在計算機集群之間 4. **單獨的應用程序邏輯**-應用程序邏輯封裝在提供 API 端點的應用程序服務器中。 應用程序邏輯是根據其他服務實現的。 應用服務器層還隱藏了直寫式高速緩存，因為這是寫入或檢索用戶數據的唯一位置，它是高速緩存的理想之地。 5. **無狀態**-狀態保存在數據庫層，緩存層或其他服務中，而不保存在應用程序中或塞在本地口袋中。 6. **可伸縮組件服務**-其他本身可伸縮且高度可用的服務用于實現此服務。 消息還使用：Memcache，用戶索引服務和 [HayStack](http://haystacksearch.org/) 。 7. **完整堆棧操作**-開發了工具來管理，監視，識別性能問題并在整個堆棧中上下擴展整個服務。 8. **蜂窩**-消息具有稱為**單元**的機器和服務群集作為其系統的基本構建塊。 如果需要更多的機長，則以遞增方式添加單元。 一個單元由 [ZooKeeper 控制器](/blog/2008/7/15/zookeeper-a-reliable-scalable-distributed-coordination-syste.html)，應用服務器集群和[元數據存儲](https://www.facebook.com/note.php?note_id=454991608919)組成。 單元提供隔離，因為處理請求的存儲和應用程序功能獨立于其他單元。 單元可能會發生故障，升級并在與其他單元無關的數據中心之間分布。 質量 1-7 是眾所周知的，并且相當廣泛地得到認可并以某種形式或另一種形式部署。 *單元*的想法沒有得到廣泛應用，因為它使抽象級別提高到 *11* 。 Salesforce 具有類似的概念，稱為[窗格](http://www.salesforce.com/dreamforce/DF09/pdfs/BKSP005_Moldt.pdf) *。* 對于 Salesforce，每個 Pod 包含 50 個節點，Oracle RAC 服務器和 Java 應用程序服務器。 每個吊艙支持成千上萬的客戶。 我們已經看到其他產品以類似的方式捆綁碎片。 分片將由數據庫集群和存儲組成，該存儲將主從配置或主主配置隱藏到高度可用且可伸縮的單元中。 [Flickr](http://highscalability.com/flickr-architecture) 是此策略的早期且出色的示例。 本文真正有趣的一點是如何處理單元中的群集管理以及如何處理作為一個單元的單元管理。 那是很難正確的部分。 在機器集群中，節點以及因此這些節點上的服務可以隨時閃爍并消失。 配置可以隨時更改也可以更改嗎？ 如何使單元中的所有系統保持協調？ ZooKeeper。 ZooKeeper 用于高可用性，分片，故障轉移和服務發現。 易碎機器集群的所有基本功能。 在單元應用程序服務器中，服務器形成一致的哈希環，并且用戶在這些服務器之間分片。 跨單元操作如何處理？ 消息具有*發現服務*，它是一種用戶 DNS，它位于單元上方，并維護用戶到單元的映射。 如果要訪問用戶數據，則必須先使用該服務找到正確的單元格。 在該單元中，*分布式邏輯客戶端*充當發現服務的接口并處理 ZooKeeper 通知。 [文章](https://www.facebook.com/notes/facebook-engineering/scaling-the-messages-application-back-end/10150148835363920#)寫得很好，并且有很多細節。 非常值得一讀，特別是如果您試圖弄清楚如何構建自己的服務時。 ## 相關文章 [ * [Facebook 的新實時消息系統：HBase 每月存儲 135 億條消息](/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html) * [ZooKeeper-可靠，可擴展的分布式協調系統](/blog/2008/7/15/zookeeper-a-reliable-scalable-distributed-coordination-syste.html) * [Facebook 關于高可伸縮性的文章](http://highscalability.com/blog/category/facebook) * [Force.com 基礎架構內的外觀](http://www.salesforce.com/dreamforce/DF09/pdfs/BKSP005_Moldt.pdf) 您遇到了錯誤的干草堆：http://planet.admon.org/haystack-new-storage-solution-for-billions-of-photos/ 謝謝埃利奧特。 我不確定這是怎么回事，可以肯定我只是復制了他們的網址。 無論如何，現在應該修復它。 我認為 Facebook 意味著另一個干草堆 http://www.facebook.com/note.php?note_id=76191543919。 閱讀有關 Facebook Messages 存儲基礎架構的文章，網址為 http://www.facebook.com/note.php?note_id=454991608919，其中包含正確的 URL。 我們的意思是：狀態保存在數據庫層，緩存層或其他服務中，而不是在應用程序中或塞在本地口袋中。