所以微服务现在可以用cpp/nodejs/python/golang/......实现
dot.net/java优势消减了一大半

【 在 feed 的大作中提到: 】
: 以前一个大系统，如今要拆分为多个微服务。
: 而其他的微服务根本不关心你的微服务是什么语言写的
--
FROM 116.233.89.*

商业考虑的不是技术，而是稳定性和成本
混合技术栈成本太高。
【 在 feed 的大作中提到: 】
: 以前一个大系统，如今要拆分为多个微服务。  
: 而其他的微服务根本不关心你的微服务是什么语言写的  
: --  
:

发自「今日水木 on Android」
--
FROM 114.254.1.*

一般微服务也要使用一些公共的组件、框架之类的方便统一增加、维护功能
譬如增加 tracing，telemetry 之类的东西
多语言会带来额外的负担，特别是没有搞什么sidecar、service mesh之类之前
即使搞了，也是统一的技术栈成本更低

【 在 feed 的大作中提到: 】
: 以前一个大系统，如今要拆分为多个微服务。
: 而其他的微服务根本不关心你的微服务是什么语言写的
--
FROM 218.17.141.*

nodejs系就是搅屎棍吧。但凡超过1.5年码领的代码，基本上拉下来能跑的概率超不过50%吧，更不要说可能不超过1M代码，nmp一下能给你拖出来上百兆的拖油瓶吧。

【 在 keygen 的大作中提到: 】
: 除了cpp这种行为艺术，其他的还是能打的
: Nodejs跟前端无缝结合，python简单，java生态威武雄壮，golang 云原生的宠儿
: 性能什么的都是最后才需要考虑的问题
: ...................
--
FROM 112.96.57.*

这个确实问题很大……npm是个大粪坑……

不过更体现出docker优势了，趁着build能通过赶紧做成镜像固化

【 在 shocker 的大作中提到: 】
: nodejs系就是搅屎棍吧。但凡超过1.5年码领的代码，基本上拉下来能跑的概率超不过50%吧，更不要说可能不超过1M代码，nmp一下能给你拖出来上百兆的拖油瓶吧。
--
修改:oldwatch FROM 116.233.89.*
FROM 116.233.89.*