问题发现
在使用过程中，通过spark访问集群的效率不是很令人满意，80核心同时运行的速度比单核心也就快了20倍左右，预测瓶颈在mongodb读写上。当然，此时没遇到其他问题暂时没进行问题梳理。
在数据规模增大之后，通过spark访问mongodb集群会造成mongos节点远程连接时输入命令卡顿，怀疑出现了某些性能瓶颈。
具体问题出现如下：
1、某一天发现主节点mongod崩溃。
2、当天重新执行spark任务，第二天发现主节点服务器无法连接，去机柜查看发现主节点服务器宕机，于是决定认真查找瓶颈。
3、重新运行任务，执行top命令：发现计算机核心使用率为100%左右，由于本服务器拥有32核心，并且spark使用其中16核心，所以在ubuntu系统下CPU使用率小于1600%都是正常的，CPU不是系统瓶颈。
使用free -m发现内存仍有剩余，内存不是系统瓶颈。
使用sudo iftop命令，发现TX和RX都在800Mb以上，初步确认是网络带宽瓶颈。
查询系统IO和硬盘容量，排除磁盘问题。
4、确认为网络带宽问题。
问题解决
本地网络环境采用的是万兆网卡和千兆交换机，对于大部分应用足够使用，但是执行spark任务时，由于mongos只有主节点存在，所以所有数据读取任务均占用主节点带宽，如果想要正常使用则需要降低并发度或者提供负载均衡。
Mongodb自身支持负载均衡，对一个sharding集群而言，所有的元数据信息分别存放在mongod里面，但是所有router信息都是放在configsvr中的（包含权限管理的用户信息等），所以想要拓展mongos异常简单，把Mongos的config文件分发到想要启动mongos的机器上，修改一下bindIP直接启动即可，启动后的使用方式和之前的mongos一致，用户信息也都存在不需要重新创建用户。
由于本集群使用了5台服务器部署Mongod，于是解决办法就是将Mongos也启动5个，相当于启动了5个单独的服务端。
启动后重新执行spark任务，在每台服务器上执行iftop查看网络使用，发现TX和RX均有300Mb左右。网络带宽不再是集群的使用瓶颈。
Mongodb的标准uri格式如下：
mongodb://[username:password@]host1[:port1][,host2[:port2],...[,hostN[:portN]]][/[database][?options]]
所以使用时也异常简单，把代码中创建MongoURI或者ReadConfig或者spark.mongodb.imput.uri中的uri按上面格式加入多个host和port即可。
问题反思
1、问题出现早有预兆，应当及早解决这些问题，提前引起重视。
2、mongodb的文档中对URI的介绍在Reference > Connection String URI Format中，当时没有看到，所以没找到怎么连接多个Mongos的方法。只启动一个mongos，但是当时其实也有考虑过可能遇到并发瓶颈的问题，但是没有深究。之后的平台搭建要进行更详尽的设计再进行部署会更加合适。
3、直接在物理机上部署虽好，但是在容器上更容易进行拓展。并且当前的系统以后可能会在多地部署，如果直接部署在k8s上会省下大量部署时间和节约大量人力成本。
4、曾经以为千兆网够用了，以后采购还是万兆网设备更好。