Page 39 - 《软件学报》2021年第5期

崔海涛 等:面向微服务架构的开发组织适应性评估框架 1263

用类比的形式,以将一项研究的主题翻译成其他研究中的术语(隐喻).相互翻译需要选取研究的关注点足够相
似 [23] .而在本文中,32 篇相关研究虽然都在讨论使用微服务架构对于组织的影响,但每项研究的关注点有很大
差异,例如 S18 中只讨论了自治团队,而 S7 涵盖了所有的 7 个方面,这使得相互翻译很难进行.
反驳综合是当一些研究与其他研究中的解释相互反驳,而对相互反驳的两种解释的关系进行考虑.尽管本
文中有一些研究存在着对某方面解释相反的情况,例如,在 S1,S7,S17,S21,S22 中认为微服务给组织通信带来了
优势,而在 S2,S8,S10,S25 中认为通信是组织需要解决的挑战,但根据系统文献综述结果的讨论,意见产生分歧
的原因在于不同研究的关注点(如 S1 的关注点在团队内部通信,而 S33 的关注点在于不同团队之间的通信)不
同,这不能被表述成解释相互反驳.因此,反驳综合也并不适合本文.
而论据线综合是通过综合和解释研究中的一阶和二阶解释来形成新的模式、理解等,这与本文的研究目的
匹配.因此,本文选用论据线综合对不同研究进行翻译.
C) 综合翻译
前两步的工作已经得到了每项研究中有关 7 个概念的描述和二阶解释,据此形成了一条论据线,见表 3(前
两列).根据论据线,最终得出了 4 种三阶解释,其中,前 3 种三阶解释仍然接近于论据线,第 4 种三阶解释是根据
前 3 种三阶解释导出的.
Table 3 Synthesizing translations
表 3 综合翻译
概念 二阶解释 三阶解释
组织结构:组织结构 (S1) “探讨有效的微服务文化中的关键因素,包括组织规模、
需要改变;组织规模, 动机、关系以及它们如何影响微服务的发展和目标”
关系;团队数量增加; (S2) 与单体系统相比,微服务开发需要较少的团队间通信
架构与组织结构 (S3) 使用微服务架构可以增加团队自治性 (1) 尽管每种开发
缺乏一致性; (S4) 与其他架构相比,没有经验的团队成员 范式都强调组织
组织如何演变 在开始使用微服务时需要较少的工作 文化、通信和开发
人员的技能和
(S5) DevOps和微服务之间的协作将有助于
自治团队:高度自主权; 消除开发和运营团队之间的障碍 经验,但在微服务
高度责任感;无须等待 (S6) 总结了19个在微服务中没有考虑到的因素,并表明, 架构中,这些概念
其他团队做出决定; 并不是所有类型的公司都能从微服务中获益 表现出新特点
自治,松散耦合;独立
部署;增加团队 (S7) 在DevOps和CD环境中,使用微服务可以带来很多优势
看不到全局的风险 (S8) 当软件公司足够大时,微服务是处理复杂性和规模的好方法
(S9) “致力于将微服务与可适应的企业体系结构集成”
技术/工具:异构技术 (S10) 微服务中的组织,工作方式,设计实践,模块化和任务分配
堆栈;技术选择的激增 (S11) 提出了9个常见的微服务陷阱及其可能的解决方案
可能很快变得难以 (S12) 开发和操作人员的技能被认为是主要障碍 (2) 每个概念并非
控制;避免技术锁定; 都独立存在,公司
自主选择工具;重用 (S13) “微服务架构还有很长的路要走, 需要在概念
和故障处理变得困难 在这个过程中,还存在许多挑战” 改变中进行权衡
组织文化:文化需要 (S14) 公司可以在使用微服务中从技术级获益,但需要在组织级进行调整 或是制定标准
变革;文化更加开放 (S15) 探索情景上下文对微服务开发的影响
和不受约束;需要 (S16) “调整原则、实践和文化的微服务体系结构”
组织信任;开发人员
对变革的抵触; (S17) “根据从业者在开发基于微服务的系统时所经历的
组织文化评估 不良实践确定了一组(20个)微服务反模式” (3) 微服务并非
(S18) 一个团队应该只拥有一个服务,这足以确保团队自治和松耦合 万能解,使用
开发人员:不知道 (S19) 组织结构需要改变,文化需要得到尊重但也必须进行变革
微服务是做什么; 微服务之前需要
缺乏微服务经验和 (S20) “如何使用微服务管理团队” 明确使用原因
技能;需要高技能的 (S21) “了解部署微服务的主要优势,以及采用 以及公司是否
开发人员;团队需要 基于微服务的产品所必需的公司文化” 做好充分准备
熟悉这些概念的成员 (S22) 介绍使用单体架构开发应用程序相关的
问题以及如何适应微服务架构