如何实施微服务项目(第 3 部分)

商务人士在混合办公空间工作

如何实施微服务项目(第 3 部分)

在这个关于微服务应用开发的 6 部分系列中,我们为定义最符合当前需求并能支持长期云采用决策的云试点项目提供了背景框架。

在第 3 部分中:我们提供了一种用于实施您自己的微服务项目的方法。

演进现有应用

现在我们更深入地探讨如何为特定规模的微服务应用开发旅程规划路线,并着眼于从较小规模到较大规模演进现有应用的可能性。

虽然从零开始构建微服务项目也相关且重要,但我们赞同在构建微服务时采用"单体优先"的方法。简而言之,这意味着您首先以任何可行的方式构建您的应用,以验证您的想法。然后,您应用本系列博客中阐述的原则,将您最初的单体应用扩展和演进为微服务项目。如果不能为业务提供价值,创建纯架构的微服务是毫无意义的。

要实施成功的微服务项目,您需要了解三个方面:您的业务、您的文化和技能组合以及您的技术。

理解并定义您的业务需求

您为何考虑转向微服务?对于许多企业来说,需要更高效的软件开发和运营实践,以便更快地为企业创造价值,并提供更好的用户体验。

在了解微服务对现有应用程序和基础设施的影响之前,您必须了解业务的哪些部分进展太慢,无法产生令人满意的结果。在许多情况下,是组织的互动系统导致了速度缓慢。这些系统可通过多种渠道访问——Web、移动端、API 等。速度不足是转向基于微服务的架构的主要原因。

在采用面向微服务的方法之前,您和您的业务利益相关者必须清楚哪些部分未能足够快地进入市场。应用程序的哪些部分需要改进和修改才能运行得更快?要回答这个问题,就需要确定现有单体架构的哪些部分应该进行微服务演进。

使用用户体验流程图或架构图,通过热图式标注帮助团队快速划分现有单体应用的各个部分。例如,使用红-黄-绿量表来标示痛点的优先级,以下是一个店面应用的 Web 归档示例:

 
显示 Storefront WAR 应用架构的示意图。它包含五个堆叠的模块,从上到下分别标记为:“店铺前台”、“商品目录”、“推荐系统”、“库存管理”和“账单结算”。每个模块在整个 Storefront WAR 容器内表示为一个彩色水平块。

当前阶段的评估不求详尽,但须秉持迭代理念,以达成以下关键目标:

  • 识别您的单体应用所提供的各项独立业务功能

  • 理解更改这些业务功能所需的相对速度和复杂性

  • 理解业务负责人期望针对这些特定业务功能获得更快反馈周期的意愿。

了解您的文化与技能集

虽然并非基于微服务架构所独有,但全面了解一个组织的团队、文化和技能对于成功的关键数字化转型至关重要。

通常,在开发单体应用时,大多数组织都构建成孤岛形式,团队根据需要参与软件开发生命周期的不同阶段。这常常会形成明确的边界,以及沿这些边界划分的受限角色和职责。

替代文本:显示按角色和服务划分的团队结构图。行代表服务 A、服务 B 和服务 C。列代表业务负责人(黄色)、设计负责人(紫色)、开发人员(红色)、运维人员(绿色)和架构师(蓝色)。每个服务在每一角色列中都有一名成员,通过网格中对齐的彩色用户图标表示。

只有当团队有权掌控整个软件开发和运营生命周期时,微服务架构才能取得成功。组件代表所有角色和职责的跨职能团队是实施基于微服务架构的基础。从设计到开发,到运维,再到业务负责人,每个人都紧密协作,并且通常集中办公。

由于团队中按设计涵盖了设计、开发和运维等所有相关方代表,工作得以更快速、高效地推进,并能清晰聚焦于改善用户体验以实现业务目标。

显示跨职能团队结构的示意图。行代表服务 A、服务 B 和服务 C,每个都用红色框线标出以突出团队分组。列代表角色:业务负责人(黄色)、设计负责人(紫色)、开发人员(红色)、运维人员(绿色)和架构师(蓝色)。每个服务包含来自每个角色的一名成员,强调了跨学科的协作。

跨职能团队也有助于促进团队成员个人技能的快速成长。当团队全面负责微服务的所有方面——从设计到运维再到运行时数据——便没有团队成员会只执行单一任务。前端工程师常会培养起数据库管理技能,而偏向运维的团队成员则能了解更多用户界面框架的差异。通过这种方式扩展技能组合,有助于整个 IT 组织在微服务方面取得成功,因为组建由全面发展的成员构成的新团队,远比不断寻找专家来填补特定角色要容易得多。

理解技术

除非您解决了业务问题以及团队文化和技能组合方面的挑战,否则将无法有效实施微服务技术,并且原有的流程和结构也将保持不变。

对现有技术栈的恰当分析因组织而异,但我们所简化的方法有助于确保您的微服务项目获得初步以及持续的成功。从小处着手,逐步取得迭代式的成功,比那种华而不实、企图一步到位彻底改造的方法,是更易实现且更富成果的途径。

“理解技术”示意图

理解技术的第一步,是识别现有单体应用中的粗粒度服务。识别这些粗粒度服务有助于您理解数据结构的复杂性、当前组件间的耦合程度、负责这些新粗粒度服务的团队等等。通过成功的粗粒度服务审查,您可以清楚地了解给定服务内部以及跨服务的数据边界。

确定粗粒度服务后,必须制定计划以说明如何将这些粗粒度服务演变为细粒度微服务。这些微服务,基于您之前的工作,都应处理相似的数据,拥有其“自己的”数据,并清楚它们需要从何处读取数据以及将数据写入其他服务。由此,您可以识别并实现各个细粒度微服务的弹性、可扩展性和敏捷性。

API 和微服务是一个更大整体的两个组成部分。一旦您对细粒度微服务有了更好的理解,您也会更清晰地理解您的接口:哪些接口处于关键路径上,哪些接口是可选的,以及哪些接口您不再需要。如果现有接口或 API 无法映射到粗粒度或细粒度的微服务,则很可能将其舍弃也无妨。

评估微服务实施规模

深入了解业务、团队结构和技术,才能确保您的团队和整个组织做好准备,了解任何给定单体架构的微服务演进的全貌——无论是在概念验证范围、试点范围还是大规模演进范围内。

所有分析和规划工作完成后,下一步是确定时间表、交付速度和预期结果。

下一篇文章,我们将探讨进行微服务转型时可以应用的开发和运维模式。

后续步骤:

Roland Barcia(IBM 杰出工程师/首席技术官)、Rick Obowski(高级技术人员)与 Kyle 合作撰写了本文。

作者

Kyle Brown

IBM Fellow, CTO

IBM CIO Office