ACM通信

贡献的文章

如何逐步过渡到微服务架构

卡洛莉·博赞、卡勒·莱蒂宁、格雷戈里·m·罗斯著
ACM通讯，2021年1月，第64卷第1期，79-85页
10.1145 / 3378064
评论

收益周期管理是一个复杂的过程，涉及多个步骤和大量的数据流。正在构建RCM应用程序的软件开发组织(SDO)很快就意识到这项任务的复杂性。具体来说，应用程序的圈复杂度为数千。SDO很难在不影响整个代码库的情况下扩展应用程序或添加特性。

回到顶部

关键的见解

在21世纪初，还没有明确的方法来克服这一挑战，直到SDO开始讨论如何通过将RCM步骤分离为更小的、独立的服务来简化系统。后来，这种想法被称为微服务体系结构(MSA)，它最近被吹捧为有前途的软件体系结构替代品。通常，体系结构风格表示一种合理的、可重用的解决方案模式，它由经验支持，针对一组已知的编程问题。¹⁰在给定其设计目标和约束的情况下，体系结构传达了一个高度抽象的软件结构和行为的概念模型。体系结构的选择对软件的实现方式以及如何组织其开发产生影响。明智选择的架构风格有助于减少技术债务，并提高软件效率和质量。⁹

通常，MSA解决方案建立在“编排”软件的思想之上，包括松散耦合和独立的“服务”。^13，18，22在MSA解决方案中，每个服务负责一个专用的、定义良好的和可伸缩的功能，该功能可能并且经常被期望同时服务于其他应用程序。信用卡处理、产品评级和结帐业务功能是电子商务中的微服务的例子。每个服务都是独立开发、测试和部署的，没有对服务的部署将如何影响其作为其他应用程序的一部分进行严格假设。在MSA下，一些服务是内部开发的，而其他服务是由第三方开发的，并通过服务编排通过api链接到最终的应用程序。从历史的角度来看，MSAs是软件社区开发和管理高度模块化、组织良好的软件资产的愿望的证明。^3.

在过去，软件主要是围绕紧密耦合的代码库构建的，这种代码库称为整体架构。这种风格主要将软件组织为模块化的单层，或者后来将其组织为水平隔离的n-层架构(Internet堆栈)。使用整体架构构建的软件在软件持续发展时(通常是在紧张的时间压力下)，会面临功能增长、可伸缩性或性能方面的重大挑战。²当新的需求出现或采用创新技术时，“遗留”代码通常无法支持此类更改的快速实现。

最近的技术进步创造了多功能的软件生态系统来开发和部署微服务。例如，Docker，一个容器平台，提供了一种操作系统级虚拟化的方法，将软件打包到Kubernetes精心策划的轻量级“容器”中。⁵越来越多的软件服务初创公司现在为容器部署、管理和安全性提供支持服务。这也允许小型sdo越来越多地部署以前为大型sdo(如Amazon)提供的软件资产。

然而，搬到MSA既不容易，也不没有风险。它需要一种战略性的、有纪律的方法，以避免对当前操作和软件用户体验的破坏。许多sdo仍不确定转型的好处，仍在观望。¹⁵发布的成功的过渡故事往往提供了毫无根据的、过于积极的主张，并给人一种脱钩将自动导致可伸缩性、灵活性和上市时间缩短的感觉。最广为人知的成功案例来自于大型的数字化运营公司，如亚马逊，而大多数考虑转型的sdo缺乏此类软件巨头的资源、技能和项目管理能力。因此，拥有遗留系统的公司需要仔细考虑完成转换的替代方案。

根据我们的实地研究，大多数具有重要软件资产的sdo选择增量策略来降低转换风险并确保平稳的转换。在增量式策略下，传统的整体软件和新的、模块化的基于msa的软件将在相当长的一段时间内同时出现。这需要对它们对软件资产、人员、组织和管理实践的共同影响有更深的认识。⁸SDO管理必须准备好在组织的多个级别上进行广泛的变更，同时评估好处和不可避免的风险的影响。接下来，我们确定了其中的一些变化和相关挑战，这些变化和挑战是在一个专注于在成功的MSA过渡期间的领先行业实践的实地研究中确定的。

