微服务——好的、坏的、丑陋的

微服务架构

微服务架构的一般优势

微服务架构的常见问题

何时不应考虑微服务架构

何时可以考虑微服务架构

最初发表于deepu.tech。

你参加了一场精彩的会议，会上一位又一位演讲者大谈微服务有多么棒。你听到科技巨头的演讲者介绍他们如何利用运行在容器上的微服务来扩展规模并解决问题，你不禁想，我们是不是也应该效仿一下？

现实情况是，软件工程中没有灵丹妙药。微服务并不能神奇地解决所有扩展问题，有时它们带来的问题比解决的问题还多。

好吧，这不是一篇抨击微服务的文章，作为一个喜欢微服务架构的人（有时是因为它们的复杂性，有时是因为它独创性），我认为了解在实际用例中实施微服务架构的成本非常重要。我在我的书中也简要讨论过这个问题。

微服务架构

在微服务架构中，通常将领域模型拆分为多个松耦合的服务，这些服务可以单独部署和扩展。
每个服务本身就是一个小型应用程序，拥有自己的架构，有时甚至有自己的运行时。

这些服务可能提供 REST 端点，可以由充当网关的应用程序进行聚合，或者服务之间可以使用消息系统相互通信。有些服务可能具有 Web GUI，有些则是仅提供 API 的无头服务。

在微服务架构中，每个服务负责处理其自身数据，理想情况下不与其他服务共享数据库模式。
这种架构可以轻松为移动和桌面体验提供不同的客户端，并可根据需求独立扩展。

构建微服务有不同的架构模式。所使用的模式也决定了服务通信的方式和聚合的方式。

本文非常详细地介绍了其中一些模式。

因此，让我们分析一下微服务架构的优点和问题，看看何时采用微服务架构是有意义的，何时避免采用微服务架构。

微服务架构的一般优势

一般来说，微服务提供（这取决于你如何实际实现它）或至少承诺以下好处，可分为三大类

松散耦合

微服务组件比传统架构更加松散耦合。
这类系统采用事件驱动或消息驱动的架构来实现松散耦合组件之间的通信。
这使得组件隔离性更好，更容易进行单元测试，并加快启动速度。

这样的系统还提供了其他好处，例如，某个服务中的内存泄漏被隔离，因此不会导致整个应用程序崩溃。因此，整体单点故障减少了。

松散耦合的单个组件的启动速度比大型整体组件快得多，从而可以并行化并改善大型系统的整体启动。

它还可以轻松重构现有功能，因为您可以逐步重构事物，而不必一次性重构整个系统。

由于这种松散耦合，每个服务都可以选择使用更合适的数据库/数据存储，而在单体式架构中，你可能需要妥协地选择单一数据库类型。
例如，处理大量非结构化数据的服务可以选择 NoSQL 数据库，而处理事务或结构化数据的服务则可以选择 SQL 数据库。

更快的开发和发布周期

在实施良好的微服务架构中，开发周转速度更快，因此您可以更好地将新功能推向市场，并更轻松地重构现有功能。

通过将复杂的问题域拆分为单独可管理的服务，可以轻松解决该问题域，从而更易于理解和长期维护。

技术采用更容易，组件可以在增量迁移中独立升级，从而可以为每个组件提供不同的堆栈。

系统中的不同微服务也可以使用不同的实现语言，并且仅使用通用消息格式（如 gRPC 或消息队列或发布/订阅）进行通信，
从而使团队能够拥有不同的语言技能，从而减少对单一语言或堆栈的依赖。

由于系统之间的通信由公共 API 或合同管理，因此团队之间的依赖性会降低，从而让您可以更改内部结构而不必担心破坏别人的代码。

最适合敏捷团队。这类团队可以更专注，因为他们只需要关注一项服务。

细粒度扩展

微服务架构最重要的优势之一是能够根据负载扩展各个组件。
如果实施得当，这将实现理想的负载分配，并降低整体基础设施成本。
需求较大的服务可以扩展，而需求较小的服务可以缩减，从而更高效地利用基础设施。

独立部署服务还可以使应用程序更加可靠，并使修补更容易，因为您不必升级整个应用程序来修复单个服务中的问题。

可以建立更复杂、更高效的扩展模型。关键服务可以更有效地扩展。基础设施得到更高效的利用。

持续交付这种复杂的应用程序也比同等的整体应用程序更容易，因为组件更小，并且部署中的任何问题都可以轻松地在每个组件上进行调查和纠正

微服务架构的常见问题

不管什么架构，微服务架构同样也存在缺点。

复杂

