漫画 | 只敢私下吐槽,不敢拿上台面,这才是微服务的灾难!
Posted 码农翻身
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了漫画 | 只敢私下吐槽,不敢拿上台面,这才是微服务的灾难!相关的知识,希望对你有一定的参考价值。
公司的高层对这个通用语言用得很好
到了编程的阶段,需要转化成代码,要用英文来表达了。
从中文到英文的转换,往往丢失一部分业务信息,产生一部分信息噪音,或者发生概念上的偏移。
很快, 在不同的系统,甚至同一个系统中,针对同一个业务概念存在三种以上不同的词汇。
模块间负责人探讨新功能的实现时,两边的沟通变得驴头不对马嘴
所以当你接手到这样的系统时,读代码的时候肯定是会骂娘的,但是读完之后也确实没有什么办法。
只要你负责维护,就持续地接受这种痛苦吧。
一个公司业务由多种语言实现,理论上可以吸引各种人才, 也会提供一个互相掐架的竞技场
实际上,在现行的微服务架构下,除了业务本身的研发人力投入之外,支持系统也有很大的工作量
如果每个服务都是一种技术栈,好家伙,一个轮子得造五遍。
对研发来说,可能也就是熟悉了五种语言的语法,并且写出了五种风格各异的 bug。
虽然公司对程序员的要求是可以随意地在不同语言技术栈之间切换,但程序员一般都有自己执著的美学偏好。
三个月后,张大胖离职了。
对于一个公司来说,不应该听信那些微服务布道师的胡言,任由公司内的技术栈随意分裂,最终在公司调整或者变化的时刻才发现积重难返。
该怎么把业务拆分成微服务呢?目前业界的微服务方法论一般也没有固定的套路。
在大企业中,顶着“架构师”头衔的这些架构师们根本就不会管任何实现上的细节。
相对较大的业务需求,一般也是一线的开发商量怎么进行实现上的拆分。想要达到合适的职责划分,需要多个合作方的所有人都靠谱才行。
于是,总会有些奇葩出现。
除了这些无法沟通的程序员,还有些奇葩的领导。
这样造成的结果是,所有逻辑的分布都具有不确定性,即薛定谔逻辑。
在你把所有模块的代码都看过之前,你是没法确定哪部分逻辑在哪个模块里的。
当模块发生负责人离职或者工作交接时,所有的开发都会进入非常痛苦的阶段,我只看自己的模块,根本没法理清全局的业务逻辑!
既然术语不统一,逻辑四处分散,难道不能重构一下吗?
在单体时代,重构有一套完整的方法论和最佳实践。
但演化到微服务的时代,原来很简单的重构就没那么简单了, 因为原本在代码中的强联系变成了分布式系统中的弱联系
当然,想重构也是可能的, 各个模块需要协调一致才可以,并且代价极为昂贵。
如果涉及到办公室政治,想重构就更难了!
重组是不可能重组的,最终的结果是,本来是一个人两天的活,生生堆了4个人,干了2个星期。
(完)
本漫画授权改编自公众号“TechPaper”
以上是关于漫画 | 只敢私下吐槽,不敢拿上台面,这才是微服务的灾难!的主要内容,如果未能解决你的问题,请参考以下文章