回到顶部

研究设计

实地研究数据是在2018年2月至2019年6月期间收集的。该研究依赖于半结构化的访谈，这些访谈集中在架构转换期间的变更、挑战和机会，以及转换对SDO的软件资产管理及其软件过程和组织的影响。数据来自9个在不同形式和阶段经历了增量过渡的sdo。这些sdo规模各异，分布在6个行业。该研究包括对31位软件专家的23次访谈，这些专家的头衔包括CTO、全球总监、高级/主要架构师、应用架构师和首席开发人员。数据收集通过三个迭代回合进行。在第一轮中，我们试图理解新兴技术对软件开发的影响。在这一轮中，线人一致认为MSA是一个关键的建筑趋势。在第二轮中，我们试图确定引导架构风格和转换选择的动机和决策逻辑。在第三轮，我们试图确定和理解在操作共存的巨石和MSA架构和解决方案的关键挑战。 We also validated our study findings and conclusions among a subset of informants. The transition strategies and challenges discussed here were inductively derived from the transcripts. We coded data simultaneously with the data collection to ensure higher validity and reliability of emerging themes, guide follow-up interviews, and identify saturation in data and code. Further details of data collection and analysis as well as examples of coding trees are reported in Appendix A available online athttps://dl.acm.org/doi/10.1145/3378064．

回到顶部

增量转换

在增量架构转换过程中，微服务以零碎的方式引入，而软件资产则以迭代和先后的方式重新架构。表1提供了一个从我们的实地研究中得出的对MSA增量过渡的好处、风险和组织影响的总结。两种最常见的替代策略的优点和缺点——大爆炸和零替代，无过渡——在附录B中有报告，可以在网上找到https://dl.acm.org/doi/10.1145/3378064．在增量策略中，选择要重新构建的应用程序，以及微服务从整体代码库中分离出来的方式，主要取决于重新构建是否为业务提供了可识别的价值，并为应用程序用户提供了直接利益。业务需要驱动哪些服务将被隔离和独立开发。在增量策略下，最终目标不一定是完全解耦系统，除非它具有明确定义和可衡量的优势。总的来说，目标是持续平衡过渡风险²³预期利益。^1，7，12

表1。增量过渡到MSA。

增量过渡的四个阶段。通常，一个增量的过渡过程会经历四个阶段:确定过渡的目标;确定体系结构更改的范围和级别;做好资源准备;改变关键的开发实践。各阶段的区别如下:

• 不同的决策者谁发起并负责与阶段相关的变更类型;
• 不同的机制允许决策者在该阶段进行过渡;而且
• 不同的结果对于每一个阶段。

这些机制是被定义的组织能力，用于制定相关的决策或实现这些决策。当开发软件资产时，sdo将在做出和执行关于转换方向的决策时部署这样的机制。伴随数字提供分离阶段的原则和它们之间的逻辑依赖关系的摘要。图中自顶向下的箭头说明了随着增量转换在各个阶段的移动，其粒度越来越大的焦点。最初，领导层必须建立一些机制，以帮助确定SDO的战略目标和当前软件开发实践与SDO战略目标相一致的程度之间的差距。这些机制有助于确定在管理协定过渡期间必须克服的限制和需要利用的机会。在增量转换中，帮助实现目标的策略通常涉及可伸缩的应用程序、增强的应用程序灵活性和改进的上市速度。根据确定的差距，SDO领导层需要为增量转换建立特定的战略目标。

数字增量过渡过程阶段。

