应用程序中的微服务：扩展用例

随着数字产品开始快速扩展，微服务成为一个流行术语。我们的承诺很明确：将系统划分为更小的部分，以提高速度、弹性和团队自主权。但微服务并不是通用的解决方案。在某些情况下，它们有很大帮助；在另一些情况下，它们会造成不必要的复杂性。因此，了解何时以及如何申请至关重要。

本指南介绍了微服务有意义的用例、最常见的风险，以及为那些想要安全扩展的人提供的分步指南。重点是实用，有比较和明确的指导。

什么是微服务

微服务是一种将应用程序划分为更小的独立服务的架构。每个服务负责特定的功能，拥有自己的[数据库0，并且可以单独开发和部署。

您拥有多个通过 API 进行通信的服务，而不是单个系统 ([monolith1´)。这允许可扩展性和并行开发。

单体应用与微服务

一个简单的比较可以帮助您理解：

外观	巨石	微服务
初始复杂度	低	高
可扩展性	有限公司	高
部署	独特	独立
保养	一开始很简单	如果管理不善则复杂
韧性	低	高

一开始，[monolith2] 比较简单。当规模和复杂性保证时，微服务才有意义。

当微服务有意义时

在以下情况下建议使用微服务：

• 该产品有几个不同的领域。
• 大型团队需要独立工作。
• 可扩展性是一个真正的问题。
• [monolith3] 的部署时间成为瓶颈。
• 可靠性需要很高。

如果您仍在验证产品，微服务可能有点大材小用。他们必须解决实际问题，而不是制造新问题。

应用程序中的用例

案例 1：市场

市场有不同的领域：目录、订单、支付、交付、支持。每个人都以不同的速度成长。例如，微服务允许您在不影响目录的情况下扩展订购服务。

案例2：金融应用

金融应用程序需要弹性。微服务允许您隔离关键功能，确保通知失败不会影响付款。

案例3：具有独立模块的SaaS

如果每个客户端使用不同的模块，微服务允许您仅激活必要的服务。这降低了成本并提高了性能。

案例 4：流媒体应用

流媒体需要内容和推荐的高可扩展性。微服务将推荐算法与主服务隔离。

这些案例表明，当有明确的领域和真正的可扩展性时，微服务更有意义。

真正的好处

• 按需扩展：每项服务根据使用情况进行扩展。
• 弹性：孤立的故障不会导致整个系统瘫痪。
• 团队自治：每个团队都可以发展其服务。
• 部署速度：小改动不需要完全部署。

如果实施得当，收益是显着的。

风险与挑战

微服务不是免费的。他们带来了挑战：

• 服务之间通信的复杂性。
• 需要[可观察性4和监控。
• 难以保持数据一致性。
• 运营成本增加。
• 更多地依赖 DevOps 和 [SRE5。

如果团队没有做好准备，结果可能会比[单体6]还要糟糕。

安全迁移策略

如果您使用的是 [monolith7] 并且想要迁移，请使用渐进的方法：

1. 确定最孤立的域。
2. 提取到单独的服务。
3. 定义清晰的API。 4.实施强有力的监控。
4. 重复该过程。

一次性迁移所有内容是有风险的。逐步进化降低了风险。

数据一致性

在微服务中，每个服务都可以有自己的银行。这带来了一致性挑战。常见策略：

• 最终一致性。
• 事件和队列。
• 传奇模式。

团队必须承认，即时一致性并不总是可能的。这需要与产品保持一致。

可观察性作为要求

如果没有[可观察性8，微服务就会变得混乱。您需要：

• 集中日志。
• 分布式追踪。
• 每项服务的指标。
• 智能警报。

这使您可以快速识别故障。如果没有这个，调试就变得不可能。

基础设施和成本

微服务需要更强大的基础设施。您需要：

• 编排（容器，[Kubernetes9]）。
• 高效的 CI/CD。
• 配置管理。
• 持续监控。

成本会增加，但可以通过可扩展性来抵消。

如何决定：快速清单

迁移前请使用此清单：

• [单体 10 成为真正的瓶颈吗？
• 是否有足够的团队来维护服务？
• 产品是否需要高可用性？
• 当前的复杂性是否阻碍了进化？
• 团队在 DevOps 方面成熟吗？

如果大多数人是否定的，那么微服务可能还不是正确的选择。

真实失败案例

并非一切都是成功。一些案例：

• 早期迁移并在基础设施上花费更多时间而不是在产品上的小型初创公司。
• 没有[可观察性11] 的团队无法调试问题。
• 具有循环依赖关系的系统变得比 [monolith12] 更加复杂。

这些案例表明微服务需要做好准备。

真实的成功案例

• 大型市场隔离支付以确保弹性。
• 使用微服务来实现合规性和可扩展性的金融应用程序。
• 快速发布模块的SaaS平台。

这些例子展示了架构经过精心规划后的潜力。

微服务和产品

架构不仅仅是一个技术决策。它影响产品。微服务可以让您更快地推出功能，但如果团队失去焦点，它们也可能会延迟。该决策需要考虑对路线图、成本和速度的影响。

结论

微服务是扩展应用程序的强大工具，但它们并不能解决所有情况。当有明确的领域、成熟的团队和真正需要可扩展性时，它们就会发挥作用。

如果遵循渐进策略，具有很强的可观察性并注重一致性，微服务可以带来速度和弹性。否则，制作精良的整体结构可能是最好的选择。

另请阅读

• [应用程序中的微服务：小型团队的用例14
• [单体与微服务：实践中的用例15
• 【应用架构：初学者最佳实践16
• [GraphQL应用：真实案例的成本和定价17
• [应用架构：可扩展系统完整指南18
• 【量身定制的数字化解决方案：建筑与真实案例19