本文翻译自 How To Understand Microservices Architecture (opens new window)，作者 OLEKSII (opens new window)
单体式架构的问题随着应用程序的增长而出现。为了克服这些挑战，可以使用微服务架构。然而，这并非灵丹妙药。这种架构有其自身的优点和缺点。
# 微服务架构概览
一个应用程序被分成多个小型服务（用户服务、航班服务、计费服务等），负责特定的有限范围。每个服务都在自己的数据库上运行，并具有各自的特性。用户界面通常向网关发出请求。网关负责将请求路由到特定服务。
网关还可以包含交叉问题，如身份验证。每个服务都可以单独支持、管理和部署。但是，它们应该以某种方式相互通信。不同的通信方法不在本文讨论范围之内，我们将单独讨论。
# 微服务架构的优势
# 高内聚、低耦合
除通信点外，每个服务都是独立的。因此，每个组件可以由不同的团队开发。错误和功能可以在单个服务中修复和部署。服务规模小，部署时间短。
# 服务范围有限
这些服务通常规模较小。因此通常更容易理解。在单个服务范围内，调试过程和测试都很简单。
# 灵活性
服务可以在自己的数据库上运行，并具有所需的特性。它可以是 RDBMS，也可以是 NoSQL，还可以两者都是或都不是。此外，服务可以用不同的编程语言编写。
# 可扩展性
各组件可独立扩展和优化。性能特征没有限制。例如，一个应用程序可以有两个用户服务实例和十个飞行服务实例。针对特定服务，RDBMS 数据库可以替换为单一用途的 NoSQL 数据库。正因为如此，微服务对于大型应用程序来说也很划算。
# 尖端技术，微服务规模小
因此，可以通过实验来验证某些想法或解决方案。它们可以快速重写。此外，迁移到新的平台版本也非常简单。例如，从 Java 8 迁移到 Java 11。 ● 开发速度快。很多框架都经过优化，可用作微服务（如 Spring Boot）。另一个优势与 CI/CD 管道有关。服务规模小，因此管道速度快。
# 微服务架构的劣势
# 调试
在单个组件范围内工作时，一切都很简单。然而，整个架构却是复杂的。一个请求可以在多个服务上运行。很难跟踪它并理解系统。数据流通常很难理解，尤其是对于新团队成员来说。
# 测试
由于组件是分布式的，因此测试具有挑战性。
# 部署
服务可以单独部署。不过，它们通常会以某种方式进行通信。服务之间的交互合约必须严格定义。一个服务的更改不应破坏其他服务。
# 沟通
每个组件可以由不同的团队开发。因此，必须对变更进行通信。这会带来通信开销。
# 基础设施开销
一方面，数据位于不同的地方。另一方面，从业务角度看，一个服务中的数据应该用于另一个服务。应该以某种方式处理服务之间的交互。这通常要么是数据复制，要么是服务间的额外调用。
# 贯穿各领域的问题
应在每个服务中实施安全、日志、监控、配置等功能。
# 总结
总而言之，微服务架构为小型项目带来了额外的复杂性和更高的成本。不过，对于大型应用程序来说，微服务可以节约成本，影响系统的高性能，并加快开发速度。