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