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

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

能性方面有深入的了解,这就对开发人员提出了更高的要求.
因此,有经验的开发团队可能更容易获取使用微服务开发带来的效益,而缺乏技能和经验的团队更建议使
[4]
用传统的单体架构进行开发 .在将一个商用系统使用微服务架构进行重构的过程中,Armin Balalaie 等人 [34] 发
现,公司需要向新手开发员讲解有关微服务的概念和技术,这浪费了大量的时间但效果并不理想.因此他们认
为,公司需要由技能熟练且具有开发微服务经验的人来组建团队.
解决方案:当时间充裕时,对那些新手开发人员进行培养,让他们对微服务的概念有一定的了解以及掌握那
些为了完成开发所需的工具和库 [34] ;而当时间有限时,由那些在微服务的开发中有着丰富经验且技能娴熟的开
发人员组建开发团队将更有成效;微服务宣传的技术异构性具有很强的迷惑性,多种技术和工具可供选择似乎
是一个不错的优势,但是掌握这些技术将给开发人员带来很大的压力,公司应该对不同的微服务开发做出不同
的技术选择标准.
3.1.6 DevOps
DevOps 由 Development(开发)和 Operations(运维)组合而成,它是一组实践,其目的是打破开发人员和运维
人员之间的壁垒,在保证软件质量的前提下,尽可能减少修改系统和将系统修改部署到生产环境中的时间.持续
交付(continuous delivery)和持续监控(continuous monitoring)等任何能实现上述目标的技术都被认为是 DevOps
实践 [34,35] .
微服务架构与 DevOps 是相辅相成的.尽管在单体架构中,DevOps 也可以进行应用,但微服务所提倡的小型
团队,使得 DevOps 的实施更加有效.同时,每个微服务可能都拥有一个单独的后端,这些单独的后端由不同的团
队使用不同的技术开发,如果没有 DevOps,由此产生的复杂性会变得难以管理.
3.1.7 通 信
通信可以分为同步通信(会议、视频、电话等)和异步通信(邮件、短信等)两种,团队中良好的通信可以提
高软件过程的质量 [36,37] .当团队中有 M 个人时,需要建立 M(M−1)/2 条通信路径,例如 2 个人仅需建立 1 条、5
个人建立 10 条、10 个人则需要建立 45 条(如图 5 所示).这代表团队成员越多,通信开销和管理开销就越多.正
如 Richard Hackman 所说,大型团队通常只会浪费每个人的时间 [38] .而微服务所提倡的小团队恰恰降低了通信
开销,使团队更容易保持凝聚力.

Fig.5 M personal communication paths
图 5 M 个人时的通信路径

Chen [30] 在为博彩公司 Paddy Power 使用微服务架构实现 DevOps 和持续交付时发现:客户现在可以直接与
负责相关微服务的团队中的人进行通信,而不需要再找微服务系统的负责人.这有助于开发人员做出更快的响
应,从而缩短开发周期.因此,一些研究人员认为,微服务对组织的通信带来了优势.
然而,有些研究人员认为,使用微服务架构给通信带来了挑战 [13,39] .文献中关于微服务中通信问题的讨论存
在差异的原因在于侧重点不同:在一个独立的微服务开发团队内部,开发人员之间的通信开销减少;而在不同的