在下一阶段，需要建立一些机制，以确定选择的一组应用程序和相关服务作为解耦目标。这决定了体系结构选择指南的范围，以及提议的服务分割的潜在影响。只有知识渊博的软件架构师才能评估这种影响。在下一阶段，项目经理需要重新组织软件团队来执行拆分。这就需要建立新的角色和职责来正确地开发、部署和维护微服务。这里的机制涉及到重组团队和执行相关组织变革的知识和技能。在最后阶段，软件开发人员必须学习并过渡到新的开发实践，而软件经理将获得管理服务供应商关系的新职责。这里的机制旨在改变本地软件开发原则，并提供了改变项目管理实践和相关开发指南的方法，从而产生新的软件开发实践，如DevOps。^3.，9

自底向上的箭头描述了每个阶段的预期影响，也就是基于学习的反馈循环。例如，开发实践中的变化很可能对团队及其技能和行为产生影响。适当的团队结构将推动可行的服务分离，而每个分离步骤都需要根据既定的目标进行检查，以确保分离将带来业务价值。

了解所有四个阶段在过渡结果方面的作用和影响是管理支助事务成功过渡的一个重要前提。分阶段活动和相关的角色变更帮助sdo逐步准备并有效地管理增量转换。特别是，如果每个阶段都得到了适当的计划和管理，并且在进入下一个阶段之前处理了相关的任务，那么这个过渡很可能会更成功地平衡风险和收益。每个阶段涉及多个临界活动．表2提供关键活动和方面的摘要以及它们对组织的影响。

表2。增量的过渡阶段、活动、关键方面和组织影响。

1. 确定战略目标．SDO必须识别出由于软件资产和相关组织功能中的错误而导致目前没有得到适当满足的显著战略目标。了解MSA过渡的准备情况和紧迫性对于成功过渡(或“燃烧平台”)至关重要。SDO管理人员应该通过询问更改软件资产体系结构的有效业务原因来引导转换。通常，这些目标与软件速度、可伸缩性或灵活性有关。¹⁷只有这样定义良好的战略目标才能保证进行转换，并要求SDO执行以下活动:

• 确认转型的战略目标．成功的sdo通常为MSA过渡建立定义良好的和可测量的目标。这些目标指导决策制定和实现它们的组织和技术变化的实施。^11，16例如，一个SDO建立了一个战略目标，即通过更及时地响应新需求，为客户提供创新的解决方案。这个目标成为MSA转换的关键驱动因素，这涉及到将高度嵌入和依赖的服务从代码库中分离出来，以获得更好的响应性和灵活性。为此，SDO优先考虑模块化微服务的开发，以支持关键业务功能，从而支持实验性开发和创新。
• 确定SDO操作和资产中的痛点．遗留系统的特性和阻碍战略目标实现的相关实践需要被识别。正如一位高管所说:“我总是问他们为什么要使用微服务。他们打算通过转向微服务架构来解决什么问题?”例如，如果战略目标是增加解决方案的创新性和改善客户体验，那么就必须确定阻碍实现这一目标的瓶颈。由于依赖关系，紧密耦合服务的更改非常耗时，并且需要复杂而缓慢的测试安排。解耦这些服务使测试更简单，代码更改更快，更容易监控性能和用户行为。
• 将微服务映射到痛点．必须将一组服务标识为造成瓶颈的原因。通过实现微服务而不是整体扩展，新服务应该有助于实现确定的目标。考虑一个类似于Uber的叫车服务，通过使用GPS坐标来提供接送服务，而服务的价格是由动态的供需信息决定的。运行这种服务所需的数据将具有很大的容量，因为应用程序必须能够快速地比较供求的历史数据，并将其与适用的客户特征结合起来，以当场确定价格。如此大量的数据处理，虽然使用的是一个整体，可能会很容易地在提供这样的服务时，对哪些类型的定价结果可以实时提供明显的限制。因此，使用Apache的Kafka Stream应用程序作为微服务来处理数据将成为一个有吸引力的替代微服务解决方案，可以更好地满足系统需求。

