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

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

但在实际应用中,大量技术和工具的使用将给开发带来挑战,数量会变得难以控制,从而使整个项目变得难
[6]
以管理 .特别是在有成员变动的团队,没有代码注释或是技术说明性文档,太多技术的使用可能会降低微服务
的可维护性和可扩展性.
因此,公司支持开发团队自由选择技术,同时也需要有一定的控制.开发不同的微服务所需的技术或工具可
能并不相同,公司应该根据不同的情况制定不同的标准 [29] .制定标准时需要注意的是:一味追求新技术或是执着
于使用过时的技术,都可能会降低使用微服务架构进行开发的有效性.另外,当一个团队在开发时想要使用一个
新的技术堆栈时,必须经过一个评审过程,以确定新技术带来的收益超过引入新的技术堆栈带来的操作开销 [30] .
3.1.4 组织文化
文化问题如果没有被很好地处理,那么使用微服务所预期的收益可能永远也无法达成 [31] .Thomas Jardinet
也指出:企业迁移向微服务真正的僵局是文化方面,组织和开发人员可能会抵触这种变革,因为他们无法接受微
[1]
服务 [28] .例如,在 Fritzsch Jonas 等人 的研究中有这样一个案例:一家软件服务公司正在尝试使用微服务架构为
汽车客户现代化一个非常大的配置管理系统,这就需要原本的开发团队经历从瀑布式到敏捷式的开发思维转
变.这会让一些开发人员难以接受,因为他们意识到之前开发的系统和取得的成就已经过时,而能否在微服务开
发中找到自己在团队中的定位,使他们陷入担忧.让团队中的所有人能够接受微服务,这是很困难的事情,也是
[1]
必须被妥善解决的问题 .
团队合作中需要异议和讨论,因为在团队进行讨论时很容易被群体思维(群体思维是社会心理学家 Irving
L.Janis 提出的一种心理现象)所压倒,即,为了与别人达成共识而放弃表达自己的意见.微服务开发团队需要创
造一个让异议和讨论自然而然产生的环境,让团队成员在不同解决方案的讨论中获取最佳的解决方案.组织成
员间的信任也是组织文化的组成部分,需要相信其他开发人员能够开发出可靠有效的微服务 [31] .
公司可以通过 Westrum 文化模型(Westrum cultural model)的使用来对团队文化是否健康进行评估,
Westrum 文化模型如图 4 所示.Westrum 文化模型不是专门为微服务设计的,但使用微服务架构的公司可以使用
这种模型来了解公司的文化状态,评估组织文化是否健康.Westrum 文化模型把公司的文化氛围分为 3 种:病态
型(pathological)、官僚型(bureaucratic)和生成型(generative).病态型的文化特征是团队中存在着大量威胁和恐
惧,团队间的低效合作和消极文化可能会造成人员流失.官僚型的文化中,人们倾向于维持等级制度,团队中充
斥着规则,成员很少关心组织的总任务.生成型的文化中成员间具有高度的合作和信任,他们关注的重点是团队
的任务,而不是自己 [32] .

Fig.4 Westrum culture model
图 4 Westrum 文化模型
3.1.5 开发人员
正如 Elger Peter 等人 [33] 所说:跨功能实施团队的技能,将在很大程度上决定微服务架构的有效性.当开发人
员缺乏使用微服务的开发经验,或者甚至不了解微服务架构的基本概念时,他们仍会使用之前开发单体架构的
思想去迎接微服务.由这样的开发人员组建的团队将十分危险,因为分布式系统开发(distributed system
development)的大泥潭将让开发人员寸步难行.同时,微服务还要求开发人员对系统容错、安全性和延迟等非功