PDF采用和维持基于微服务的软件开发中的挑战
组织挑战可能比技术挑战更难。
Padmal Vitharana 和 Shahir A. Daya
微服务（MS）已成为软件开发中最新的流行语1,6,17，基于微服务的开发正日益普及。微服务方法为传统的单体架构风格提供了一种替代方案。虽然基于微服务的开发相对于单体架构风格的优势显而易见，但行业专家一致认为，这两种风格在所有情况下都不具备绝对的优势。支持者认为，微服务软件开发方法更有利于将更具活力的业务环境所产生的组织变革映射到相应的 IT/IS（信息技术/信息系统）变革。
微服务代表一种架构风格，其中大型、复杂的应用程序由一套较小的微服务组成。人们提倡使用微服务来克服现有软件开发方法的一些弊端1,7,30。每个微服务对应于围绕业务能力的单一功能。每个微服务都包含自己的数据资源，并且可以快速部署。示例包括银行网站上的在线账单支付服务和航空公司网站上的备选航班服务。
微服务的其他优势包括易于进行需求变更和测试、更高的可扩展性、增强的技术创新和异构性（例如，支持不同的编程语言和平台）、易于监控性能（如服务可靠性）以及对更多流程变化的支持4,7,18,29。在acmqueue之前的一篇文章中，Tom Killalea 强调了微服务除了行业专家已经认可的优势之外的八项红利15。Netflix 和 Uber 等知名公司的广泛采用进一步证实了基于微服务的软件开发的可靠性13,16,19。
由于对微服务的正面评价，许多组织现在正在考虑采用它们。虽然优势显而易见，但在采用和维持基于微服务的软件开发方面仍存在重大挑战。许多挑战源于该方法的新颖性以及对影响基于微服务开发的技术和组织参数缺乏了解。除非充分理解这些挑战，否则公司不太可能充分利用微服务的好处，甚至可能比现代化之前的情况更糟。
本文旨在识别从最初决定采用微服务到长期维持新范式的持续任务中的关键挑战。本文旨在为那些考虑基于微服务的软件开发的人员提供见解。本文还穿插了“现场报告”部分，这些部分基于作者之一 Shahir A. Daya 的第一手经验，他在过去两年中一直在多家财富 100 强公司领导重要的基于微服务的开发项目。（他负责帮助 IBM 全球商业服务组织掌握交付基于微服务的现代化项目所需的技能。因此，他教授多门关于该主题的课程，并与他人合著了一本 IBM Redbook 以及 IBM 的《微服务决策指南》。）
采用微服务架构的初步决策
对于许多人来说，采用微服务架构的决定通常源于大型复杂单体应用中失控的代码库23。虽然许多应用程序一开始都很小，并且旨在满足特定的业务需求，但随着新需求的增加和错误的修复，随着时间的推移，它们变得越来越大、越来越复杂。人们经常寻求代码重构来应对不断增长的复杂性的影响，但在单体应用环境中进行重构的障碍是众所周知的1,25。最终，采用微服务架构的决定取决于组织应用程序套件的概况。
虽然代码库螺旋式上升和复杂性升级的极端情况可能是显而易见的，但其他情况使采用微服务的决定变得复杂。在实践中，该决定不应基于一次性将所有单体应用程序转换为微服务；相反，第一步应该是识别特定的业务功能和相关的代码段，作为现代化为微服务的初始候选对象。当频繁的代码更改需要经常部署单体应用程序时，单体应用程序会造成巨大的瓶颈。
当应用程序在相对较短的时间内已经经历了重大增强，或者预计将来会进行重大增强时，管理层应考虑采用微服务。当单体应用占用的测试资源超过开发工作量时，也应考虑现代化为微服务。当一个应用程序被确定为行业中的差异化因素，并且已对其成功进行了大量投资时，应考虑在微服务下对其进行重构。当单体应用程序继续难以满足 NFR（非功能需求）和用户期望时，有更多机会获得现代化为微服务的好处。当软件可扩展性被置于更高的价值时，重构为微服务允许每个微服务独立于构成应用程序的其他微服务进行扩展（相对于单体应用）。虽然通常希望具有可扩展性，但预测未来的可扩展性需求并非易事。
尽管如此，微服务倡导者面临的最大挑战是向上层管理人员提出价值主张。为采用提供理由的关键在于量化微服务的好处，并将其与实施微服务基础设施的成本进行比较，包括招聘和再培训人员。现代化为微服务的决定必须以整体而非零散的方式考虑所有参数。诸如组织文化的改变等无形因素也需要考虑在内，在组织文化中，个人团队负责从开发到运营的每个微服务。
虽然微服务模型在整体系统的持续运行能力方面提供了更高的弹性，即使在非关键微服务发生故障时也是如此7，但这仍然需要编程到代码中12。与单个单体应用不同，微服务允许设置更精细的 SLA（服务级别协议）。但是，当为整个系统考虑单个微服务的 SLA 时，从最终用户的角度来看，它们会变成乘法而非加法。因此，量化由一套相互依赖的微服务组成的应用程序的 SLA 可能非常具有挑战性。
当公司寻找有效应对组织变革的方法时，这些组织变革源于新产品开发等需求以及相应的 IT/IS 变革，微服务提供了一种新颖的方法，可以更无缝地协调组织和 IT/IS 变革7,18,29。然而，对于许多人来说，采用微服务架构的决定并非易事，并且并非所有应用程序都适合这种现代化改造。
在比较单体应用和微服务软件开发方法时，《高级微服务》14的作者 Thomas Hunter 断言，“选择一种方法而不是另一种方法有多种原因，并且没有哪种方法绝对比另一种方法更好或更差。” 当一家公司拥有大量的应用程序套件，这些应用程序历史上每年只部署一到两次时，就没有什么理由跳到微服务。在做出采用新范式的这一重要决定时，公司需要检查其应用程序组合并考虑上述所有标准。随着时间的推移，经验将帮助组织驾驭决策环境，从而采用微服务或保留传统的基于单体应用的开发。
现场报告
在与组织的对话中，很明显他们理解微服务架构风格与单体应用相比更加复杂，并且不应轻率地做出利用微服务现代化应用程序的决定。他们还理解，良好模块化的单体应用程序没有任何问题。只有当他们开始看到在及时交付业务能力方面不如竞争对手，或者当他们开始遇到诸如可扩展性等非功能问题时，他们才会开始谈论现代化应用程序架构的可能性。
组织也开始缓慢地走上微服务之路。许多组织会关注单体应用程序的痛点，并仅使用微服务解决这些痛点。例如，可以将单体应用程序中的性能热点拉入微服务中并独立扩展，而无需扩展单体应用程序的其余部分。
组织已经开始理解，并非所有应用程序都需要现代化为微服务风格，并且不必现代化整个单个应用程序。一个应用程序可以由一个提供某些功能的单体部分以及一个提供其他功能的现代微服务套件组成（即，新旧共存）。例如，一家大型北美银行正在将其在线银行应用程序的选定部分现代化为微服务风格。一家大型美国航空公司也在使用这种机会主义和渐进式方法来现代化其网站、移动应用程序和自助服务亭。这种方法称为绞杀榕模式10。
将现有单体应用转换为微服务
为了实现微服务范式的优势，公司会寻找分解现有单体应用的方法。实际上，识别较大的微服务并在以后将其分解为较小的微服务是有意义的。我们的经验是，将较大的微服务分解为较小的微服务比将两个较小的微服务组合起来创建一个较大的微服务更容易。其他人也提出了类似的观点，即大多数组织倾向于从较大的微服务开始，然后将其拆分为较小的微服务26。挑战在于制定系统地从单体应用中划分微服务的指南。
将代码分段为单元，其中每个单元代表一个单一功能或业务能力，这被称为限界上下文，该术语起源于领域驱动设计3,9。隔离单体应用中频繁更改的代码段是识别限界上下文的起点，以便对单体应用的某些部分进行分段以创建微服务。如前所述，（a）最常用的代码段，（b）占用大量测试资源的代码段，（c）充当差异化因素的代码段，以及（d）难以满足 NFR 和用户期望的代码段也为如何分段单体应用以构建微服务提供了线索。
这种转换练习需要遵守强内聚和松耦合的传统原则。尽管如此，目标永远不应是将整个单体应用转换为微服务。相反，应以迭代方式识别合适的代码段并将其重构为微服务。
为单体应用到微服务的转换实施停止规则在实现预期目标方面起着至关重要的作用，而不会被微服务狂热所冲昏头脑。此外，这不应仅仅是将单体应用的代码库复制并粘贴到微服务的练习。它需要被视为改进该代码段的机会（尽管存在某些挑战），使其成为以明确定义的接口提供特定业务功能的微服务。
在大多数情况下，并非所有原始单体应用都转换为微服务。改造后的单体应用现在必须与新创建的微服务共存。最初发送到单体应用的调用现在可能必须重新路由到相应的微服务。新生态系统带来了仅在单体应用环境中不存在的额外挑战：现有单体应用的用户界面需要更新，以将现代化/新功能指向交付该业务功能的基于微服务的应用程序。单体应用程序和基于微服务的现代化部分之间的这种共存需要它们之间共享上下文，包括身份验证/授权信息，从而进一步加剧了软件开发和运营的复杂性。
分解单体应用不可避免地涉及将企业存储库中的数据元素分段到各个微服务。虽然设计人员通常精通分布式数据库设计原则，但由单体应用和微服务组成的新生态系统需要数据分段方面的培训，这超出了我们现有的知识。在此练习中，挑战在于避免数据重复，并可能学习无视诸如数据规范化等传统原则。一旦数据被分区，就必须对单体应用进行测试，以确保它不会崩溃。虽然每个微服务都包含自己的数据资源有其优势，但从业人员在对企业数据库进行分区时面临着重大挑战。
基于微服务的开发需要额外的测试级别。首先，契约测试是指测试 API。当消费者链接到微服务时，就会形成契约。此契约定义了需要彻底测试的输入、输出和性能参数。
其次，混沌测试是指测试自然界中固有的“混沌”。通常，此练习涉及定义什么是“正常”，并在引入混沌条件之前在这些条件下测试系统。与仅具有两种可用状态的单体应用不同，新的范式中表现出更混沌的条件，因为应用程序中的某些微服务可能正在启动并运行，而其他微服务可能没有。
为了在混沌测试中模拟这种现实，每个微服务都会被有意地关闭，以测试其对整个系统的影响。此测试还涉及有意引入网络延迟，以评估其对性能的影响。微服务通过网络相互通信，而不是单体应用中进行的进程内函数调用。测试断路器11——断路器用于决定是在正常条件下继续运行还是在有限容量下运行——给新兴的范式增加了额外的复杂性。
现场报告
我们不建议使用微服务架构风格创建新的绿地应用程序。一开始就这样做太复杂了。应使用单体应用优先方法来创建 MVP（最小可行产品）并将其交付给用户。一旦单体应用变得足够大，就可以将其分解为微服务。大多数组织都在使用微服务架构风格来现代化现有的关键业务单体应用程序。这些遗留应用程序在多年的代码更改中积累了大量的技术债务，这导致敏捷性下降，影响了新业务功能的上市时间。
几乎所有与我们合作的组织都在使用绞杀榕模式5来“绞杀”单体应用并一次拉出一个微服务。这种方法需要仔细考虑单体应用部分和微服务部分如何共存。这并不简单，但能够快速现代化大型应用程序的某个功能并将其交付给用户的好处超过了共存的复杂性。前面提到的美国航空公司正在使用这种绞杀榕方法。整个转型可能需要三年以上才能完成；但是，最终用户会在各个产品（功能/特性）上线后立即开始看到转型的业务能力，并且在项目过程中他们会继续逐步看到转型的能力。
构建新的微服务和修改现有微服务以满足新需求
随着新需求的出现，开发人员必须决定是构建新的微服务还是修改现有的微服务。在修改现有微服务时，挑战在于保留该微服务的限界上下文（即，微服务中包含的内容的高度内聚）。除非开发人员接受过新范式的培训，否则他们可能会采取技术上便捷的方法，而不是通过关注业务方面来维护基于微服务开发的核心原则。例如，添加新代码以满足需求可能会违反每个微服务应支持围绕业务能力的单一功能的原则。或者，在添加代码时缺乏应有的谨慎可能会导致意外的依赖关系（即，修改后的微服务、其他微服务甚至重构后的单体应用之间的耦合），从而阻碍独立且快速地更改、测试和部署它的能力。
关键在于教育开发人员在新范式中处理业务需求，并灌输维护其基本原则的纪律。每个开发团队的技术负责人需要验证创建新的微服务和修改现有的微服务不会破坏新兴范式的关键假设。需要扩展诸如代码审查之类的传统技术，以确保新的配置不会违反限界上下文。否则将导致微服务架构的崩溃，并阻碍其广受吹捧的优势的实现。
新范式在应用程序级别而不是在企业级别运行，就像 SOA（面向服务的架构）和 Web 服务的情况一样。因此，可能会出现一些重复的工作。尽管一个应用程序团队可能已经创建了一个可以被第二个应用程序团队使用的微服务，但在缺少企业范围的微服务存储库的情况下，后者可能会创建一个相同的微服务。
这些基于应用程序的团队倾向于快速行动，并且它们之间很少共享代码库。确实发生的少量共享是通过口口相传或开发人员和项目团队之间的个人联系来体现的。如果一个团队发现另一个团队已经创建的微服务很有用，则前一个团队倾向于创建其自己的现有微服务的“副本”，以避免依赖后一个团队创建的微服务。该团队实际上是分叉了代码库，现在负责维护其自己的微服务分支。然而，促进共享的最佳方法是对所有微服务进行编目。
新微服务的添加给监控它们带来了新的挑战。开发人员必须定义用于监控微服务性能的指标。一个关键问题是定义用什么来表示微服务处于“良好”状态。监控微服务的可用性、可靠性、履行 SLA 的能力、稳健性和弹性需要指标和基准。可能需要创建合成事务来定期测试每个微服务的运行状况。需要持续监控微服务的性能日志，以评估其性能并在需要时采取纠正措施。
现场报告
微服务的首次交付往往是好的。团队刚刚开始微服务之旅，所有参与者都了解微服务的原则以及它们为什么是必要的。开发人员虔诚地遵守规则，并确保微服务的粒度是合适的，并且它们具有限界业务上下文。
然而，一旦基于微服务的架构的兴奋感和魅力消失，一些开发人员就会开始偷工减料，并违反微服务风格的一些核心原则，例如具有限界业务上下文以及不通过数据库耦合到另一个微服务。这种情况在某些组织中已经很明显，并且随着微服务风格的更广泛采用，它将成为一个更大的问题。
需要纪律，并且诸如架构和代码审查之类的措施对于避免承担不必要的技术债务是必要的。在基于微服务的转型项目中跟踪技术债务是一个好主意。不同的技术和业务约束可能会迫使团队采取捷径，从而导致更多的技术债务。前面提到的美国航空公司在跟踪技术债务方面做得非常出色，并且正在团队的积压工作中创建用户故事来偿还债务。
运营微服务和架构
由于需要跟踪的大量移动部件（相对于传统的单体应用），微服务范式带来了更大的运营复杂性。每个微服务提供特定的业务功能，并且一套微服务必须协同工作才能提供更全面的业务功能。虽然基于微服务的开发依赖于开发提供某些业务功能的自主服务，但设计解耦的应用程序系统并非易事。它涉及相应的微服务之间的消息传递和数据交换，这些都需要监控和管理。与维护单体应用系统常用的企业数据库不同，维护分区到微服务中的数据的可用性和一致性会产生额外的需求。
版本控制在新范式中带来了重大挑战。现在开发人员和分析师必须处理许多微服务的多个构建版本和接口版本，而不是处理少数几个版本的单体应用20。随着开发人员创建新版本，他们必须为先前版本和新版本提供支持。需要将旧版本在功能和界面方面的差异告知用户。一些开发人员选择将新的微服务列为实验性、beta 版或通用版7。如果停止支持旧的微服务，则必须有明确的指南来告知用户。当服务注册表包含微服务的多个版本时，为给定应用程序找到合适的版本会带来额外的复杂性。需要制定版本控制策略和指南。
与函数调用在同一运行进程中的单个单体应用相比，网络对具有许多微服务的应用程序的影响更大8。网络本身会引入延迟问题，这可能会对基于微服务的应用程序的性能产生不利影响。微服务以分布式系统的形式体现，它们之间的调用通过网络进行管理。与单体应用不同，由一套较小的微服务组成的应用程序（它们之间进行消息传递）可能会放大网络延迟。
运行性能测试以识别最大的延迟来源可能是解决此挑战的关键。选择一个有助于识别潜在瓶颈的平台可以缓解网络延迟。虽然在处理由微服务组成的应用程序时网络延迟是不可避免的，但更深入地了解微服务的内部工作原理将有助于识别可接受延迟水平的标记。
除了技术挑战外，当公司开始开发微服务时，他们还面临着改变围绕单体应用的普遍文化的障碍，在这种文化中，激励机制和责任制大相径庭。新范式提倡 DevOps 团队的原则，这些团队负责开发和运营每个微服务。DevOps 对应于一套旨在统一软件开发（Dev）和软件运营（Ops）的实践2。
与基于营销等学科的传统团队不同，DevOps 团队按业务能力组织。他们负责从产品的初始阶段到整个运营生命周期，无论产品是小的还是端到端的垂直切片，贯穿产品实现更大产品的功能，其中包括作为其一部分的所有微服务。
这些 DevOps 团队不是在单体应用中寻求以技术为中心的解决方案，而是在寻求以业务服务为中心的解决方案。在实施微服务之前，必须明确微服务预期代表的明确业务服务（即功能）。文化变革，例如与跨职能团队合作的意愿以及承担新兴范式要求的扩展角色，可能会受到某些方面的抵制。转向基于“谁构建，谁运行和支持”原则的新文化可能具有挑战性。除非激励机制与促进跨职能协作和接受 DevOps 团队中的扩展角色相一致，否则有些人可能不愿接受促进基于微服务的开发所需的组织变革7,28。
现场报告
在不同的组织中工作以交付基于微服务的项目时，我们发现组织挑战比技术挑战困难得多。组建一个可以处理从 UI 到后端，再到所有渠道（Web、移动设备等）的垂直切片的跨职能团队/小组并非易事。这些人可能分布在组织的不同部门，可能需要调动他们以克服一些障碍。调动所有组成团队的成员，以便他们向同一位人力资源经理汇报肯定会有所帮助。尽管他们有同一位人力资源经理，但团队成员将根据他们在跨职能团队中担任的特定角色，接受来自不同负责人的技术指导。
开发人员还需要加快掌握 DevOps 的 Ops 部分。团队必须接受他们维护和支持他们编写的代码这一事实。如果他们编写的微服务失败，他们会在半夜收到传呼。他们需要实施必要的监控、仪表板、警报和运行手册自动化，以避免此类紧急中断。我们正在开始与我们的客户一起做这件事，并且看到了积极的结果。开发人员正在承担责任，代码质量正在提高，但开发人员不想永远维护他们的代码。让他们保持参与至关重要，因此让个人一次从一个团队/小组转移到另一个团队/小组非常重要。
组织中对您的微服务计划的强有力的执行发起人的支持对于成功绝对必要。所有在文化转型方面取得积极进展的客户都有强有力的执行发起人的支持。
长期维持微服务方法
与任何新范式一样，定期需要证明在软件开发和运营中使用微服务的合理性。高层管理人员可能会坚持要求提供绩效提升的证据，以便为人员和微服务相关技术的持续投资提供依据。这需要初始基准测试和持续的绩效评估。
虽然传统指标具有相关性，但需要开发和建立新的绩效指标。例如，必须跟踪基于微服务的应用程序的 SLA 以及每个微服务的 SLA，以确保合规性。除了这些传统的非功能需求外，其他基准测试和跟踪指标还包括现代化应用程序的部署次数增加、部署期间的停机时间减少、报告的缺陷/错误数量减少、添加新功能的更新成本降低等。
此外，需要制定流程来审查和改进应用程序以及每个应用程序中的微服务。从根本上讲，每个微服务都应代表一个单一的业务功能。需要检查和平衡措施，以确认每个微服务都符合此核心原则。通常，公司尚未建立此类流程，尽管这样做对于证明公司在拥抱新范式方面保持忠实于自身而言具有巨大的价值。通常，当修改现有的微服务时，有些微服务可能包含元功能和与其他微服务的依赖关系（即，紧密耦合）——这两种特性与基于微服务的开发指导原则背道而驰。
应定期由与开发方不同的另一方检查每个微服务，以确保其符合基于微服务开发的关键原则。嵌入在微服务中的数据也是如此。如果没有明确的重点和纪律，修改现有微服务以添加新需求或修复缺陷可能会导致微服务和企业数据库之间产生不必要的数据依赖关系。
由于不断面临尽快交付软件产品的压力，一些开发人员可能会试图偷工减料，并在过程中放弃微服务的基本原则。开发人员需要不断接受培训，以维护基于微服务开发的核心原则。
此外，公司需要继续培养人才，以开发下一代微服务，这些微服务对应于围绕业务能力的单一功能，包含自己的数据资源，并且可以快速部署。然而，很少有大学毕业生接受过基于微服务的软件开发方面的培训。这些是组织在长期维持基于微服务的开发方面面临的一些挑战。
现场报告
全栈开发人员不易找到。如今，大多数组织都拥有特定领域的专家——例如，前端开发、后端开发或原生 iOS 开发。很少能找到能够完成所有工作的人。有些人有广度，但在一个领域（“T”型）很深入（即专家）。为了向更倒三角形的个人（即，在多个专业领域具有不同深度）发展，诸如结对编程和频繁的结对轮换之类的实践有助于培养必要的技能。这需要时间，并且不能仓促完成。我们的一些客户正在使用 Spotify 方法，并且事实证明这对于基于微服务的开发来说是一个很好的模型。
IBM 等大型组织正在开始影响学术课程，将云原生和基于微服务的应用程序开发教育纳入其中，以弥合行业中的技能差距。
结论
日益增长的全球化和过度竞争导致了动态的业务环境，这要求公司快速适应快速且频繁的变化。这些环境力量迫使企业战略发生变化，从而体现在内部组织变革中。软件系统与公司的各个方面紧密交织在一起，因此，组织变革需要系统变革4,7,21,24。
然而，公司仍在努力有效地将组织变革与 IT/IS 变革相映射7,29。这归因于公司无法独立且快速地部署软件应用程序7。软件行业对基于微服务的开发克服这些弊端的能力非常着迷。
每个微服务都包含自己的数据，并代表对应于业务能力的单一功能。这允许业务服务与软件服务（即微服务）无缝对齐。虽然新范式具有相当大的优势，但它也可能带来巨大的成本1,7,22,27。因此，必须考虑本文中强调的挑战，以提高公司在采用和维持基于微服务的软件开发方面的成功几率。
参考文献
1. Abgaz, Y., McCarren, A., Elger, P., Solan, D., Lapuz, N., Bivol, M., Jackson, G., Yilmaz, M., Buckley, J., Clarke, P. 2023. 将单体应用程序分解为微服务架构：系统综述。IEEE Transactions on Software Engineering 49(8), 4213–4242; https://dl.acm.org/doi/10.1109/TSE.2023.3287297.
2. Balalaie, A., Heydarnoori, A., Jamshidi, P. 2016. 微服务架构支持 DevOps：迁移到云原生架构。IEEE Software 33(3), 42–52; https://dl.acm.org/doi/10.1109/MS.2016.64.
3. Bogner, J., Zimmermann, A. 2016. 将微服务与可适应的企业架构集成。IEEE 第 20 届国际企业分布式对象计算研讨会，158–163; https://ieeexplore.ieee.org/document/7584392.
4. Bozan, K., Lyytinen, K., Rose, G. 2021. 如何逐步过渡到微服务架构。Communications of the 64(1), 79-85; https://dl.acm.org/doi/10.1145/3378064.
5. Brown, K. 2017. 将绞杀榕应用程序模式应用于微服务应用程序。IBM; https://developer.ibm.com/articles/cl-strangler-application-pattern-microservices-apps-trs/.
6. Cortellessa, V., Di Pompeo, D., Eramo, R., Tucci, M. 2022. 基于模型的微服务系统持续性能工程方法。Journal of Systems and Software 183; https://www.sciencedirect.com/science/article/pii/S0164121221001813.
7. Daya, S., van Duy, N., et al. 2016. 微服务从理论到实践：使用微服务方法在 IBM Bluemix 中创建应用程序。IBM Redbooks; https://www.redbooks.ibm.com/abstracts/sg248275.html.
8. Dragoni, N., Saverio, G., Lafuente, A.L., Mazzara, M., Montesi, F., Mustafin, R., Safina, L. 2017. 微服务：昨天、今天和明天。在Present and Ulterior Software Engineering. Springer, 195–216; https://link.springer.com/chapter/10.1007/978-3-319-67425-4_12.
9. Evans, E. 2004. 领域驱动设计：应对软件核心的复杂性。 Addison-Wesley Professional.
10. Fowler, M. 2004. 绞杀榕应用程序; https://martinfowler.com.cn/bliki/StranglerFigApplication.html.
11. Fowler, M. 2014. 断路器; https://martinfowler.com.cn/bliki/CircuitBreaker.html.
12. Hasselbring, W. 2016. 微服务用于可扩展性：主题演讲摘要。第七届/SPEC国际性能工程会议论文集, 133–134; https://dl.acm.org/doi/10.1145/2851553.2858659.
13. Hoff, T. 2016. 从Uber扩展到2000名工程师、1000个服务和8000个git仓库中吸取的教训。高可扩展性; https://goo.gl/1MRvoT.
14. Hunter, T. 2017 高级微服务：微服务基础设施和工具的实践方法, 第1页. APress出版社。
15. Killalea, T. 2016. 微服务的隐藏红利。acmqueue 14(3); https://queue.org.cn/detail.cfm?id=2956643.
16. Mauro, T. 2015. 在Netflix采用微服务：架构设计方面的经验教训。NGINX; https://goo.gl/DyrtvI.
17. Mendonça, N., Jamshidi, P., Garlan, D., Pahl, C. 2021. 开发自适应微服务系统：挑战与方向。IEEE Software 38(2), 70–79; https://dl.acm.org/doi/10.1109/MS.2019.2955937.
18. Newman, S. 2020. 从单体架构到微服务：转换单体架构的演进模式。 O’Reilly Media出版社。
19. Panda, A., Mooly, S., Shenker, S. 2017. 微服务时代的验证。第16届操作系统热点主题研讨会论文集, 30–36; https://dl.acm.org/doi/10.1145/3102980.3102986.
20. Pautasso, C., Zimmermann, O., Amundsen, M., Lewis, J., Josuttis, N. 2017. 微服务实践，第2部分：服务集成和可持续性。IEEE Software 34(2), 97–104; https://dl.acm.org/doi/10.1109/MS.2017.56.
21. Rolland, K., Lyytinen, K. 2021. 管理架构债务管理与数字创新之间的张力：一家金融机构的案例。第54届夏威夷国际系统科学会议论文集, 6722–6732; https://scholarspace.manoa.hawaii.edu/server/api/core/bitstreams/5b283564-2e92-4c36-abf3-519e72d0fd0b/content.
22. Singleton, A. 2016. 微服务的经济学。IEEE Cloud Computing 3(5), 16–20; https://ieeexplore.ieee.org/document/7742218.
23. Taibi, D., Lenarduzzi, V., Pahl, C. 2017. 迁移到微服务架构的过程、动机和问题：一项实证研究。IEEE Cloud Computing 4(5), 22–32; https://ieeexplore.ieee.org/document/8125558.
24. Tallon, P. P., Queiroz, M., Coltman, T., Sharma, R. 2016. 业务流程和信息技术对齐：概念化构建、实证说明和未来研究方向。Journal of the Association for Information Systems 17(9), 563–589; https://aisel.aisnet.org/jais/vol17/iss9/3/.
25. Tempero, E., Gorschek, T., Lefteris, A. 2017. 重构的障碍。Communications of the 60(10), 54–61; https://dl.acm.org/doi/10.1145/3131873.
26. Thönes, J. 2015. 微服务。IEEE Software 32(1), 116; https://dl.acm.org/doi/10.1109/MS.2015.11.
27. Waseem, M., Liang, P., Shahin, M. 2020. DevOps中微服务架构的系统映射研究。Journal of Systems and Software 170; https://www.sciencedirect.com/science/article/abs/pii/S0164121220302053.
28. Waxer, C. 2015. 微服务狂热。Computerworld 2(4), 22–27; https://www.computerworld.com/article/2998269/read-cw-s-november-monthly-digital-magazine.html.
29. Wolff, E. 2017. 微服务：灵活的软件架构。纽约：Addison-Wesley出版社。
30. Zhou, X., Li, S., Cao, L., Zhang, H., Jia, Z., Zhong, C., Shan, Z. Babar, M. A. 2023. 重新审视现实中微服务架构的实践和痛点：一项行业调查。Journal of Systems and Software 195(C); https://dl.acm.org/doi/10.1016/j.jss.2022.111521.
致谢
本研究由雪城大学惠特曼管理学院罗伯特·H·布雷森运营管理研究所和厄尔·V·斯奈德创新管理中心的资助项目资助。
Padmal Vitharana 是雪城大学马丁·J·惠特曼管理学院的信息系统教授。他获得了威斯康星大学密尔沃基分校的博士学位。他的研究专长在于一般的系统分析和设计，特别是微服务、软件组件和服务。他的研究成果发表在领先的期刊上，并曾在 IEEE Transactions on Services Computing 和 Communications of the AIS 的编辑委员会任职。
Shahir A. Daya 是 IBM 杰出工程师，也是 IBM 加拿大业务转型服务的首席架构师。他是 IBM 高级认证架构师和 Open Group 杰出首席/首席 IT 架构师，在 IBM 工作超过 25 年。他因杰出的技术成就而荣获享有盛誉的 IBM 公司奖。他的行业经验包括银行、金融服务以及旅游和交通运输。他专注于云原生架构和高性能开发团队的现代软件工程实践。
版权 © 2024 归所有者/作者所有。出版权已授权给。
最初发表于 Queue 第 22 卷，第 1 期—
在数字图书馆中评论本文
© 保留所有权利。