1. 确定体系结构变化．第二阶段帮助技术领导参与到与所需架构变更范围相关的关键技术决策中。这种变化是通过建立对技术范围和转换风险的清晰理解而发生的。需要识别要隔离的服务，并说明它们的依赖关系。这有助于SDO对转换进行适当的初始范围确定。在这个阶段，重要的是不仅要评估新的微服务给软件管理增加的复杂性，而且要确定那些不应该被分离的部分，因为好处将是边际的或风险将超过它们。在架构变更阶段进行以下活动:

• 评估微服务的复杂性．技术领导需要确定要拆分的服务并就其达成一致，并对分离时间表进行优先级划分。这需要详细评估每次拆分给应用程序带来的复杂性。理解和减轻可能的风险、组织对此类风险的容忍度，以及预期的收益是需要考虑的重要因素。例如，微服务之间的消息传递将迅速变得复杂，并容易出错。如果在开发和集成服务之前代码冻结是必要的，则需要通知客户这是否是预期的，以及报告的增强是否会延迟。
• 服务分割规则/决定．要解耦的服务顺序应该由服务特征和相关业务价值决定。在面向客户的服务中，如果独立部署服务，快速开发和部署可以很快实现业务价值。要拆分的服务应该足够大，并根据需要进一步拆分，以避免不必要的复杂性。领导必须了解适当范围的价值，并避免创建“minimonoliths”，这通常是由定义不佳的跨界服务导致的。一种常见的方法是在单个开发工作中拆分两到三个服务，并将其他所有内容留在整体的核心中。然而，拆分规则并不总是由业务逻辑驱动。它们还受到数据库设计和数据依赖关系的固有约束的影响。正如一位受访者所说的那样，“代码实际上并没有那么难拆分;几乎总是很难把数据分开，因为你必须知道哪些服务拥有哪些数据。”

当一个微服务已经确定要分离时，要么以独立的方式在内部构建它，要么寻找第三方服务提供商是一个可行的选择。例如，如果将产品评级服务添加到商业销售站点，则可以在内部开发该服务。或者，第三方可以提供经过充分测试的、功能增强的产品评级服务，随时可以部署。在这种情况下，在做出任何最终决定之前，了解和预测未来的维护、定制选项和数据所有权的后果是很重要的。

• 包含巨石核心．应用程序的主要业务逻辑不太可能随时间发生显著变化。因此，将其完全分解为服务通常是低效且不必要的，尤其是在不存在与伸缩性相关的瓶颈的情况下。所有已识别的服务都需要与剩余的核心和数据进行相应的共享。一位微服务开发人员这样描述保持核心的重要性:“您将始终必须处理庞然大物和遗留系统的一部分，但您不会添加到庞然大物上。”

1. 推进资源准备．确定的体系结构范围将推动此阶段渗透到整个组织的程度。如果实现团队在MSA转换方面缺乏经验，那么服务分离的顺序应该从任务重要性较低的顺序开始。例如，与结帐或支付功能相比，电子商务应用程序中的产品评级服务是一个合理的选择。第一个服务隔离需要作为一个展示项目来处理，以展示业务利益并获得组织的支持。因此，适当地集结和管理团队对于过渡的长期成功至关重要。体系结构更改阶段有助于确定负责开发这些第一个服务的团队的适当组合需求。这个阶段的活动集中在建立机制，磨练个人的技能，使成功的团队形成，如下所述:

