转载

微服务的灾难-技术栈

微服务的布道师们特别喜欢鼓吹一个观点：拆分微服务之后，我们可以随意地对小模块进行重构，选择最合适的技术栈，并且如果写失败了随时对这个模块拿其它语言进行重写。这一点被大多数布道师当作微服务的重点优势。

但是布道师们有意地把这样做所带来的问题忽略了，或者更恶意的是，他们明知道有问题，但是不说？啊哈哈。

一个公司业务上有多种语言的话，理论上可以吸引到各种“语言的人才”。这确实不假，并且可以提供给各种语言大佬一个互相掐架的优秀竞技场，只要干掉对手(其它语言的大佬)了，我就可以扩张团队，让团队把所有其它语言的模块用我们擅长的语言重写一遍，善哉善哉。小伙子们一年的事情就都安排上了。

但是显然这种说辞是有问题的。在现行的微服务架构下，除了业务本身的研发人力投入之外，在业务之外的支持系统的研发工作也有很大的工作量，比如典型的，服务发现，熔断，优雅重启，存储系统 client，消息队列 client，缓存 client，配置系统 client 等等。。各种周边系统版本依次叠代下来，那可能也是几百上千人一两年的工作。为什么会带来这么多的工作量？其中很大一部分就是因为语言和技术栈混乱造成的。比如一个公司的技术栈能够统一到 java 的话，那没什么说的，大家都用 Spring Cloud 全家桶或者 Dubbo 全家桶就可以了。但是你们既有 java 又有 Go 又有 PHP 又有 C++ 又有 NodeJS 又有 Rust，这样显然就很难在众多神仙中达成一致。比如你想要选用 java 的 Spring Cloud 生态，但是这里面的服务发现或者配置系统并没有打算对其它语言进行支持，即使支持可能也支持地不全面。一旦支持不全面，公司内的轮子党们一定会跳出来，强行给你找出几十个缺点，一杆子打回去，最终得到一定要自己造这些轮子的结论。

好家伙，五种语言八种框架，一个服务发现的 client 轮子造五遍都能算少的了。目前开源界的趋势是将那些和业务无关的非功能性需求从模块中剥离出来，比如 service mesh 就是很好的尝试，只不过现阶段用过的都说坑。说好的那都是不怀好意，拉人入坑。对于研发人员来说，一个轮子造五遍真的没什么意思，可能也就是熟悉了五种语言的语法，并且写出了五种风格各异的 bug。只不过满足了部分中层管理老板的人员扩张野心。

语言和框架太多，对于公司来说显然是灾难。比如常见的公司组织架构调整，业务技术部门进行重组，不同部门的系统一般会进行暴力交接。这里说的“暴力”的意思是，不管你能不能接得下来，反正我是给你了。之后的维护也别来找我，甚至连简单的问答可能原部门都不一定愿意做。虽然公司对程序员的要求是可以随意地在不同语言技术栈之间切换，但程序员一般都有自己执著的美学偏好。让 java 程序员写 Go，往往是会翻车的。大多数 java 程序员在语言内的生态足够好，能满足几乎所有需求时，没有任何意愿去学习一门新语言。这是天然的抗拒心理，可以理解。我们这里已经有无数的案例表明，java 程序员转 Go，在写不满三个月的时间内就会离职 2333。就算不说 java，国内的 php 专家们也是不愿意写 Go 的，那些 PHP 大佬们哪怕在 swoole 之类的框架中重新实现一套 goroutine，也不愿意直接去写更原生的 Go 语言，因为用别人的东西体现不出轮子哥的价值啊。

对于一个公司来说，不应该听信那些微服务布道师的谎言，任由公司内的技术栈随意分裂。最终在公司调整或者变化的时刻才发现积重难返。在这一点上，我一直很羡慕国内的 b 站。他们很早地就把技术栈进行了统一。而其它那些几千甚至上万研发的“大公司”，大多都没有做到这一点。

原文 http://xargin.com/disaster-of-microservice-techstack/

正文到此结束