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