译者 | 刘汪洋
审校 | 重楼
微服务架构以其可扩展性、敏捷性和弹性深受青睐，但在实践中，许多组织往往遭遇可能削弱这些优势的挑战。本文聚焦于常见的微服务反模式，并结合实际经验提供构建高效、可扩展微服务的实用建议。
要避免的微服务反模式
1.分布式单体
问题
“分布式单体” 是指尽管系统形式上采用了微服务架构，但服务之间高度耦合，以至于每次更新一个服务时，都需要同时调整或重新部署多个其他服务。这种设计实质上延续了单体架构的特点，只是将其组件分散在了不同的服务中，未能实现真正的微服务范式。
真实场景
例如，在一个包含支付服务、订单服务和库存服务的电子商务系统中，若这些服务彼此强依赖以完成用户事务，则任何一项改动都会导致连锁反应，要求其他服务同步更新或重新部署。尽管从外部看似为分布式系统，实际上这种耦合模式背离了微服务的核心原则。
实用解决方案
通过采用领域驱动设计 (DDD)，明确各服务的边界上下文，从而实现职责分离。例如，将“支付服务”设计为独立的自治域，仅通过定义清晰的 API 与其他服务交互，如“订单服务”。同样，订单服务与库存服务之间可以采用事件驱动的设计模式（如基于 Kafka 的消息中间件），从而避免直接依赖。
专业建议
在系统迁移过程中，建议使用功能开关逐步引入新功能，同时确保与现有系统的向后兼容性。这种方法不仅降低了迁移风险，还能在实际应用中验证新架构的稳定性和可行性。
2.跨服务共享数据
问题
跨服务共享数据库，尤其是允许多个服务对同一数据库表进行写操作，会违反微服务架构中关于服务自治的核心原则。这种设计增加了服务间的耦合度，使得对数据库的任何更改都可能影响多个服务，从而削弱了微服务的独立性和灵活性。
真实场景
在典型的 ERP 系统中，销售服务和库存服务可能需要访问同一产品表进行数据写入。例如，对产品信息的任何架构调整或写操作，都会引发连锁反应，导致相关服务发生故障。这种共享数据库的模式不仅增加了系统的复杂性，还需要团队间密切协调，降低了开发效率。
实用解决方案
- 封装数据库逻辑：将数据库访问逻辑封装在特定的服务中，通过定义明确的 API 提供数据访问功能，避免其他服务直接访问数据库。
- 引入只读副本：使用只读副本或缓存解决方案（如 Redis）满足其他服务的读取需求，同时确保写操作仅限于拥有数据所有权的服务。
- 分布式数据库隔离：最终目标是为每个微服务提供独立的数据库，但在过渡期间，可以先定义明确的写入权限，仅允许单一服务对特定表进行写操作，其他服务通过 API 或查询接口实现只读访问。
实际挑战
实现每个微服务独立数据库可能面临较大的迁移成本，特别是在复杂系统中。作为折衷方案，可以在共享数据库中采用“每个服务一个模式”的方法。具体而言，为每个微服务分配专属的数据库模式（Schema），其他服务无法直接访问这些模式中的数据，除非通过指定的 API。
陷阱
对于无模式数据库（如 MongoDB），严格的 Schema 管理并不适用。然而，即便在无模式数据库中，共享集合的微服务仍可能因为隐式的数据协议产生耦合问题。例如，一个服务以特定格式存储数据，另一个服务却期望以不同格式读取这些数据，这种隐式契约会导致隐藏的兼容性问题。因此，无模式数据库中的服务间数据访问也应通过 API 抽象来避免直接依赖。
3.过度同步调用
问题
过度同步调用（如通过 REST 请求）可能导致系统性能下降。这种模式不仅增加了延迟，还提高了故障传播的风险，尤其是在高流量场景下，会对系统的稳定性和可扩展性构成严重挑战。
真实场景
以客户服务系统为例，处理每个客户工单请求时，系统需要同步调用多个外部服务，如客户服务以获取客户信息、账户服务以获取账户详情、通知服务以发送通知。在高并发流量下，这种设计模式可能导致网络资源耗尽或服务响应缓慢，严重影响用户体验。
实用解决方案
- 减少同步调用：将多次 API 调用合并到单个聚合调用中，封装在一个独立的网关或终端节点后统一处理。这不仅减少了网络请求，还提升了整体效率。
- 引入异步通信：采用异步通信机制（如 RabbitMQ 或 Kafka），尤其适用于通知服务等无需实时响应的场景。异步模式可以有效解耦服务间的直接依赖。
- 缓存和非规范化：使用数据缓存或非规范化策略，预处理和存储读取优化的数据，以减少对实时请求的依赖。例如，将相关的客户和账户信息提前整合，以便直接响应查询请求，而无需多次调用其他服务。
专业建议
进一步提升系统性能的策略包括构建读取优化管道，通过变更数据捕获 (CDC) 技术实时更新非规范化数据。可以利用 Kafka 等流处理工具搭建数据流管道，当数据源发生变更时，系统自动生成非规范化的读取副本。这种方法使用户请求能够直接访问预处理的数据，避免了实时解析复杂关系的开销，从而显著减少系统延迟和压力。
4.服务边界定义不明确
问题
服务的职责范围如果定义不清晰或存在重叠，会导致系统复杂化，使维护变得困难。同时，模糊的边界关系也会引发所有权不明确的问题，增加协调成本。
真实场景
在某电子商务系统中，假设一个“产品服务”负责处理产品创建、库存更新以及客户评论。由于这些职责相互独立且功能复杂，将它们归于同一服务会导致代码臃肿、不相关逻辑纠缠，并最终使系统难以扩展。
实用解决方案
采用领域驱动设计 (DDD) 原则，根据业务功能而非技术需求划分服务。例如，将“库存管理”“客户评论”和“产品创建”拆分为独立的微服务，确保每个服务专注于单一领域。清晰的功能分界能够提高服务自治性，同时减少服务间的耦合。
专业建议
为每个微服务设立对应的跨职能团队，确保领域知识与技术所有权一致。这样不仅能够快速响应业务需求，还能减少因职责不明带来的沟通障碍。
5.通信协议不一致
问题
在微服务架构中，如果通信协议没有统一标准，频繁混用 REST、gRPC 和 WebSockets 等协议，可能会造成维护困难，并增加集成复杂性。开发人员需要理解并适应不同协议的特点，学习曲线陡峭，排障成本高。
真实场景
传统微服务系统可能使用 REST 处理外部 API 请求，同时在某些内部服务之间采用 gRPC，而事件通知则依赖消息传递系统。这种多样化的协议选择缺乏一致性，开发人员必须深入理解每种技术的差异和用法，导致项目复杂度增加。
实用解决方案
根据使用场景对通信协议进行标准化。例如：
- 外部接口：采用 REST 作为主要协议，便于跨平台兼容。
- 内部调用：对低延迟和高性能要求的场景，优先选择 gRPC。
- 事件驱动架构：利用消息队列（如 RabbitMQ 或 Kafka）实现异步事件通知。
为团队提供清晰的文档和工具以支持标准协议的实现，同时定期审查实际使用情况以确保遵循设计理念。
专业建议
采用服务网格（如 Istio 或 Linkerd），统一管理服务间的通信协议和流量控制。服务网格可以简化跨服务调用的配置，同时提高监控和故障排除能力，帮助实现标准化和展示一致。
6.缺乏可观察性
问题
当服务运行状况、交互方式和性能缺乏可见性时，诊断问题的难度将大幅增加。这种情况会削弱系统的弹性和恢复能力，特别是在复杂的分布式系统中。
真实场景
例如，在一个支付系统中，如果某服务出现故障，这种问题可能通过服务之间的交互链发生级联效应。然而，由于缺乏全局视角和系统级的监控手段，定位根本原因往往需要开发人员手动检索和分析各服务的分散日志，导致问题解决效率低下。
实用解决方案
- 分布式跟踪：采用工具如 OpenTelemetry，通过跨服务传播交易 ID，帮助开发人员追踪请求在整个系统中的流转路径，快速发现问题根源。
- 集中式日志管理：引入 ELK 堆栈（Elasticsearch、Logstash、Kibana）等集中式日志解决方案，将所有服务的日志集中到一个平台，便于快速检索和分析。
- 指标采集与监控：使用 Prometheus 等工具收集系统性能指标，并通过 Grafana 等可视化工具监控服务运行状况。
专业建议
建议从基础日志记录开始，随着系统复杂性增加，逐步引入分布式跟踪和高级监控功能。同时，设置预警阈值，结合监控系统自动发送告警通知，从被动诊断转向主动预防。
7.硬编码配置
问题
硬编码的配置（如数据库 URL、密钥或服务终端节点）不仅会限制部署的灵活性，还可能造成严重的安全风险。配置的泄露可能导致敏感信息暴露甚至系统被攻击。
真实场景
例如，生产环境的数据库连接字符串直接硬编码在源代码中。如果开发人员将代码提交到版本控制系统，该敏感信息可能意外暴露。此外，某些外部脚本（如自动化工具）也可能包含硬编码配置，增加了管理难度。
实用解决方案
- 外部化配置：将所有配置（如连接字符串和密钥）从源代码中移除，存储在环境变量、配置管理系统（如 Consul）或 Kubernetes 的 ConfigMaps 和 Secrets 中。
- 自动化管理：在 CI/CD 流水线中集成安全扫描工具，检测代码中的硬编码配置，并在部署前阻止可能的安全风险。
专业建议
定期审核配置文件和密钥的安全性，确保访问权限仅限必要范围。可以通过在 CI/CD 管道中集成自动化脚本，在构建源代码之前扫描潜在的硬编码敏感信息，避免人为错误造成的安全漏洞。
8.忽视网络可靠性和延迟
问题
微服务架构由于依赖分布式网络通信，其稳定性容易受到网络故障和延迟的影响。如果未采取有效措施缓解网络问题，可能会引发服务挂起、超时甚至全系统失效。
真实场景
例如，当一个服务调用外部支付提供商的 API 时，如果网络请求超时且没有超时保护或重试机制，下游服务可能被阻塞，进而导致整个交易流程中断。
实用解决方案
- 实施弹性模式：采用工具如 Resilience4j 实现断路器模式，防止服务因频繁失败请求而过载；配置指数回退重试策略，以智能化地重新尝试失败的请求。
- 设置超时保护：定义合理的超时时间，避免请求长时间挂起。
- 负载均衡：通过负载均衡器分散请求压力，防止单一服务因过载而失效。
专业建议
引入服务网格（如 Istio）为系统提供内置的弹性功能，如自动流量控制和故障注入测试。通过模拟网络延迟和故障场景，验证系统在极端情况下的可靠性。
9.API 版本控制不足
问题
在缺乏有效版本控制的情况下，对 API 进行破坏性变更（如修改请求/响应结构或以非向后兼容的方式更新功能）可能导致依赖该 API 的客户端应用程序无法正常运行。这种不兼容会引发紧急回滚或代价高昂的修复。
真实场景
假设一个 REST API 更新了请求有效负载的结构，但未通知客户端开发团队。结果，多个客户端应用程序因调用失败而中断，进而影响最终用户体验。
实用解决方案
- 采用版本控制策略：对 API 进行显式版本化，例如通过 URL 路径（如 /v1/resource）或 HTTP 头信息明确区分不同版本。
- 管理弃用周期：在引入新版本的同时，提供明确的迁移计划和过渡期，避免强制客户端立即调整。
- 清晰的变更通知：通过文档和公告及时传达 API 的变更内容，确保使用者了解和适应。
专业建议
使用 OpenAPI 等工具自动生成和管理 API 文档，跟踪变更历史并简化开发人员对新版本的适应过程。此外，考虑在 API 网关中添加版本路由逻辑，以同时支持旧版和新版 API，进一步减少迁移带来的冲击。
10.为基础设施问题重新造轮子
问题
尝试自行开发服务发现、运行状况检查或负载均衡等基础设施功能，往往既耗费资源，又增加了维护复杂性。这类定制解决方案容易出现兼容性问题，并且占用了本应聚焦于业务功能开发的时间和精力。
真实场景
例如，构建一个自定义的服务发现工具，不仅需要处理多环境部署的复杂性，还可能随着微服务数量增加而暴露出性能和兼容性问题，最终造成运营负担。
实用解决方案
- 使用标准化工具：采用经过验证的开源或商用工具，如 Kubernetes，来处理服务发现、运行状况检查和负载均衡等基础设施需求。
- 借助服务网格：通过服务网格（如 Istio 或 Linkerd），实现跨服务的一致流量管理策略、运行状况监控和故障注入测试，从而避免重复开发基础设施功能。
专业建议
将团队的工程重点放在业务逻辑和客户价值上，而非重新构造已有的基础设施组件。这种方法不仅减少了开发和维护成本，还可以利用社区和现成生态系统的支持来快速解决问题。
结论
构建可扩展的微服务架构既充满机遇，也伴随着挑战。通过识别和解决常见的反模式（如分布式单体架构、跨服务共享数据和过度同步调用），可以显著提升服务的独立性、弹性和扩展能力。
在实际的项目设计中，约束条件往往需要我们在理论与实践之间找到平衡。例如，在数据分离中，可能需要临时采用封装的 API 访问共享数据；在选用 MongoDB 等灵活数据库时，则需格外关注隐式依赖带来的风险。微服务的成功在于明确的边界定义、一致的通信标准以及强大的可观察性能力。
根据实际情况，将技术决策与业务需求相结合，充分发挥微服务的优势，并有效规避常见陷阱。这种方法不仅有助于提升团队效率，还能为系统的长期可持续性打下坚实基础。
作者介绍
刘汪洋，51CTO社区编辑，昵称：明明如月，一个拥有 5 年开发经验的某大厂高级 Java 工程师。
原文标题：10 Microservices Anti-Patterns to Avoid for Scalable Applications，作者：Abhishek Goswami