• 重组团队．软件开发团队的组织通常反映了Conway定律中表达的模块化软件组织:⁶设计软件的组织将产生一个在结构上代表该组织当前劳动分工的软件组织。向MSA的转变试图打破目前的软件组织，因此，有必要以不同的方式划分软件团队，以产生组织中的新结构。开发人员需要重组成更小的、独立的、以服务为中心的单元，它们的依赖性更小，通信结构更窄。¹⁴新组织需要将关键的、独立的、多应用程序服务隔离在其自主开发单元内。新的团队结构给维护遗留系统带来了压力，当部分软件功能被拆分为新的负责任的DevOps团队的自治服务时，当前的社会组织如何运作。如果组织没有实施这种激进重组的重要经验，最好从一个负责非关键服务的服务团队开始，以了解如何管理和组织这样的团队。
• 确定并培训关键开发人员．另一个挑战是确定真正支持MSA理念并愿意接受培训和学习的团队成员。开发人员必须学习新的技能，并且在将未经尝试的技术集成到技术组合中时，需要继续致力于实现变更。那些拥有良好的业务领域知识(特别是要解耦的服务)和天生学习技术技能的人是最佳人选。应该完全取消被选中的候选人的单一相关职责，以创建一个完全有能力的团队，该团队可以有效地分离、开发、部署和作为一个独立单位维护服务。因为这两种架构风格将共存，所以重要的是要理解所有剩余的开发人员都不会对学习新技能感兴趣。这些开发人员应该被分配来维护遗留代码。在某些情况下，如果所有开发人员都对微服务感兴趣，选择在开发人员角色之间轮换是可取的，以防止团队成员之间出现问题。

获得关键的MSA设计和实现技能，如持续交付，代表着从过去的根本改变。必须进行DevOps技能和相关代码管理的培训。通常会邀请外部顾问来指导开发人员顺利地执行第一次拆分，并管理代码变更。培训应涵盖与参与过渡工作的外部服务提供者建立关系的技能。开发人员应该参加专业的会议，以建立开发人员的关键知识库，并创建学习网络。

• 转换角色和职责．大型sdo通常使用成熟的咨询公司进行内部人才开发。较小的sdo鼓励以自我为基础的、有节奏的学习，但会聘请外部顾问来领导解耦代码和吸收所选技术的初始过程。新环境中的一些基础设施和测试支持角色将不那么受欢迎，因为开发和操作现在主要在云中运行和管理。转换团队需要包括来自业务操作的成员，以便业务端理解为什么会发生这些更改。这对于创建成功的DevOps实践也是必要的^3.这使得自主开发团队不仅处于开发服务的最前沿，而且处于以更高速度测试和部署服务的最前沿。²³
• 获得支持．初始服务拆分的成功将为架构转换创造动力，并有助于获得开发人员和业务部门的支持。MSA转换通常会引起SDO内部的更改，以支持创建负责特定微服务的模块化和独立的操作单元。因为MSA假设有更多的软件组件需要开发、测试、部署和管理，所以在组建团队之前需要引入DevOps实践。这为建立适当的基础设施和文档提供了时间，并开发适当的度量标准来衡量MSA过渡结果。¹⁰

1. 改变软件开发实践．这个阶段的重点是改变关键的开发机制和技术，目标是找到适当的技术来实施选定的微服务。这个阶段还为质量保证建立标准，并为组织更复杂的服务供应商管理做好准备。主要活动包括:

