1、后端服务 php 为什么迁移到 java？
网上流传已久的 “世界上最好的语言是 php”，说实话，php 基本上什么都能做，每个领域都能找到一些库。但是在性能上确实有一定的问题。
1、性能及格的服务端
性能上，传统有 C++ 和 Java，现代有 Go 和 Node 还有 Rust，php 虽然搭上 swoole 在这个领域也才算及格。php 天生不支持多线程并发，虽然搭上了 swoole 也搞出了类似多线程，其实底层实现使用的是 多进程的方式。
之前和同事开玩笑说，你非让一个腿瘸的人拄着拐杖跑起来，表明上确实比之前 “跑” 的快，但是他毕竟是瘸子，不可能比正常人跑的快。
2、开发迷途
php 动态类型 + 弱类型，能不添乱就不错了。线上参差不齐的开发人员开发的代码分布在各个地方，当有朝一日出现 bug 时候，没有办法 debug，也没有办法很直观的查到问题，只能无限的打印-输出，来跟踪到可能出错的地方，之后再通过更加细致的打印-输出来判定出错的原因。往往为了寻找或调试一个简单的问题就让人心灰意冷。
2、索引系统为什么选用了 go 而不用搜索体系相同的 java？
要从 go 的协程与 java 的线程来考量
协程是非抢占式的用户态线程，它的所有操作都是在用户态完成的。优势：
1. 可以减少线程不同态来回切换成本以及来回保留现场所消耗的资源
2. 协程本身不存在并发的问题，因为协程本身是在一个线程中运行
3. 协程更轻量，一个协程 几十 KB，一个线程大约 1MB
所以，协程特适合的场景有：多任务调度、数据流处理 以及 接口请求等场景。而索引系统会面临各种业务调度，以及数据流的处理并写入到 es，这种场景非常契合协程的使用场景。
3、rpc 调用为什么选用 dubbo 而不是其他
主要从两个大方面考量的：
1. 整个服务体系架构
目前整个搜索架构采用的是 spring-cloud-alibaba 全家桶的方式构建的，而 dubbo 也属于 alibaba 旗下的开源产品，并于最近开始活跃持续更新。基于此，rpc 方案优先选择 dubbo 方式。
2. 服务治理方面
基于 dubbo 会有一套完备的服务治理相关功能。例如：
1. 服务注册与发现、负载均衡机制、路由规则等
2. 还可以很方便的通过简单的配置，没有任何的 API 侵入完成远程调度
3. 可以很方便的接入限流、熔断服务降级相关组件
4、搜索微服务为什么选用 spring-cloud-alibaba 而不用原生的 spring-cloud？
首先说一下前提，为什么要将服务拆分成微服务体系架构，是因为我们当前的主业务线接入的越来越多，由原来的4 条扩张到现在的 22 条，每条业务对应搜索策略、排序场景都不尽相同，当然有共同的地方可以进行抽象单独提出来。
这种前提下再加上正好搜索要做一次搜索架构重构，来解决目前架构不合理的地方，主要有：
1. 逻辑混乱，没有明确的分层，一个业务线多个主方法入口，给到业务端调用方有多个接口，导致后续维护起来非常的困难，底层 es升级迁移都无法进行。
2. 代码堆叠，一直存在重复造轮子的现象，且经历过多人多版本迭代，已经没有办法或者说不太好进行抽象和封装了。
3. 格式混乱，没有统一的命名规范、注释规范等，导致想弄明白一段逻辑的具体含义，非常困难。
所以借着这个契机，统一做了一次大的重构和优化。
接下来谈谈为什么不选用原生的 spring-cloud 技术体系，主要有以下两点考量：
1. SpringCloud中，很多核心组件，都采用 Netflix全家桶，但是 Eureka,Hystrix 宣布停止运营，Zuul 又由于其阻塞式网络模型，性能比较容易出现瓶颈。这些坏消息，给广大的开源使用者，一记重拳。
否极泰来，2018 年 10 月 31 日的凌晨，这个伟大的日子里，Spring Cloud Alibaba 正式入驻了 Spring Cloud 官方孵化器，并在 Maven 中央库发布了第一个版本。
而且，spring-cloud-alibaba 相关配套组件也一应俱全，相当好用。
2. 在各个项目中通过 rpc 方式调用，而选用的方案就是 dubbo 方式，dubbo 是 alibaba 开源的，而 spring-cloud-alibaba 也是 alibaba 开源的，他们之间可以无缝结合。