单体听起来很神秘。在数以千计的全球组织中，单体应用程序通常是独立的、并排的、神秘的、令人敬畏的。整体式应用程序是现代商业不可或缺的一部分，也是每个关键业务流程的重要贡献者，从后台到供应链，从客户服务到业务参与等等。虽然这些单体继续为业务做出巨大贡献，但这些应用程序的现代化是一个令人沮丧和痛苦的话题。许多组织放弃了，而另一些组织则通过重新定位或重新架构（旧的“提升和转移”）将整个单体迁移到云中作为权宜之计。2022年，新希望、新技术和新方法正在打破单体应用的神秘面纱。误区1：单体现代化是失败的原因每个云提供商、云原生平台和系统集成商都有一个模型，几乎包含现代化词典中的每个“R”。最初，这个行业只有五个R的现代化：重新托管、重构、重新架构、重建或替换。随着现代化的成熟和更多顾问的参与，R的数量也在增加，包括重新平台化、重写、保留和退役。这令人困惑。很少有数据、数学和自动化被应用到单一的现代化过程中。有书籍和最佳实践，还有许多顾问和解决方案架构师愿意提供建议和交付。这些都是很好的开端，但往往侧重于DIY方法或昂贵、高风险的外包。新一波工具、应用人工智能和自动化正在被应用，以弥合所有DIY或所有外包选项之间的差距。这些方法的基础是基于单体的实际架构分析，不仅是需要迁移到新版本的底层平台组件，还有实际的业务逻辑本身。业务逻辑是应用程序的核心，架构师可以从中开始识别可以导致更清晰的微服务领域驱动设计的领域。至少，这些服务代表了更独立的迷你服务，或者只是具有更高排他性的普通服务。缺乏基本的数据驱动方法导致应用程序团队远离现代化，选择迁移策略作为权宜之计，这导致我们陷入陷阱2。误解2：单体应用到云=现代化将应用程序迁移到云是一个引人注目的目标，并且将IT和应用程序团队围绕一个更大的目标联合起来的“moonshot”愿景。但需要明确的是，移民不等于现代化。整体迁移到云端，可以获得巨大的DevOps和数据中心缩减收益。几乎所有组织都意识到了这些短期收益，这反过来又为希望加速和简化企业工作负载向云迁移的云提供商创造了意外收获。许多技术领导者所犯的错误是认为他们的工作已经完成——我们现在已经实现了现代化！这种误解很快就破灭了：现在大多数组织都清楚，云中的单体应用与内部部署的单体应用面临着相同的挑战。困难——工程化缓慢、缺乏可扩展性、维护困难和可持续性低。随着成本开始上升，云优势仍然遥不可及，许多人将这一阶段称为“提升和转移遗憾”或“迁移遗憾”。为了打破这种误解，必须在更大、更具战略性的现代化战略背景下看待和规划移民——移民只要是全面现代化的基石就可以。整体现代化使其能够充分利用云原生架构的价值，从容器和微服务到Kubernetes和无服务器。再加上利用通用CI/CD、安全和DevSecOps策略和平台的好处，您的业务案例很快就会到位，这导致我们产生误解3。误解3：为应用程序现代化构建准确的业务案例是不可能的对于大多数组织而言，应用程序现代化最困难的部分是为现代化项目构建准确的业务案例。我们探索了误解#1中缺失的元素之一来解决这个问题：预测时间和精力的架构师与批准预算和资源的业务领导者之间缺乏数据驱动讨论的基础。由于缺乏共同的语言和衡量基础，领导层和管理层之间的信任出现双向崩溃。打破这个循环需要开始数据和测量。首先分析衡量个人的复杂性和改变整体所涉及的风险。要了解复杂性，您首先需要确定社区或依赖集群，这表明哪些区域是明显的，以便可以提取微服务。然后可以通过类依赖关系在它们之间纠缠的程度来计算复杂性，从而降低代码的模块化级别。风险可以通过依赖链的长度来衡量，它决定了应用程序某一部分的变化对应用程序下游不相关部分的影响程度。所有这些都可以汇总成一个总体技术债务评分，显示当前的债务支出与创新支出，显示现代化项目的ROI和TCO业务用例优势。从这种强有力的量化立场来看，业务优先级更容易达成一致，这让我们打破了误解4。误解#4：所有单体都是平等的事实上，单体架构可以成为适用于各种用例的相关现代设计模型。一个简单的第一步是根据当今的业务价值对单体应用进行堆栈排序。评估他们的业务实用性和工程负载、功能积压和维护成本。通常，这些应该保持一致，因为团队的规模、积压功能的数量和维护成本应该与企业单体的商业价值保持一致。事实上，这些单体抵制“遗留”标签，因为它们仍然是企业和支持它们的工程团队的一等公民。业务价值下降的老化单体是简单重组或最终退休的绝佳选择。如果应用程序仍然是一个可行的业务贡献者，那么必须对其复杂性和与现代化相关的风险进行全面评估（请参阅误区#3）以制定最佳计划，从而制定更准确的业务用例。通过计算这些关键业务部门的复杂性、风险和由此产生的技术债务，您可以使用基于AI的自动化工具将不太复杂的部分转移到更快的应用程序现代化项目中，从而加快流程。更复杂的单体（通常称为“巨石”）将花费更多时间，并且应该遵循更具迭代性的重构方法，使用扼杀模式将控制从单体切换到新服务，一次有选择地提取一两个微服务。这些单一的应用程序可以存在于任何地方，甚至在云端。误解#5：单体应用是一个内部问题诚然，当今大多数单体应用仍然存在于内部，牢牢固定在其原始基础架构上。但越来越多的单体已经成功迁移到云端，运行在云提供商的IaaS基础设施中，使用提供商的算力、CPU和内存，但不幸的是，它们仍然以单体的形式运行。这些云中的单体可能会成功运行一段时间，但当可扩展性问题出现时，唯一的解决方案是以越来越高的成本购买越来越大的图像——更多的CPU和更多的内存。这些可能需要更昂贵的预留实例，云工程师必须始终在红线级别运行——没有弹性，没有水平可扩展性。上述相同的数据驱动评估和优先级排序方法与云中的这些单体完全相关，甚至可能更相关。为什么？数据驱动的评估、支持AI的现代化和迁移后重构是所有解决方案和软件架构师所需的关键能力。云中的单体如此接近于完全实现其现代命运。一旦整体重构过程完成，容器、Kubernetes、DevOps、无服务器和服务网格服务就可以在云上启动。误解6：单体依赖无法解开承担维护任务的架构师面临着严峻的挑战，更不用说在他们的职责下对单体进行现代化改造了。大多数时候，他们不是最初的架构师或开发人员，即使他们是，整体也会随着时间的推移而发展，承担越来越多的技术债务，这可能会掩盖很多最初的意图。这些错综复杂的巨石有许多相似之处。人工智能可以提供帮助。当一个系统可以将单体的深度依赖关系表示为图形时，图形机器学习可以检测在潜在域中形成活动社区的集群和链接，这带来了一系列好处，从理解复杂性和变化风险到实际检测之间的潜在边界微服务和社区。构建支持它的图形和模型需要结合动态和静态分析，但最终结果是更高效和有效的现代化工作。整体现代化是可能的，它们可以变得更可预测和更快。误区7：永远无法实现整体现代化在打破了上述六个误解之后，应该清楚的是，如果您遵循这些建议，时间和预算不应成为现代化的一个因素。现在，讨论应该是关于现代化可以带来哪些商业利益和成果。明确的评估和数据驱动的规划也应该塑造实现现代化的方式。复杂性较高的应用程序应遵循迭代的、选择性的重构策略，在这种策略中，不太复杂的关键业务单体可以更快地完成整个过程。在过去十年中，应用程序现代化一直是一项劳动密集型最佳实践，需要大量培训以及文化和组织变革。这些实践都是关键技能，但由于缺乏自动化和支持工具，该过程因技能差距和失败疲劳而放缓至停滞。这里有一些新工具采用这些方法，并通过人工智能和自动化将它们提升到一个新的水平。下一步是部署一个持续的现代化方法，插入CI/CD管道，并在应用程序的整个生命周期中检测和修复技术债务。
