如何评价Uber不用Node.js，而用Go语言构建地理查询服务？

点评《Uber是如何基于Go语言构建高QPS服务的》一文，解答读者疑问，通过比较Node.js和go来谈架构演进过程，分享我对未来技术的思考

缘起

大家都是知道uber是大量采用Node.js开发的公司，而2016年4月12日infoq发了一篇名为《Uber是如何基于Go语言构建高QPS服务的？》

很多人问我，是不是uber以后要用go去替代Node.js？

我的回答是，目前看它只是地理查询的地方使用go重写了，这并不意味着，它完全会用go替代Node.js的，而且在绝大部分场景下Node.js是有它的优势的，除了文章讲的场景外，真的很少能找出差异特别大的点，各有优缺点，一个公司想弃用一项技术栈也是很难的一件事儿。

QCon见到朱赟，她说湾区那边ror非常多，而我所了解的国内只有少数极客在用，为什么呢？地域是一方面，文化是一方面，马斯洛的需求层次理论当然也是重要点，再举个例子,北京招聘Node.js非常多，在天津，js能写明白的都不多，为什么呢？

我们看问题，是否也要区分一下场景？比如mvp（最小可用原型）在创业初期非常实用，可是如果你已经过了初期，你的其他功能没有跟上，你的mvp会让你死的很惨，血与泪的教训都在告诉我们，这个世界不是二分法来判断的，对与错之外，还有场景这个变量集合。

当我们评估所要使用语言的时候，Node.js正是广大的服务设计团队普遍采用的编程语言。而我们也在Node.js的使用方面有着丰富的经验。然而，Go语言却由于以下原因满足了我们的需求：

高吞吐量和低延迟的需求。Uber的手机端App在发送请求时，必然会触发一次查找地理围栏的操作。而服务器必须要能够对每秒上万次的请求以99%的概率响应时间小于100ms的速度进行响应。
CPU密集型负载。查找地理围栏需要使用计算密集型的Point-In-Polygon（PIP）算法。尽管Node.js可以很好的用于I/O密集型的服务，解释执行以及动态类型定义等的特性使得它并不适合于我们的使用场景。
非中断式的后台加载。为了保证查询操作是基于最新的地理围栏信息而进行的，服务必须要能够根据多个数据源的信息在后台实时刷新内存中的地理围栏数据。因为Node.js是单线程的，后台刷新很可能会占用一定的CPU时间（如CPU密集型的JSON的编译工作），最终导致部分查询的响应时间过长。但是，对于Go语言而言，这完全不是问题。Goroutine可以运行在多个CPU核上，并且可以在响应前端查询的同时后台并行进行刷新数据的工作。

这个理由解释是ok的，go确实在并发上有它的优势，异步流程控制上比Node.js要强非常非常多，对于一些tcp长连接（im、游戏），多核计算类的都有非常好的性能优势。

可是，亲，你的瓶颈出在哪里呢？真的是性能么？