當MongoDB由於存儲的數據越來越多， 由於性能原因， 或者單個主機資源限制， 垂直擴容沒有辦法進一步的時候， 我們就需要開始考慮水平擴容了。
與垂直擴容不同的是， 水平擴容不需要新添加的機器有多麼強大的功能，它的設計理念是將業務數據儘可能平均的劃分成一段一段的， 每一段分佈在一臺機器上， 這樣， 當系統需要進一步擴容的時候，只需要添加機器， 將現有數據的一部分遷移到新添加的機器上， 舊的系統就有能力繼續處理業務。
sharding 的架構：
ShardRegistry
ShardRegistry是 一個管理集羣shard的類， 它主要有如下的功能：
- shardMap: 通過shardID， replicaName， host找到Shard；
- shard與其他的host的網絡連接；
- 根據configsvr的shard 集合內容更新shard內容；
- 執行分片的command；
CollectionMetadata
該類記錄了集合的metadata， 尤其是集合的遷移相關的信息。
CatalogManager、CatalogCache
CatalogManager及其子類主要是用來enable sharding集合， 以及添加、刪除shard等操作， 與副本集的catalog類相似， 主要是用來管理cluster的相關操作；
CatalogCache用來緩存集合的metadata， 主要是對只讀的集合metadata。 對於sharding的集合， 很多操作都需要metadata， 通過Cache， 可以方便程序的metadata讀取。
Balancer
balancer是一個後臺進程的類， 它負責將cluster裏面各個shard的chunks的個數的均勻分佈， 它通過ChunkManager， 收集到各個shard的chunk 信息， 當2個shard的chunk數差異超過一定的門檻， 就會觸發MoveChunk 命令， 進行chunk的遷移。
ChunkManager
ChunkManager用來記錄shard的chunk信息， 以及查詢的時候， 將查詢命令裝換成shard key的索引信息；
ShardingState
這個類是DB layer非常重要的一各， 負責記錄任務執行過程中， 集羣的狀態。比如， moveChunk遷移過程中， MigrationSourceManager調用源端接口， 記錄需要遷移的chunks， MigrationDestinationManager表示在目的shard轉入數據， 以及相應的遷入過程；另外， splitChunk， mergeChunk以及moveChunk過程， 都會涉及chunk的改變， 需要更改metadata以及chunk的分佈信息等等。