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

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

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

缘起

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

http://www.infoq.com/cn/articles/uber-build-high-qps-services

不少人问我，是否是uber之后要用go去替代Node.js？

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

区分场景

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

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

先看一下文章说的“选择Go的缘由”

当咱们评估所要使用语言的时候，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、游戏），多核计算类的都有很是好的性能优点。

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

黑一下go语言吧: 够(go)不着

go的缺点是很难够(go)着

• 没有好的包管理，目前生态还不是特别好，选择的可能很少
• 没有好的调试工具，tdd/bdd新手难掌握(vscode-go还凑合)
• 语法问题，强c背景的人很少

总结：适合高端人群，但对团队开发是有门槛的，不适用国内大部分大团队，固然若是你的团队足够牛逼，选go是很是好的选择。

羊和骆驼的故事告诉咱们：够得着你牛逼，够不着，累死你也够不着

架构的演进

架构的演进过程，通常以下

• 不管如何，先实现(不择手段，或者说用本身擅长的)
• 优化（一棵树上吊死）
• 服务化（东拼西凑，捉襟见肘，趋于稳定）
• 合适的技术作合适的事儿（有选择的挖坑优化）

若是Uber的服务都很是成熟了，那么它是有能力彻底用其余语言重写的，用go重写地理查询服务，是由于它已经演化到了第四阶段，有了以前的精力才有今天的可转变。

其实，我对语言并无什么偏见，按照目前技术发展速度来看，将来应该是一个技术多样性，语言性能趋于相同，你们只看喜爱来决定选用那种语言的局面，而不是语言之争。

其实最终仍是要回归到架构的本质上去的，场景决定技术。

在将来很长一段时间，Node.js都会是Uber的主要服务，即便替换也会一点一点的来，积累与成本是不可能短期消失的。

咱们要问的是：“如今处于什么阶段？当前场景下使用Node.js是否合适？”，而不是看人家用go重写了。。。

全文完

欢迎关注个人公众号【node全栈】