译者 | 刘汪洋
审校 | 重楼
单体架构和微服务架构是当今软件开发中的两种主要范式。人们常把它们分别视为传统和现代的开发方式，但实际情况要复杂得多。选择合适的架构需要权衡诸多因素，每种方案都有其独特的优劣势。
对大多数新项目来说，直接采用微服务架构并非最佳选择。从单体架构起步，在需要时再逐步向微服务演进，这种方式往往更高效、更经济。
随着应用规模扩大，单体系统的维护成本不断攀升。一些团队开始考虑通过重构将应用拆分为微服务；也有团队仅仅因为追求技术潮流而选择转型。这个过程往往耗时较长，甚至可能增加维护负担。因此，在启动转型前，需要深入评估利弊得失，确保当前架构确实遇到了瓶颈。记住，拆分总比重建容易。
接下来，我们将聚焦于几个核心话题：
- 如何充分发挥单体架构的优势，为未来可能的微服务转型打好基础
- 如何实现从单体到微服务的平稳过渡
- 微服务转型可能带来的连锁反应
更优雅的模块化单体架构
在考虑架构转型前，不妨先审视项目的结构设计。如果你的项目还没有采用模块化，这或许是一个值得尝试的方向。模块化不会强制你转向微服务，但能让你享受到微服务的诸多好处，同时避免额外的维护成本。
基于项目的构建工具（Maven、Gradle等），我们可以把项目划分为独立的模块。其中部分模块可以共享复用，其他模块则可以独立封装特定的业务领域或功能特性，为应用提供独立的服务能力。
模块化架构带来的好处显而易见。它让应用各个部分之间更加松耦合；让功能开发更加独立，减少代码冲突；让新人更容易融入团队，因为他们可以从局部入手，逐步了解整体；让测试更加精准，因为每个模块都可以独立验证；如果未来需要迁移到微服务，这些模块化的基础会让转型事半功倍。
当然，模块化架构也面临一些局限。比如无法针对不同模块独立扩展，系统整体的资源配置需要满足负载最重的模块需求，这可能造成资源浪费。技术选择也会受限，因为模块化的单体应用难以混用 Java、Golang 和Python 等不同语言，不过这在大多数场景下并非主要问题。
模块化整体式架构 vs 微服务
渐进式的绞杀者模式
绞杀者模式借鉴了自然界中藤蔓植物的生长特点，通过逐步替换的方式实现系统更新。这种模式让你能够在保持系统稳定运行的同时，逐步用新服务取代旧系统的各个部分。
实施绞杀者模式需要循序渐进：
先进行转换，从单体架构中识别并提取适合独立的功能模块，用现代技术重新实现，这是改进原有实现的好机会。接着是共存阶段，新旧系统并行运行，通过灰度发布逐步迁移流量，同时保留回滚能力。最后是淘汰阶段，当新服务稳定性得到验证后，完全切换流量并下线旧系统。
这种渐进式迁移策略的优势显著：既能保持系统持续交付能力，又能降低转型风险，还能让团队专注处理局部细节，及早发现并解决潜在问题。
转型中的挑战与应对
在实施绞杀者模式时，转型策略的规划至关重要。团队需要深入思考哪些组件优先改造、如何确保新旧系统的无缝对接、如何维护数据一致性等关键问题。同时，建立清晰的沟通机制和监控体系，实时掌握每次替换的进展和影响，这些都是确保转型成功的重要保障。
微服务转型带来的连锁反应
转向微服务固然能带来诸多益处，但也会让一些原本简单的事情变得复杂。比如本地测试场景，由于微服务数量众多，开发团队可能难以在个人设备上完整运行测试环境。又如日志追踪，当一个业务流程横跨多个服务时，完整的链路日志收集和分析就变得极具挑战性。这就需要我们提前做好准备，建立合适的工具和规范。
让我们深入探讨几个需要重点关注的领域：
基础设施的升级之路
单体应用和微服务在基础设施需求上有着本质差异。运行单体应用时，基础设施相对简单，用几台虚拟机或AWS EC2 这样的 PaaS 方案就能应对。扩容、配置、升级、监控等运维工作也可以通过简单工具实现，不一定需要专业的 DevOps 团队支持。
而微服务架构则对基础设施提出了更高要求。伴随服务数量增长，手动运维很快就会力不从心。你需要引入Kubernetes这样的容器编排平台，或者选择托管容器服务。这意味着更专业的技术栈和更系统的运维能力储备。
平台能力的构建之道
维护单体应用时，很多工作都相对直观。发现安全漏洞了？在一处更新依赖就够了。需要规范化外部服务调用？写个统一的包装类到处复用即可。
但在微服务场景下，这些看似简单的任务都变得复杂起来。原本的一次更新现在要协调多个服务，每个服务都有自己的版本节奏和依赖关系。当服务和团队数量增多时，这种复杂度会进一步提升。
这就是为什么许多组织会专门成立平台团队，构建统一的平台层。平台层就像是所有微服务的共同基础，统一管理公共依赖，提供标准化模式，封装现成的工具组件。这样不仅简化了日常维护，还能确保整个系统的一致性。
结语：慎重选择，稳步前行
微服务转型是一次重要的架构升级，需要深思熟虑和周密规划。我们探讨的这些步骤和模式，都是为了让这个过程更加平稳可控。绞杀者模式提供了渐进式的转型思路，保障了系统持续稳定运行。而模块化的单体架构不仅是迈向微服务的重要准备，有时甚至能让我们重新审视转型决策，在享受微服务优势的同时避免过度的复杂性。
选择什么样的架构并不重要，重要的是这个选择能否真正解决我们面临的问题，能否适应团队的技术水平和业务需求。架构转型不是目的，而是手段，最终服务于业务发展才是根本。
作者介绍
刘汪洋，51CTO社区编辑，昵称：明明如月，一个拥有 5 年开发经验的某大厂高级 Java 工程师。
原文标题：Don't Fall Into the 'Microservices Are Cool' Trap and Know When to Stick to Monolith Instead，作者：Mariia Berdysheva
