漫画 | 只敢私下吐槽，不敢拿上台面，这才是微服务的灾难！

公司的高层对这个通用语言用得很好

到了编程的阶段，需要转化成代码，要用英文来表达了。

从中文到英文的转换，往往丢失一部分业务信息，产生一部分信息噪音，或者发生概念上的偏移。

很快， 在不同的系统，甚至同一个系统中，针对同一个业务概念存在三种以上不同的词汇。

模块间负责人探讨新功能的实现时，两边的沟通变得驴头不对马嘴

所以当你接手到这样的系统时，读代码的时候肯定是会骂娘的，但是读完之后也确实没有什么办法。

只要你负责维护，就持续地接受这种痛苦吧。

一个公司业务由多种语言实现，理论上可以吸引各种人才， 也会提供一个互相掐架的竞技场

实际上，在现行的微服务架构下，除了业务本身的研发人力投入之外，支持系统也有很大的工作量

如果每个服务都是一种技术栈，好家伙，一个轮子得造五遍。

对研发来说，可能也就是熟悉了五种语言的语法，并且写出了五种风格各异的 bug。

虽然公司对程序员的要求是可以随意地在不同语言技术栈之间切换，但程序员一般都有自己执著的美学偏好。

三个月后，张大胖离职了。

对于一个公司来说，不应该听信那些微服务布道师的胡言，任由公司内的技术栈随意分裂，最终在公司调整或者变化的时刻才发现积重难返。

该怎么把业务拆分成微服务呢？目前业界的微服务方法论一般也没有固定的套路。

在大企业中，顶着“架构师”头衔的这些架构师们根本就不会管任何实现上的细节。

相对较大的业务需求，一般也是一线的开发商量怎么进行实现上的拆分。想要达到合适的职责划分，需要多个合作方的所有人都靠谱才行。

于是，总会有些奇葩出现。

除了这些无法沟通的程序员，还有些奇葩的领导。

这样造成的结果是，所有逻辑的分布都具有不确定性，即薛定谔逻辑。

在你把所有模块的代码都看过之前，你是没法确定哪部分逻辑在哪个模块里的。

当模块发生负责人离职或者工作交接时，所有的开发都会进入非常痛苦的阶段，我只看自己的模块，根本没法理清全局的业务逻辑！

既然术语不统一，逻辑四处分散，难道不能重构一下吗？

在单体时代，重构有一套完整的方法论和最佳实践。

但演化到微服务的时代，原来很简单的重构就没那么简单了， 因为原本在代码中的强联系变成了分布式系统中的弱联系

当然，想重构也是可能的， 各个模块需要协调一致才可以，并且代价极为昂贵。

如果涉及到办公室政治，想重构就更难了！

重组是不可能重组的，最终的结果是，本来是一个人两天的活，生生堆了4个人，干了2个星期。

（完）

本漫画授权改编自公众号“TechPaper”