在Kubernetes容器化环境中，要高效地实现从单体到微服务的迁移，就要遵循以下最佳实践。
译自 4 Strategies for Migrating Monolithic Apps to Microservices，作者 Kayla Bondy 是 Dynatrace 的高级产品营销经理，专注于应用程序可观测性产品线。凭借 7 年以上的技术和营销角色经验，她为传达复杂的技术概念带来了热情和专业知识......
DevOps 团队面临着使用 Kubernetes 将单体应用迁移到分布式容器化架构的巨大压力，以优化软件交付生命周期(SDLC)。他们正在努力缩短发布周期、简化部署更改、减少依赖导致的脆弱性。
这些需求推动了从难以跟上现代需求的单体应用的转变，因为一次更改需要重建整个堆栈。根据云原生计算基金会 (CNCF) 2022 年度调查，79% 的组织已经转向微服务架构，可以轻松对单个服务进行迭代。
对许多组织来说，采用举起并转换的方法是将单体应用迁移到 Kubernetes 和微服务的第一步。这涉及直接将单体应用程序部署到云上托管的硬件上，然后逐步拆分应用为微服务。但是，举起并转换理念也存在挑战，因为组织必须重构单体应用程序以优化云性能。因此，逐项将应用程序重构为容器化架构通常更具成本效益。
以下是 DevOps 团队可以遵循的四个最佳实践，以高效地将单体应用迁移到 Kubernetes 容器化环境中的微服务。
单体应用程序通常很容易被破坏其复杂和脆弱的依赖关系网。因此，在没有清晰计划的情况下将单体应用迁移到云和容器时，突发和意外中断几乎不可避免 - 尤其是如果 DevOps 团队继续前进。为了避免不必要的意外，在任何迁移项目之前要全面映射单体应用的依赖关系和业务功能。
由于其复杂性，手动映射单体应用的依赖关系存在高度人为错误风险。因此，为了了解应用程序后端和前端组件之间的关系，使用可以实时可视化应用程序的自动化解决方案将很有帮助。使用事务跟踪的遥测数据进行应用程序拓扑映射至关重要，使团队能够构建单体应用及其组件的精确可视化表示。
为容器化的 Kubernetes 环境重构单体应用是一个巨大的任务，通常涉及从头重构和重建。考虑到这一点，将迁移工作分解为小的、增量的和更可管理的作业至关重要。
在映射单体应用后，DevOps 团队可以逐步用微服务替换其组件。在创建单个微服务时，团队可以针对单体应用进行测试和比较，看看新服务如何影响性能和功能。然后，一旦微服务成功复制了单体应用的功能，团队就可以删除该特定组件对单体的依赖，然后继续下一个组件。
单体应用中的依赖关系是深度交织在一起的。组件之间的这些密切关系是推动向 Kubernetes 和微服务转型的驱动力之一，因为它们阻碍了灵活的变更和部署。
将应用迁移到微服务架构时，团队要了解服务之间的所有依赖关系，并尽可能减少和简化这些依赖关系。异步消息传递至关重要，它允许服务通过使用队列发送和接收消息来进行通信。通过采用异步消息传递，微服务之间的通信将更少出现瓶颈，同时也使编辑或替换单个微服务变得更容易。
从单体应用迁移到 Kubernetes 上的容器化服务意味着应用程序有更多可以相互独立运行的服务和支撑技术，这可能会使它们更复杂。鉴于组件数量，DevOps 团队很难手动跟踪它们之间的所有依赖关系。就像团队需要在迁移单体应用之前对其进行映射一样，他们还需要通过端到端可观测性来维护微服务环境映射。
在实践中，这意味着使用可观测数据(包括来自云技术栈组件的日志、指标和跟踪)，以了解服务关系和应用依赖。这种可观测性还必须扩展到每个 Kubernetes 集群、节点和 Pod 以及在其上运行的工作负载。当问题出现时，可观测数据允许 DevOps 团队识别问题的根本原因，以便他们可以快速解决问题。
为了更有效，团队应该使用一个平台，该平台统一了来自整个应用基础设施的可观测性和安全数据。这个统一的平台应该利用 AI 功能，为环境运行状况提供精确答案，这样团队就可以自动完成大部分围绕故障分类、解释和补救的工作。
从单体应用迁移到容器化微服务可能很复杂且时间耗费。然而，一旦迁移完成，DevOps 团队就可以更灵活迭代，同时能够充分利用云服务。
团队为实现迁移而完成的大部分工作在很长时间内都会带来回报。采用现代技术(如端到端可观测性和 AI)来促进迁移，使团队能够持续监控和优化其微服务环境，从而提供最佳的用户体验和业务结果。这些技术可以激发他们的转型努力，帮助组织获得持久的竞争优势。