• 支持混合架构．虽然支持MSA解决方案的团队和整体核心将被相对有限的和定义良好的接口分开，但是他们需要理解他们的工作对彼此的影响。明确的服务职责将保证更快地识别和解决故障。有了隔离的服务，对敏捷性的需求将发生重大变化。管理层需要在项目管理方法中引入相关的更改，以适当地包含与核心和微服务开发相关的一系列活动。他们必须运行敏捷的DevOps团队，以便在微服务开发中更加积极主动。整体应用程序受益于稳定性，并需要更具有预测性的长期支持和相关实践。
• 建立适当的程序来寻找合适的技术．开发微服务使团队能够更灵活地为他们负责的服务选择“适合”的技术。然而，所选择的技术需要在更高的层次上进行正式的评估，以确保它们的使用符合组织的整体需求。通过这种方式，sdo可以更好地控制各种技术的扩散和部署，并减轻日益增长的异质性、糟糕的选择和成本上升的风险。如果所选技术被证明不适合服务，那么如果使用了适当的微服务规范，就可以相对容易地替换它。在这方面，一位微服务开发者表示:“我们构建这个流程的方式是，如果我们发现一项新技术不可行，我们可以放弃它。”大多数sdo鼓励试验，早期失败被视为流程的一部分，这最终会促进创新的服务开发。
• 管理供应商．微服务的开发和部署所必需的云平台在MSA生态系统中引入了无数潜在的新供应商。协调服务部署、管理契约和遵从性，以及理解和减轻相关风险成为重要的新挑战。在开始转换之前，SDO管理需要准备并考虑供应商问题。
• 建立最低的软件质量．不同技术的扩散具有优势，因为它有助于寻找最佳解决方案，特别是在实现挑战。然而，这种多样性需要与对质量的要求和最小化错误的需要相匹配。在这个新环境中，建立质量标准并在部署的技术之间始终如一地交付高质量的产品仍然是重大的挑战。一位开发人员说:“我们用不同的语言编写了所有这些不同的微服务，在部署期间给我们带来了不同的挑战……当团队部署它们时，有些会比其他的bug更多。”
• 监测用户行为．要实时了解与编排好的应用程序之间的用户交互，需要对大量用户流数据进行持续的检测、监视和分析。在MSA环境中，数据科学家在理解客户需求和确定服务增强方面通常与业务分析师一样重要。
• 建立通信结构．由于存在大量未计算的依赖关系，因此在所有相关的开发人员之间经常需要进行通信。微服务应该减少通信开销，因为它们主要依赖于通过接口规范建立的窄带异步通信。然而，SDO管理需要允许跨团队的开发人员之间进行“足够”的交互，以避免构建“迷你巨石”中显示的附加依赖项。共同办公的团队认为这是一个巨大的挑战，一位分析师表示:“我认为，当你拥有一个共同办公的专注的产品团队，而不是分布式的团队时，保持每个微服务的壁垒无疑更具挑战性。我认为分布式团队会迫使你更好地保持这些服务的解耦。”

回到顶部

结论

MSA不是一颗银弹。它不能解决管理软件资产的所有持久问题。例如，解耦巨石和隔离关键的微服务并不能解决设计有缺陷的系统或编写低质量代码所产生的问题。但是，如果在现实的和可度量的目标的指导下，并且SDO意识到转换对整个组织的级联影响，增量转换可以实现从软件资产派生的更好的业务价值。

SDO必须有充分的理由进行MSA转换。如果可以为MSA转换建立一个现实的战略目标，那么SDO需要准备和构建它所能建立的机制，做出适当的必要决策，并适当地实现它们。过渡策略应该是渐进的，除非组织有大量的资源和深厚的软件经验，或者由于重大的操作失败或其他业务原因，将需要进行完整的过渡。

SDO需要说明服务隔离的清晰、可度量的好处，这些好处大于相关的风险和更高的组织复杂性。SDO不应该在不了解服务对更灵活的开发、可伸缩的应用程序或提高上市时间的好处的情况下对服务进行解耦。SDO还必须建立具有良好基础的标准化拆分规则的严格技术规程。它应该根据业务需求确定的既定优先级，迭代地执行服务分割。

在MSA转型中成功的关键是理解和处理组织中较软的社会弱点。MSA从根本上讲是关于SDO的结构、思想和心灵的深刻变化，这是由新的技术机遇引发的。它以整体和间断的方式塑造组织，随着时间的推移，在组织现状的深刻变革中，其结构、角色、责任、技能、激励和惯例都受到影响。SDO管理人员不应该期望这些现有的和根深蒂固的结构自动或通过命令适应MSA。SDO需要为持续的变更做好准备，并学会以有纪律的方式调整组织以适应新的体系结构制度。糟糕的执行将导致员工困惑和沮丧，不适合的应用程序，并最终失去竞争力。

回到顶部

回到顶部

数字图书馆是由计算机协会出版的。版权所有©2021 ACM, Inc。

---

没有发现记录