升级分为Elasticsearch server升级和Elasticsearch client api升级
为什么要迁移当前团队内多个业务方公用一套ES集群，容易被影响，重要业务应该独自搭建一套集群
迁移的优势：
降低业务耦合性，加强不同业务隔离；
丰富的资源提供更好的服务支撑；
为什么选择ES2.3在1.X系列之上，ES2.X算是开启了又一个重要的里程碑，文档的展示样式也体现了该版本的重要性，当然了这只是冰山一角；
下边是增强说明（下边两幅图说明了同一个观点：更优秀的功能集成在了2.X版本上）：
附上地址：https://www.elastic.co/blog/release-we-have 新功能
我们既然决定了迁移，那就一起升级到优秀的版本，2.3.3是当时最新的版本,算是比较稳定的版本，看他最近一次提交是5.17；
上边两个接口的迁移效果
因为上周中间才开始，还在观察期，中间的几个突兀是期间来回切换重启，缓存失效引起，当然，这个效果是ES Server在基本上没怎么调优的情况下的效果，之后会一遍观察，一遍调优，找出适合我们自己的配置；
ES升级方案 升级策略搭建自己业务独立的ES集群(2.3.3)
API更新换代
配置文件*以下列表中的参数可支持自动化配置，其余未列出来皆用默认配置（如有不妥，请及时纠偏，尤其是 配置节点类型一列）
配置参数功能简介配置节点类型自动化配置建议配置所属模块 data master data master node node.master data master node.data data master index.number_of_shards data master index index.number_of_replicas data master index.refresh_interval data master index.merge.scheduler.max_thread_count data master index.unassigned.node_left.delayed_timeout data master index.search.slowlog.threshold.query.warn data index.search.slowlog.threshold.fetch.warn data index.indexing.slowlog.threshold.index.warn data monitor.jvm.gc.old.warn data master monitor monitor.jvm.gc.old.info data master monitor.jvm.gc.young.warn data master monitor.jvm.gc.young.info data master script.inline data script script.indexed data path.logs data master path path.data data master network.host data master network transport.tcp.port data master http.port data master discovery.zen.ping.multicast.enabled data master discovery discovery.zen.ping.unicast.hosts data master discovery.zen.minimum_master_nodes master gateway.recover_after_data_nodes data gateway gateway.expected_data_nodes data gateway.expected_master_nodes master gateway.recover_after_master_nodes master gateway.expected_nodes data master gateway.recover_after_nodes data master gateway.recover_after_time data master action.disable_delete_all_indices data master action action.destructive_requires_name data master shield.enabled data
cluster.name
集群名称
node.name
节点名称