Page 46 - 《软件学报》2021年第5期
P. 46

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

                 微服务团队之间,由于微服务允许团队独立工作,团队之间的通信需求减少,这在短期可能会带来收益,但会在
                 项目的同步性问题上带来问题           [39] .因此,为了保证项目的整体同步性,可能需要在开发时在团队中加入技术协调
                 会议 (technical coordination  meeting)、依 赖协调会议 (dependency coordination  meeting)和执行概要会议
                                         [9]
                 (executive summary meeting)等 .
                    通信问题需要注意的点是:需要根据团队结构识别通信场景,以制定通信策略.Lenarduzzi 等人                          [39] 把通信分
                 为以下 3 种场景:并置团队(所有的团队在同一地点工作)、有重叠工作时间的分布式开发团队(不同的微服务团
                 队在不同的地址位置工作,但在工作日有一定的时间进行交流)和无重叠时间的分布式开发团队(在工作日无交
                 流),可以通过引入层次结构(即团队协调员)来解决通信问题(具体的通信策略可以参考 Valentina 等人                              [39] 的
                 工作).
                 3.2   开发组织适应性评估框架(回答RQ2)

                    这一部分将报告执行元-民族志的结果并进行讨论,即元-民族志的第 7 步(报告研究结果).基于微服务给组
                 织带来影响的系统文献综述的结果,本文从 32 项研究中找出了 7 个重复出现或是常见的概念:组织结构、自治
                 团队、技术/工具、组织文化、开发人员、DevOps 和通信.通过分析这 7 个概念的描述以及 32 项研究的主要
                 思想或理论,形成了一条论述线,并最终导出了 4 条三阶解释.分别为:(1)  尽管每种开发范式都强调组织文化、
                 通信和开发人员的技能和经验,但在微服务架构中,这些概念表现出新特点;(2)  每个概念并非都独立存在,公司
                 需要在概念改变中进行权衡或是制定标准;(3)  微服务并非万能解,使用微服务之前,需要明确使用原因以及公
                 司是否做好充分准备;(4)  公司想要获得微服务预期收益,必须创建适应该架构的开发组织,公司需要明确影响
                 组织适应微服务的因素和因素之间的关系并合理应对.其中,前 3 条三阶解释既与原始结果一致,又超越了原始
                 结果.第 4 条三阶解释是基于前 3 条三阶解释提出的,同时是为了回答本文所设置的研究问题二,即对于使用微
                 服务架构的公司,如何评估和改进组织对于微服务架构的适应性?本文将提出一个适应性评估框架,以帮助公司
                 判断其开发组织对于微服务架构的适应性,并讨论如何提高其适应性.接下来,首先对前 3 条三阶解释进行分析
                 和讨论,以帮助更好地形成框架.
                    (1)  尽管每种开发范式都强调组织文化、通信和开发人员的技能和经验,但在微服务架构中,这些概念表现
                 出新特点.
                    无论在敏捷过程还是极限编程等不同的软件过程中,还是使用单体架构开发软件时去创建团队,形成优秀
                 的组织文化、构建高度的通信以及寻找技能娴熟和经验丰富的开发人员都是被提倡的,所以对组织文化、通信
                 和开发人员的技能和经验的考虑并非是微服务专属.但我们必须明确这 3 个概念在微服务中表现出了哪些新
                 特点,这对组织适应微服务架构不可或缺.
                    微服务架构中的组织文化要求团队成员接受微服务,即开发人员现在需要打破使用单体架构进行开发时
                 的固定思维,了解微服务开发特性,从而明确自己在新的微服务开发中的角色;微服务中通信问题的特点在于客
                 户可以直接与相关微服务的开发人员沟通,这更有利于问题的解决,然而,分布式的微服务开发要求不同类型团
                 队找出与团队组成形式匹配的通信方式;在开发人员的技能和经验方面,虽然 Jonas Fritzsch 等人                         [40] 采访了 10
                 家采用微服务的公司的软件专家后发现,Restful HTTP、Docker container 和 Java 仍然是开发最常用的工具或技
                 术,但由于微服务技术异构性的特点,可能随时要求有新技术或工具的加入,这对开发人员提出了更高的要求.
                    因此在微服务中,对于组织文化、通信和开发人员的技能和经验的讨论是必需且独特的.
                    (2)  每个概念并非都独立存在,公司需要在概念改变中进行权衡或是制定标准.
                    本文通过系统文献综述找出了使用微服务架构对组织产生影响的 7 个概念,需要注意的是:就像一家公司
                 是一个有机的整体,这些不同概念也是一个整体,并非独立存在.公司需要在不同的概念改变中进行权衡或是制
                 定标准.例如,由于微服务给了团队高度的自治权,不同团队可以不必依赖于其他团队而独立地开发和交付,这
                 使每个微服务团队可以更专注于他们的开发任务.但团队之间的这种松散耦合导致了不同团队之间通信需求
                 的减少,缺乏通信可能会造成整个项目的不同步等问题.又比如,微服务开发需要与 DevOps 紧密结合,这给微服
                 务团队带来了持续交付和持续部署等能力,但是 DevOps 需要打破开发人员和运维人员之间的壁垒,运维人员、
   41   42   43   44   45   46   47   48   49   50   51