哪个合适上哪个，性能要求不高的用 python ，其他用 go 。
• 请不要在回答技术问题时复制粘贴 AI 生成的内容
This topic created in 623 days ago, the information mentioned may be changed or developed.
 |
1
流行？ 都已经流行几年了 现在流行把微服务切回单体应用了
|
9 |
xuanbgFeb 19, 2025
2
是的，微服务的一大优势就是支持多语言混合开发
|
 |
pkoukkFeb 19, 2025
4
理论上是的，但有能力管理的好微服务的人并不多
多数微服务架构到最后都会变成一坨理不清的毛线球 如果出什么问题排查到最后，发现有问题的这个项目，用这种语言的人离职了/休假了/高升了/转岗了，咋办呢 |
 |
i8086Feb 19, 2025
6
分久必合，合久必分。
分出来，架构不好，就是一坨。 |
 |
8
从逻辑上讲，不应该看流行什么，而是适合什么。流行一个新东西意味做选型的时候多了一种可选方案，而不是必选。
|
 |
freemoonFeb 19, 2025
9
理论上是，实际上不可能也不方便使用多语言构建，因为要考虑团队成员技术栈，说白了就是不好招一个擅长多语言的开发（加钱好说）。
|
 |
chevalierFeb 19, 2025
10
也是，也不是。
是是因为，微服务之间是网络调用的，没有语言依赖。 不是是因为，微服务也需要很多语言框架层面和第三方组件的基础建设，比如耗时埋点、链路追踪等，在我接触到的公司中，这些建设一般都集中在 1-3 种公司常用的语言，不会支持很多语言。 |
 |
rucheeFeb 19, 2025
11
理想很丰满，现实你得考虑维护成本的。
编程语言、技术栈铺太多，写的时候很爽，维护怎么办？有人离职怎么办？张三想去修李四的 BUG 怎么办？这都是些很现实的问题。 所以最稳妥的方案还是单一语言，或者限定两三门语言。 |
 |
LieEarFeb 19, 2025
13
现在又开始流行微服务转单体、下云了。
技术是个圈 |
 |
gitdoitFeb 19, 2025
14
看来大家在经历过微服务的毒打之后, 都发现自己的项目更适合单体;
|
 |
AlexBobFeb 19, 2025
15
是的,微服务 一直都是为大项目服务的,参考微软的,啥开发语言都有各种工具.
只不过在国内被滥用了而已. 微服务的概念就是为云而设计的.很先进. 支持亿级用户,负载也只有微服务能把硬件释放协调好. |
 |
guanhui07Feb 19, 2025
16
没人还是别整 微服务 ，整这么多事
|
 |
17
@crocoBaby 3# 保真，微服务切单体，也是微服务鼻祖 amazon 率先实践。微服务不是灵丹妙药，有它不适用的业务。过去几年跟风切微服务的公司太多了，他们甚至没有经过认真思考和论证。反正提出和推动落地的人，能刷 KPI 和丰富简历，至于老板，大都不懂技术，以为上了这个就一定如何如何。
|
 |
systemGuestFeb 19, 2025
19
你不要只看那一少部分发声吹微服务的，他们才是极少数，绝大多数公司，大多数人，都是图稳定静悄悄搞单体，跑普通业务。
|
 |
YanlongliFeb 19, 2025
21
IT 部门多，业务多，且业务或多或少有关联需要交互的适合微服务跨部门协作，公司就十几个人，IT 也不分部门的，项目之间没有联系的，单体服务才是王道。
|
 |
pingdogFeb 19, 2025 via Android
22
面向 KPI 的编程你拆了也白拆，代码都是屎山，天知道这个 API 有什么坑，强拆就只能 fork 出来在基础上加 feature ，效率还是没变
在系统建设时就要定好方向 |
 |
chendyFeb 19, 2025
23
应该是不需要被绑死，但是该用啥还是要用啥
语言背后是生态和人力成本，不是说写啥好玩就用啥的 |
 |
24
《微服务戏谑调》
拆拆拆，乐高堆成山， 改行运维泪两行。 调用链长赛春运， 流量一涌就撞墙。 监控日志满天飞， 查个 Bug 捉迷藏。 事务分家难同床， 数据打架谁收场？ 发布半夜拼手速， 回滚比谁键盘响。 成本如瀑老板怒， 甩锅大会上分锅忙。 微服务啊微服务， 你说香不香？ |
 |
lujiaxingFeb 19, 2025
25
是. 理论上微服务的情况下, 每个 pod 都可以用不同的开发语言开发.
但是我没见过哪个公司允许员工这么搞的. 而且 微服务 = 高投入. 现在很多中小厂已经退回单体架构了 |
 |
root71370Feb 19, 2025 via Android
26
切回单体+1
|
 |
salmon5Feb 19, 2025
27
需要考虑语言问题，因为绝大多数公司的微服务，都是假微服务，最终还是 CRUD 的屎山
|
 |
8355Feb 19, 2025
28
微服务本身没错，普通业务小厂根本没这个必要就是了。
|
 |
donaldturingleeFeb 19, 2025 via Android
29
微服务一般没有好的架构只能是灾难，不如单体一根
|
 |
30
给你说一个例子：
github 用 ruby on rails ，单体 当然最近几年可能加了一些其他服务 但核心服务还是 ruby on rails 所以我觉得你可以考虑一下 |
 |
xiangbohuaFeb 19, 2025
31
微服务架构好不好是另一回事，决定要做了那就不考虑这个了。
回到要不考虑语言，那是技术层面层面上看，肯定不需要了啊，json 穿就万事了，但是实际执行层面肯定要考虑，招人、用人、文档、技术栈之类全是问题。 除非你们公司打到随便拉一个团队出来都可以抵一个小公司的，否则语言我感觉不要超过 3 种比较好，再多就没必要了。 |
 |
GressFeb 19, 2025
32
分久必合，合久必分。古人诚不欺我
|
 |
G2bN4dbX9J3ncp0rFeb 19, 2025
33
+1 ，我公司切回单体了
|
 |
hausenFeb 19, 2025
34
感觉现在的微服务是为了拆而拆
|
 |
prosgtsrFeb 19, 2025 via iPhone
36
公司有些基础脚手架，如果想用别的语言就得把这些东西再实现一遍，不然没法用
|
 |
doodle123Feb 20, 2025
37
可以是可以，但是从服务注册与发现的角度，体感就不够丝滑。比如 Java 单语言开发，几乎是为 Spring Cloud 体系量身定做的 Eureka 必然是首选。多语言开发的话，Eureka 未必就是首选了，因为虽然 Eureka 支持多语言，但由于官方主要是围绕 Java 和 Spring Cloud 进行开发，非 Java 服务的集成和使用可能需要做一些额外的配置和实现。
|
 |
IamUNICODEFeb 20, 2025
38
是的，不需要考虑语言
切单体+1 |
Select Language