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

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

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

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

《微服务戏谑调》

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

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

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

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

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

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

切回单体+1

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

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

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

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

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

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

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

+1 ，我公司切回单体了

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

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

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

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

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