知乎从Python转为Go，是不是代表Go比Python好？-轻识

来源｜业余草

众所周知，知乎早在几年前就将推荐系统从 Python 转为了 Go。于是乎，一部分人就说 Go 比 Python 好，Go 和 Python 两大社区的相关开发人员为此也争论过不少，似乎，谁也没完全说服谁。

知乎从Python转为Go，是不是代表Go比Python好？我认为，各有优点，谁也取代不了谁，会长期共存！

“由 Python 语言转向 Go 语言就说明 Go 语言比 Python 语言好”完全是一种片面理解。

“语言至上论”是解决不了业务问题的，选 Go 也不行，Java 也不行。

Go 的优势是文件易部署，协程机制相对成熟且简单，以及静态编译语言的效率，还有就是编程模式相对简单。这大概是现在越来越多企业尝试Go的原因，除了知乎，B 站也把核心部件从 PHP 转到了Go。

除此之外，BAT 等互联网巨头，内部都有系统采用了 Go 语言。

那是不是说 Python、PHP 不行了？当然不是也不应该是这样的。如果要坚持Python、PHP，也是没问题。一个系统沉积太久的话，会产生很多大大小小、零零散散的“技术债”，这其间就涉及解决成本的考量，重构、重写、抑或重新设计核心模块或新模块？由此又带来技术选择的问题。还有Python、PHP人才储备的问题，还有团队希望尝试新技术的考虑。这些问题交织在一起，就不是哪个编程语言好跟坏这么简单的事儿了。所以还是要回到业务层面来看技术解决之道。

不得不说，Go的协程，一个“go”就能解决绝大多数问题，确实写代码很简洁，Python 新添的 asyncio 还是相对复杂，Future、Task等等还是有不少门道的。所以，技术永远只有合适的，而没有最佳的，也没有非此即彼的好坏分明。

我相信，如果团队在 Python 方面积累厚实，且热衷专注于 Python，选择Python 应该就是个大概率事件。Python 现在已经应用颇广，特别是在 AI 领域带动下，Python 人才也不像以前那样难找工作了，铁打的营盘流水的兵，是不是知乎也面临人才流动压力？此外，毕竟 Python 的生态，在这么多编程语言中，是数一数二的，Go 虽热，但在社区方面恐怕还是比不上 Python、PHP，这也是一个现实问题。知乎前端换了 React，我没感觉比原来的 AngularJS 进步，但不能就此说 React 不行。尝试用 Go 写一些原来 Python 的范围，也是同理。而且一个系统同时应用多种开发语言、一系列技术栈，都是再正常不过的事了。

Python 有自己的场景，不会被彻底替换的，担心也是多虑的，反正都是“增删改查”嘛！

至于，知乎为什么选择 Go，内部的一些工程师透露：选择 Go 并不是一个人的决定，而是整个团队深思熟虑后的结果！

众所周知，知乎社区后端的主力编程语言是 Python。

随着知乎用户的迅速增长和业务复杂度的持续增加，核心业务的流量在过去一年内增长了好几倍，对应的服务端的压力也越来越大。随着业务发展，我们发现 Python 作为动态解释型语言，较低的运行效率和较高的后期维护成本带来的问题逐渐暴露出来：

运行效率较低。知乎目前机房机柜空间已经不足，按照目前的用户和流量增长速度，可预见将在短期内服务器资源告急（针对这一点，知乎正在由单机房架构升级为异地多活架构）；
Python 过于灵活的语言特性，导致多人协作和项目维护成本较高

受益于近些年开源社区的发展和容器等关键技术的普及，知乎的基础平台技术选型一直较为开放。在开放的标准之上，各个语言都有成熟的开源的中间件可供选择。这使得业务做选型时可以根据问题场景选择更合适的工具，语言也是一样。

基于此，为了解决资源占用问题和动态语言的维护成本问题，我们决定尝试使用静态语言对资源占用极高的核心业务进行重构。

为什么选择 Golang？

如上所述，知乎在后端技术选型上比较开放。在过去几年里，除了 Python 作为主力语言开发，知乎内部也不乏 Java、Golang、NodeJS 和 Rust 等语言开发的项目。

Golang 是当时知乎内部讨论交流最活跃的编程语言之一，考虑到以下几点，知乎决定尝试用 Golang 重构内部高并发量的核心业务：

天然的并发优势，特别适合 IO 密集应用
知乎内部基础组件的 Golang 版生态比较完善
静态类型，多人协作开发和维护更加安全可靠
构建好后只需一个可执行文件即可，方便部署
学习成本低，且开发效率较 Python 没有明显降

相比另一门也很优秀的待选语言—— Java，Golang 在知乎内部生态环境、部署的方便程度和工程师的兴趣上都更胜一筹，最终我们决定，选择 Golang 作为开发语言。

最后，我们做个简单总结：第一点，重构语言的选择，关键要跟公司技术背景和业务场景结合起来；第二点，架构尽量灵活，并不断自我迭代；第三点，监控要早点开展，并尽可能底层化、通用化。