所以..。该架构最近被置于参考架构师的统治之下。参考架构师,我将他称为RA,开始工作,结果立即可见:我们停止调用微服务微服务,但阻塞。
由于我们以前是Java/Linux和C#/.net商店的混合体,所以在RA发布命令不再在Java和Linux上进行开发之前,一切都进行得很顺利。我们试着解释在使用微服务时(哎哟.)实现堆栈也不是很相关,多个堆栈为我们提供了更多的机会,因为有发展的空间,而且Linux堆栈的成本在云端通常较低,RA发送了一份停止和停止备忘录,敦促我们去他最喜欢的供应商那里。
除了可以调用的与成本和质量相关的明显参数之外,还可以使用其他的参数,这样我们就可以为保留代码提供一个理由。还有很多遗留问题,将其移植到一个新的平台不会带来任何业务价值,而是质量的下降和巨大的延迟。
到目前为止所使用的论点是
我遗漏了什么,才能对单个堆栈提出令人信服的理由?在微服务体系结构中,架构师不应该更多地关注交付价值、拥有清晰的接口和机制而不是具体的实现吗?由于功能和非功能的原因,微服务可以独立进化并选择自己的堆栈,迫使每个人都服从会导致退化和脆性。当然,单栈似乎更经济,并承诺代码重用,但据我所知,业务域在这两个世界中是相当不同的,所以无论如何重用将是困难的。
发布于 2020-09-18 04:54:26
这里有两种对立的力量--代码基础质量和合理性(无论是在可用技术方面,还是在时间和金钱方面)。在可维护性和可重用性方面,维护同构代码库可以提供更高的通用代码库质量。然而,使用多种技术更现实,这一点在您的问题中已经提到过了。我想说,这不是对错问题,而是平衡问题。
我在现实中看到的是,无论您多么努力地保持所有代码的同质性,当一个项目增长时,总会有一些与外部系统的集成引入一种新技术(针对Ex )。国家医疗保险,或远程200000记录制药数据库)或需要使用一些外来的图书馆(一些视频处理模块,只有一个有效的实现纯C)。
还有一个我很看重的原则--如果它有效的话,不要把它的代码搞砸了。微服务体系结构很好地服务了这一原则,因为它引入了分离部分的隔离,并使经过验证的服务能够只做他们的工作,从而使开发人员能够专注于新特性。
最后一个想法--在真实的商业环境中,每一行代码都会耗费资本,改变策略和重写代码必须有强烈的动机。决策的方向从需要到执行,这意味着必须有一个非常明确的需要得到满足(对于Ex )。有一个bug是至关重要的,破坏了核心用户体验),并且必须有一个非常清晰的理由来重写现有的代码(该bug与意大利面代码有关,如果不引入新的bug就无法修复,因此意大利面代码必须被截取,并替换为更好的代码),以激励重写决策。代码完美主义并不是一个好的动机,因为它违背了这个方向。
我相信“平衡”一词是关键。您的新架构师打破了成本和代码基础质量之间的平衡,这正是困扰您的问题。
https://softwareengineering.stackexchange.com/questions/415998
复制相似问题