https://www.elastic.co/guide/en/elasticsearch/reference/current/breaking-changes-2.3.html
2.0比1.7的变化
其中红色部分是这次迁移过程中遇到需要解决的问题，带箭头的是ES Server变化的相关部分，不带箭头的是代码层面需要变化的部分；
其中，代码改动部分最大的是Query DSL changes;
2.1的变化
search changes：search type的count和scan过期了；
2.2的变化
比较少，摘一个
如何同步迁移时的新需求从master分支上上新开一个branch ，每次master增加新功能，上线之后，立马同步到新的branch，时时保证同步性；
迁移流程搭建一套新的ES2.3.3集群；
全量写入数据索引，观察ES写入是否正常，修改出现的问题，直至索引写入OK；
上线每天全量刷数据到索引的服务，观察两天，索引创建过程及结果正常；
此时线上有一套1.7的刷索引服务和读索引服务，还有一套ES2.3刷索引服务，此时ES2.3增量索引也正常进行；
将搭建好的ES2.3备份集群上线，收集数据服务接入该备份集群，通过双写的方式保证数据正常；
在3、4、5进行期间，在测试环境上部署ES2.3的搜索服务，通过这段时间线下的点击来发现问题，修复直至搜索和1.7结果一致；
原有服务4台Server，增加一台Server，发ES2.3API端的分支（该分支请求ES2.3索引），通过流量配置平台将该台server流量调至1/50，通过观察错误日志和监控图表，直至无问题；（此时有问题，通过OCTO的禁用，可以瞬间恢复）
继续放开流量，一边放流量一遍观察日志和监控，直到1/5，没问题，然后发新加的3台机器，直至放入1/2流量，继续观察，无问题后，通过服务管理平台禁用原来ES1.7的API端而不是直接下掉服务（这样即使有问题，可以通过服务管理平台的禁用瞬间恢复）；PS：这个观察的时间还是蛮长的，几个小时吧
观察一段时间没什么问题，随后增加少量代码，实现一键切换的功能，验证、上线，完全上线之后，一键切换到备份集群，没什么问题，再切回来；
观察整个周末线上服务的一个运行情况，基本无大碍（有一个GC的问题，已经整理到需要解决的问题里边），然后将数据收集服务里边的一些定时任务迁移到ES2.3的收集服务里边，上线；
截止到上周末为止，升级、迁移基本完成，原有集群任务还在跑，考虑再跑这周，下周跑几天，没有问题的话，做一下善后处理，下掉对ES1.7的完全引用，收拾收拾代码，开始ES2.3的业务之旅；
ES集群宕机方案 索引采用双写的机制，保证当前使用索引和备份索引保持一致；
搜索采用ZK配置，一键切换使用集群；
凌渡冰 目前就职于美团 Do what you like to impact the world.