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