复杂性是这种架构最大的副作用之一。虽然微服务可以通过将问题分解为更小的服务来降低领域复杂性，但
分布式系统在以下方面仍存在复杂性：

• 整体堆栈，因为不同的组件可能具有不同的技术堆栈，迫使团队投入更多时间来跟上它们。
• 扩展效率更高，但需要服务发现、DNS 路由等高级功能。
• 组件之间的通信可能需要消息系统（队列、PubSub、事件存储）。
• 分布式系统上的业务事务可能涉及更新多个数据库，这使得回滚更加复杂且容易出错。
• 整个应用程序的部署更加复杂，因为涉及容器、编排和虚拟化的复杂性。
• 需要复杂的基础设施。通常需要容器（Docker）、业务流程管理（Kubernetes）以及多个 JVM 或应用程序容器来运行。

集成测试

由于堆栈中移动部件增多，组件间通信更加复杂，端到端测试和集成测试的执行难度加大。
所需的测试基础设施的搭建和维护也变得更加困难。

团队规模和经验

微服务的技术堆栈更加复杂，而且大多数时候更难学习，因此它需要一支比类似的单片应用程序所需的更有经验、拥有更高级技能的团队。

由于涉及更多组件和技术，因此还需要更大的团队来维护应用程序。

实施跨多项服务的需求需要更多的前期时间来就合同和 API 达成一致。

团队成员根据他们所从事的组件共享不同的技能组合，但可能无法鸟瞰整个应用程序，这使得业务需求更难以可视化，并且跨领域问题更难以解决。

开销

复杂的微服务将产生运行监控设置、消息服务、编排、服务注册等额外的开销。

由于复杂性，初始开发时间会更长，从而导致上市时间变慢。

初始基础设施的总体成本可能比类似的整体成本高得多。

在微服务架构中，服务之间总是存在代码重复，这也可以被视为开销。

何时不应考虑微服务架构

除非万不得已，否则不应使用微服务架构。请记住，并非所有应用程序都像 Netflix、Google、Amazon 或 Spotify 那样对规模有如此高的要求。
微服务架构为这类应用程序带来的许多好处都源于其强大的规模，而这可能并不适用于您。
因此，以下是一些不选择微服务架构、或许应该坚持使用单体架构的理由。

• 当你的应用程序规模较小，并且你知道它不会发展成像 Facebook 那样的规模时。对于定义明确的简单用例，单体应用始终是最佳选择。例如
  • 用于公司内部用例的 CRUD 应用程序。
  • 一个用户群非常小众的小型应用。比如销售一些特色商品的购物网站。
• 当新应用的上市时间至关重要时。微服务的初始上市时间会更长。
• 当你的团队规模较小或团队平均经验较少时，最好从单体应用开始。
• 当你的基础设施预算有限时，虽然从长远来看，微服务可能有助于节省资金，但在初期，它会让你花费更多。

最重要的是，不要因为微服务炒作、热门公司使用或知名人士推荐而选择它。对于大多数用例而言，单体架构仍然是一个不错的解决方案，即使你从单体架构入手，也可以根据需要拆分成微服务。

何时可以考虑微服务架构

一般来说，如果您有以下情况之一，微服务往往会有所帮助。

• 当您的用例领域很复杂时，您拥有一支经验丰富的大型团队，将其拆分会使其更容易实施。
• 当你期望在用户量方面成为下一个 Facebook、Netflix 或 Twitter 时。理想情况下，当你期望拥有指数级的用户群时。
• 如果你的应用程序将为其他拥有大量用户的应用程序提供 API，例如社交媒体应用程序使用的支付网关或库存服务
• 当你有一个流行的电子商务应用程序，拥有庞大的用户群，但应用程序中不同服务的负载不均衡时，是时候将它们拆分成微服务了。

所以总而言之，不要因为某种架构模式对别人有用就选择它，而要选择适合你的用例、规模和需求的模式。
并非每个人都需要处理数百万并发用户或传输 TB 级的数据。

如果你喜欢这篇文章，你也可能会喜欢我的书。你可以在Packt和亚马逊上购买。

如果您喜欢这篇文章，请点赞或留言。

如果您决定构建微服务，请查看 JHipster 和我下面的文章，别忘了在Github上给它一颗星。

1. 使用 JHipster 域语言在 30 分钟内创建完整的微服务堆栈
2. 在 Azure Kubernetes 服务（AKS）上部署 JHipster 微服务
3. JHipster 微服务与 Kubernetes 上的 Istio 服务网格

您可以在Twitter和LinkedIn上关注我。

封面图片由Sergei Akulich在Unsplash上拍摄