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

1258 Journal of Software 软件学报 Vol.32, No.5, May 2021

[2]
的编程语言开发微服务,也可以在最适合其需求的硬件上进行部署 .并且因为规模有限,所以微服务比单体架
构开发的软件有更高的可伸缩性(scalability)、可维护性(maintainability)和容错机制(fault tolerance mechanism).
因此,综合多种优点于一体的微服务架构在 2014 年被正式提出后,便获得广泛的关注且关注度逐年上升.但微
服务并不能作为所有软件系统开发的可行方案,由微服务带来的众多挑战也有待解决.
Conway 在其名为《How do committees invent》的文章中指出,一个系统的通信结构将直接影响该系统的
组织结构.这句话已经在实践中被多次证明是有效的.同时,人们发现微服务架构同样也符合 Conway 法则 [1,6] .
使用单体架构风格开发软件的组织不能直接开发微服务.因此,如果公司想使用微服务架构开发软件项目,则必
须对开发组织进行调整,以设计出与微服务架构相适应的开发组织.
[5]
Weinreich 等人 采访了 10 位微服务设计领域的专家,总结出了使用微服务时相关的设计领域以及领域的
重要性排序.他们的结果表明:在 15 个微服务相关的设计领域中,组织设计的重要性排在第 4.他们认为:如何横
切团队、明确团队需要处理的任务以及所有团队的集中管理,都是很大的挑战.
[7]
Di Francesco 等人 对工业中微服务的使用进行了实证研究(empirical research),他们将迁移到微服务过程
中遇到的挑战划分为技术挑战(technical challenge)和组织挑战(organizational challenge).与此同时,在对 18 位微
服务开发人员的采访中,他们发现:在向微服务迁移的过程中,组织的数量增加了(迁移初期平均 6.7 个,迁移完成
平均 8 个),但每个组织的成员数量持续减少(迁移初期平均 8.3 人,迁移完成平均 6.5 人).从这一趋势可以推断:
一方面,微服务更倾向于支持小型团队;另一方面,为了适应微服务,组织结构一直在发生变化.
[8]
Zhang 等人 在一项对 13 家不同类型的微服务公司进行的行业访谈中发现,研究中涉及的公司主要还是依
靠经验对组织进行转型.不恰当的组织转型,导致了组织结构与微服务架构的不匹配,这可能会导致开发组织之
间需要大量的沟通和开发效率低等问题.正如访谈中的一位参与者所说:“我们知道组织应该跟上架构的相应变
化,但我们缺乏如何做到这一点的指南.”这也是本文工作的研究动机之一,本文试图为开发组织在面向微服务
开发的过程中提供指导意见.
[9]
Halappa 等人 也意识到:当架构风格发生改变,组织也需要参与变更以与微服务架构相适应.他们提出了 4
点建议:(1) 暴露出你的团队面临的架构问题;(2) 教育他们使用微服务带来的优势;(3) 对微服务架构进行权
衡;(4) 让团队自己做决定.
虽然文章中提出的建议可能有助于组织提高对微服务架构的适应性,但建议所涵盖的点很不全面,且没有
任何相关的细节描述.
[6]
尽管大多数人都承认:想要获取使用微服务带来的预期优势,除解决技术挑战外,组织的挑战也必须解决 ,
但有关组织方面的研究并不广泛.并且,现有的有关微服务开发组织的研究中,也并没有一套全面的、能够帮助
评估开发组织对微服务适应性的指南性框架被提出.因此,为了协助使用微服务的公司能够跟上架构的变化,本
文专注于组织的角度,围绕微服务对组织产生的影响进行了系统且全面的总结,并提出了一个适应性评估框架
以帮助公司判断以及提高开发组织对微服务的适应性.同时希望通过本文的研究工作,激发更多的研究人员对
微服务开发组织方面的研究兴趣,改善微服务与开发组织匹配度,从而提高使用微服务的收益.

2 研究方法

本文中所用的研究方法包括系统文献综述、元-民族志、问卷调查以及行业访谈.研究过程分为 3 个步骤.
第 1 步,使用系统文献综述搜集所有与微服务开发组织相关的研究,并明确使用微服务给开发组织带来了
哪些影响(回答 RQ1).
第 2 步,基于元-民族志方法对相关研究和影响的描述进行定性数据合成,并结合系统文献综述的结果提出
开发组织适应性评估框架(回答 RQ2).
第 3 步,基于框架的内容设计问卷调查和行业访谈,以结合工业界的经验对框架的有效性进行验证.
本文的主要研究过程如图 1 所示.