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

Posted 2021-04-05 Node全栈

如何评价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会让你死的很惨，血与泪的教训都在告诉我们，这个世界不是二分法来判断的，对与错之外，还有场景这个变量集合。

先看一下文章说的“选择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)着

• 没有好的包管理，目前生态还不是特别好，选择的可能不多

• 没有好的调试工具，tdd/bdd新手难掌握(vscode-go还凑合)

• 语法问题，强c背景的人不多

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

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

架构的演进

架构的演进过程，一般如下

• 无论如何，先实现(不择手段，或者说用自己擅长的)

• 优化（一棵树上吊死）

• 服务化（东拼西凑，捉襟见肘，趋于稳定）

• 合适的技术做合适的事儿（有选择的挖坑优化）

如果Uber的服务都非常成熟了，那么它是有能力完全用其他语言重写的，用go重写地理查询服务，是因为它已经演化到了第四阶段，有了之前的精力才有今天的可转变。

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

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

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

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