既然都流行微服务了是不是不必考虑语言问题

[pureGirl]

哪个合适上哪个，性能要求不高的用 python ，其他用 go 。

[Yanlongli]

IT 部门多，业务多，且业务或多或少有关联需要交互的适合微服务跨部门协作，公司就十几个人，IT 也不分部门的，项目之间没有联系的，单体服务才是王道。

[fuzzsh]

面向 KPI 的编程你拆了也白拆，代码都是屎山，天知道这个 API 有什么坑，强拆就只能 fork 出来在基础上加 feature ，效率还是没变
在系统建设时就要定好方向

[chendy]

应该是不需要被绑死，但是该用啥还是要用啥
语言背后是生态和人力成本，不是说写啥好玩就用啥的

[wxiao333]

《微服务戏谑调》

拆拆拆，乐高堆成山，
改行运维泪两行。
调用链长赛春运，
流量一涌就撞墙。

监控日志满天飞，
查个 Bug 捉迷藏。
事务分家难同床，
数据打架谁收场？

发布半夜拼手速，
回滚比谁键盘响。
成本如瀑老板怒，
甩锅大会上分锅忙。

微服务啊微服务，
你说香不香？

[lujiaxing]

是. 理论上微服务的情况下, 每个 pod 都可以用不同的开发语言开发.
但是我没见过哪个公司允许员工这么搞的.

而且 微服务 = 高投入.
现在很多中小厂已经退回单体架构了

[root71370]

切回单体+1

[salmon5]

需要考虑语言问题，因为绝大多数公司的微服务，都是假微服务，最终还是 CRUD 的屎山

[8355]

微服务本身没错，普通业务小厂根本没这个必要就是了。

[donaldturinglee]

微服务一般没有好的架构只能是灾难，不如单体一根

[guiyumin]

给你说一个例子：
github 用 ruby on rails ，单体
当然最近几年可能加了一些其他服务
但核心服务还是 ruby on rails

所以我觉得你可以考虑一下

[xiangbohua]

微服务架构好不好是另一回事，决定要做了那就不考虑这个了。
回到要不考虑语言，那是技术层面层面上看，肯定不需要了啊，json 穿就万事了，但是实际执行层面肯定要考虑，招人、用人、文档、技术栈之类全是问题。
除非你们公司打到随便拉一个团队出来都可以抵一个小公司的，否则语言我感觉不要超过 3 种比较好，再多就没必要了。

[Gress]

分久必合，合久必分。古人诚不欺我

[G2bN4dbX9J3ncp0r]

+1 ，我公司切回单体了

[hausen]

感觉现在的微服务是为了拆而拆

[wangsd]

@crocoBaby 我们主要做中小项目，想切回单体，部署太麻烦了。

[prosgtsr]

公司有些基础脚手架，如果想用别的语言就得把这些东西再实现一遍，不然没法用

[doodle123]

可以是可以，但是从服务注册与发现的角度，体感就不够丝滑。比如 Java 单语言开发，几乎是为 Spring Cloud 体系量身定做的 Eureka 必然是首选。多语言开发的话，Eureka 未必就是首选了，因为虽然 Eureka 支持多语言，但由于官方主要是围绕 Java 和 Spring Cloud 进行开发，非 Java 服务的集成和使用可能需要做一些额外的配置和实现。

[IamUNICODE]

是的，不需要考虑语言
切单体+1