不要使用Python开发大型项目!
当前位置:点晴教程→知识管理交流
→『 技术文档交流 』
这两天正好在办公室那破沙发上瘫着,咖啡喝到胃疼,结果我们组那个小李突然问我一句:“东哥,大型项目能不能用 Python 啊?你不是之前写过一个嘛?” 我当时脑袋嗡一下,你懂吧,就是那种“哎哟这事儿又来了”的感觉。反正我就随口念叨:“兄弟…别闹,大型项目真别用 Python,能避则避。”然后我怕他以为我是在装老油条,就稍微摊开说了下。你等下,我先喝口水……好,继续。 唉首先吧…为什么别用?不是说 Python 不好,Python 超好用,写点小工具、脚本、自动化、数据处理,那叫一个舒服,连我爸我估计教两天也能写点啥。问题不是能不能写,是写完能不能上战场、能不能扛住风吹雨打。 我去年在公司楼下抽烟的时候(别学,抽烟不好),我们后端架构师过来跟我抱怨,说我们另外一个部门把一堆核心业务写 Python,结果高峰期那延迟…跟弹幕似的往上飙。服务器负载也上天,最后又加机器又加缓存,搞得跟补锅一样。 Python 天然有个锅——GIL(Global Interpreter Lock)。这东西就像办公室里只有一个微波炉,大家都要热饭,结果再多线程也没用,最后还是得排队。 我当时给小李解释的时候手都在比划:“你开 20 个线程,你以为你 20 倍性能?不存在,都是挤一个门。” 还有 I/O 密集型倒是还能混混日子我前阵子写个监控脚本,用 但是 CPU 密集?兄弟你用 Python 做图像处理、大规模数据计算,或者复杂业务规则全靠 Python算,那就真的像用电动车拉钢筋一样,能拉,但心酸。 你看这个我当时顺手写的例子,给他看了一眼他都沉默了: 你以为是 10000000? 呵呵,不一定,GIL 让你线程看似并发,实际上像是轮流在上厕所,抢资源的时候还容易打架。 但真正让我劝退的…是维护成本我去年十一点半在公司加班(那天大雨,我鞋都湿了),线上一个 Python 服务出问题,日志全是 coroutine 的栈,我整个人都麻了。 Python 灵活,灵活到什么程度?灵活到你完全不知道别人写的是什么玩意。我们组有个新来的喜欢搞“黑魔法”,各种动态注入、猴子补丁(monkey patch),我读他代码的时候一句话都说不出来,整个人跟 AI 一样失语。 大型项目一旦代码量上万,Python 的灵活就变成了混乱。 Java 那种一板一眼反而稳得多。 再说说性能优化,Python 真的是个无底洞你要优化?可以啊,上 Cython。 不够?上 PyPy。 再不够?上 C 扩展。 再不够?上 Rust binding。 最后你会发现你整个项目只有外壳是 Python,里面全是别的语言。 我那天跟小李说到这,他还反问我一句:“那大厂不是也用 Python 吗?” 我直接笑了:“用啊,人家用 Python 写调度、脚本、服务编排、小 API、高级业务逻辑,真正的性能核心全部 C++、Java 顶着呢。” 哦对了,还有部署别跟我说 Python 部署简单,那都是小项目。 大型项目一旦上容器,上多环境,上大量依赖,你看看 Python 的依赖树长啥样。 还有不同线上机器 Python 版本不一致? 哎我是真的吃过亏,有一次线上一台机器是 Python 3.6,另一台 3.9,结果一个依赖 import 行为不一样,半夜报警响得像过年。 不过我不是说不能用 Python,只是要用对地方这个我怕小李听偏了,我赶紧补一句: “兄弟 Python 用来写大型业务系统的外围、AI 处理、自动化、调度、轻量服务,这是它的舒适区。让 Python 扛一个核心业务的大型项目,你这是让马拉货车,累不累?” Python 非常适合:
但是不适合:
我那天跟小李说到最后,他也懂了我说:“你要真想用 Python 写大型项目,那你得先准备好——”
然后我说着说着,我手机还响了,是外卖到了,我就跟他说:“行吧,今天就这样,你要真有兴趣我们回头搞个 demo,你自己上手就知道了。” 我外卖凉了点,但这不重要。重要的是——Python 是好东西,但大型项目这种活,让它干是不厚道的。 算了不说了,外卖真的凉透了…… -END- 阅读原文:原文链接 该文章在 2025/12/15 9:08:31 编辑过 |
关键字查询
相关文章
正在查询... |