MongoDB：在應用伺服器上共同定位 mongos 程序
我想問一個關於本文件中描述的最佳實踐的問題：
http://info.mongodb.com/rs/mongodb/images/MongoDB-Performance-Best-Practices.pdf
使用多個查詢路由器。使用分佈在多個伺服器上的多個 mongos 程序。常見的部署是將 mongos 程序放在應用伺服器上，這允許應用程序和 mongos 程序之間進行本地通信。適當數量的 mongos 程序將取決於應用程序和部署的性質。
只是關於我們的部署的一點背景。我們有很多應用伺服器節點。它們中的每一個都使用無狀態 RESTful WS 執行一個基於 JVM 的程序。正如這個最佳實踐所建議的那樣，每個應用程序伺服器節點都執行自己的
mongos程序，這意味著 JVM 程序的數量始終等於程序的數量mongos。所有
mongos程序都連接到 3 個配置伺服器和幾個 mongo 分片（每個分片內都有副本集）。儘管我們使用的是分片部署，但我們並沒有真正分片我們的集合。事實上，我們有大量的數據庫，它們在創建期間分佈在所有分片中（這是我們目前分片的主要案例）。由於最佳實踐還建議“適當數量的 mongos 程序將取決於應用程序和部署的性質”，我開始懷疑我們的使用
mongos是否真的合適，或者如果我們有幾個專用mongos節點並讓我們的應用伺服器無需在mongos本地執行即可連接到它們。您對
mongos根據應用程序伺服器實例數或 MongoDB 集群大小確定合適的實例數的最佳方法有何看法？最近，我們開始研究無狀態 Web 服務的集群管理，我指的是 Docker、Apache Mesos 和 Kubernetes 等工具。如果我們使用 Docker，那麼通常不鼓勵在容器中執行多個程序。考慮到這一事實，很難確保應用伺服器容器和
mongos容器始終位於同一個物理節點上並具有相同數量的程序。這讓我想知道這個最佳實踐是否仍然適用於我剛剛描述的集群架構。如果沒有，您能否建議mongos在此架構中定位和部署流程的更好方法是什麼？
由於已經送出了答案，並且是一個有用且有效的答案，因此我不想分散其自身的用處，但確實有一些要點可以提出，而不僅僅是簡短的評論。所以考慮一下這種“增強”，它希望是有效的，但主要是對已經說過的內容的補充。
事實是要真正考慮“您的應用程序如何使用數據”，並且還要了解“分片環境”中的因素以及您提出的影響這一點的“容器環境”。
背景案例
將程序與應用程序實例放在一起的實踐建議的一般做法
mongos是避免應用程序與該mongos程序通信所需的任何網路成本。當然，mongos在“最近”節點由於某種原因不可用的情況下，在應用程序連接字元串中指定多個實例也是“推薦做法”，然後可以選擇另一個，儘管可能會產生聯繫遠端節點。您提到的“碼頭工人”案例似乎有些武斷。雖然容器的主要目標之一（在此之前，諸如 BSD 監獄甚至 chroot 之類的東西）確實是實現某種程度的“程序隔離”，但執行多個程序並沒有什麼問題，只要你了解其中的含義。
在這種特殊情況下，
mongos它意味著“輕量級”並作為應用程序程序的“附加功能”執行，其方式幾乎是應用程序本身的“配對”部分。所以 docker 鏡像本身沒有類似“initd”的程序，但是執行像supervisord這樣的程序控制器（例如）作為容器的主程序並沒有什麼問題，然後給你一個程序控制點那個容器也是。這種“配對程序”的情況是一個合理的案例，也是一個很常見的問題，即有官方文件。如果您選擇這種“配對”操作進行部署，那麼它確實解決了
mongos在同一網路連接上維護實例的主要問題，並且確實解決了作為應用程序伺服器本身的“伺服器實例”的問題。也可以以某種方式將其視為“整個容器”失敗的情況，然後該節點本身將無效。並不是我會推薦它，實際上您可能仍然應該配置連接以查找其他mongos實例，即使這些實例只能通過增加延遲的網路連接訪問。特定於版本/特定於使用
既然已經說明了這一點，這裡的另一個考慮因素又回到了最初考慮將
mongos程序與應用程序放在一起以實現網路延遲的目的。在 2.6 之前的 MongoDB 版本中，特別是在聚合框架等操作方面，會出現更多的網路流量和後續處理工作，這些工作由mongos處理來自不同分片的數據的程序執行. 現在情況並非如此，因為現在可以在這些分片本身上執行大量處理工作負載，然後“蒸餾”到“路由器”。另一種情況是您的應用程序使用模式本身與分片有關。這意味著主要工作負載是在多個分片上“分佈寫入”，還是在整合讀取請求時確實是“分散-收集”方法。在那些場景中
測試，測試，然後再測試
所以這裡的最後一點是不言自明的，歸結為對您問題的任何理智回應的基本共識。對於 MongoDB 或任何其他儲存解決方案來說，這並不是什麼新鮮事，但是您的實際部署環境需要在其“使用模式”上進行測試，就像對核心組件或任何預期功能的“單元測試”一樣接近實際情況。總體結果需要測試。
除了按預期測試對您的應用程序性能和可靠性而言“實際上最有效”的方法之外，實際上沒有“明確的”聲明說“以這種方式配置”或“以這種方式使用”實際上是有意義的。
當然，“最好的情況”永遠是不要
mongos用來自“許多”應用程序伺服器源的請求“擁擠”實例。但隨後允許他們一些自然的“平價”，可以由可用的資源工作負載分配，以“至少”擁有一個可以選擇的“資源池”，實際上在許多情況下是理想的，但不需要引發額外的“網路傳輸成本”。這是目標，但理想情況下，您可以“實驗室測試”不同的感知配置，以便為您的最終部署解決方案找到“最合適”的解決方案。
我還強烈推薦已經提到的“免費”（如啤酒）課程，無論您的知識水平如何。我發現各種課程資料來源經常提供“隱藏的寶石”，讓您更深入地了解您可能沒有考慮或忽略的事情。如前所述，M102 課程由 Adam Commerford 建構和指導，我可以證明他對 MongoDB 和其他數據架構的大規模部署具有高水平的知識。值得花時間至少考慮一下您可能認為自己已經知道的新觀點。