微服务架构进化：从业务加一堆横切代码到 Sidecar 解耦

本文要点： Sidecar 模式将横切关注点从业务逻辑组件中解耦出来，从而提升可维护性并降低复杂度。Sidecar 可以与微服务一同构建，但也可以使用与微服务本身不同的技术栈来实现。Sidecar可以在多个服务之间复用，为配置、日志、追踪以及发布-订阅消息传递提供开箱即用的支持。Sidecar 模式能够在不增加复杂性的前提下，降低组件之间的耦合度，并提升基于微服务应用的可扩展性、可维护性和效率。虽然 Sidecar 非常适合为实现横切能力提供开箱即用的支持，但对于极度延迟敏感的工作负载，你通常可能不会选择使用它，以避免额外的网络跳转和资源开销。 如今的应用程序需要监控、日志记录、配置管理等能力。这些关注点中的每一个都可以实现为组件或服务。这些横切关注点也可以与应用程序紧密集成。虽然这种紧耦合能够确保共享资源被高效利用，但其中任何一个组件发生故障，都可能导致整个应用程序宕机。这时，Sidecar 设计模式便派上了用场。 Sidecar 设计模式能够帮助动态服务（即微服务）持续获得其所需的资源和数据，同时保持轻量化，避免背负大量内部逻辑带来的负担。在本文中，我们将探讨 Sidecar 设计模式、它的优势，以及如何在基于微服务的应用程序中实现它。我们还将讨论在使用 Sidecar 时通常会遇到的常见问题，以及如何缓解这些问题。 准备工作 要运行本文讨论的代码示例，你的系统中应安装 Visual Studio、ASP.NET Core 和 Docker。请注意，当你在计算机上安装 Visual Studio 时，也可以通过 Visual Studio Installer 同时安装 ASP.NET Core。 下载 Visual Studio 和 Docker Desktop。你还需要 Elastic Search，我们将通过 NuGet 来安装它。 什么是微服务架构？ 微服务架构由一组使用不同语言和技术构建的服务组成。管理这些特定语言接口的依赖关系，通常会增加大量复杂性。此外，由于其分布式特性，微服务架构还会带来多种挑战。 在构建基于分布式微服务的应用程序时，处理日志记录、身份认证和授权等横切关注点可能会非常困难。而这正是 Sidecar 模式能够发挥作用的地方。 什么是 Sidecar 设计模式？ Sidecar 模式通过将应用程序组件部署到独立的进程或容器中，帮助实现组件的隔离与封装。之所以称为 “Sidecar（边车）”，是因为这种设计模式类似于连接在摩托车旁边的边车。从本质上来说，Sidecar 设计模式能够帮助你构建由不同组件和技术组成的应用程序。 Sidecar 设计模式通常通过容器来实现，其中被称为 “Sidecar” 的辅助容器会与主应用程序一同运行。 这些 Sidecar 容器为应用程序提供额外功能，并负责那些不需要包含在主应用中的任务，例如日志记录、监控、配置和安全等。 图 1. Sidecar 示意图 Sidecar 与父应用程序紧密关联，其生命周期与父应用类似，并会与父应用一起构建和销毁。如果你在承载 ASP.NET Core 微服务的主容器旁边使用 Sidecar 容器，那么主容器将负责应用程序的核心业务功能，而 Sidecar 容器则负责辅助性职责，例如： 日志记录监控分布式追踪安全策略执行服务发现流量路由通信 为什么我们需要 Sidecar 设计模式？ 下面快速概览一下 Sidecar 设计模式的优势： 通过将横切关注点隔离到独立组件中，并使其独立于主应用运行，从而降低复杂性。与语言无关，因此你可以使用多种不同的编程语言来构建它通过包含所有必要模块并与微服务一同运行，减少代码冗余。通过使用 localhost/共享网络降低延迟（尽管与进程内方案相比，Sidecar 仍可能引入一定延迟）。通过将 Sidecar 作为独立进程附加到同一主机或子容器中，增强扩展性，使应用能够按需扩展。 在分布式应用中实现日志记录的挑战 在本节中，我们将探讨分布式应用在日志记录方面面临的挑战，并理解 Sidecar 设计模式如何在这里发挥作用。 问题：基于微服务应用中的日志开销 日志记录是一种横切关注点，通常用于在应用程序运行期间捕获并存储事件记录。在分布式应用中，日志更常用于监控应用运行时行为、采集与性能相关的元数据，以及定位问题。 然而，在典型的基于微服务的应用程序中，日志可能会带来显著开销。例如，由于分布式服务中的日志数据量巨大，以及日志收集、聚合和传输到后端组件时对 CPU、内存和网络等资源的额外消耗。 结果就是，应用延迟增加，同时吞吐量下降。此外，由于微服务具有短暂性（ephemeral），在动态环境中聚合日志也会更加困难。你需要使用关联 ID（Correlation ID）来关联分布式微服务，但这又会带来额外的处理开销。 解决方案：使用 Sidecar 模式解耦日志功能 Sidecar 设计模式可以帮助缓解上述挑战。它能够实现关注点隔离，按照应用需求格式化数据，并降低复杂性和代码冗余。你可以利用 Sidecar 设计模式，在不修改主应用代码库的情况下，统一应用中的日志记录方式、收集指标数据并监控应用健康状态。 使用 Sidecar 模式在微服务架构中实现分布式日志 在本节中，我们将探讨如何在基于微服务的应用程序中实现分布式日志，以及 Sidecar 容器如何帮助为每个微服务收集并整合日志。为了构建这个应用程序，我们将使用以下技术和工具： Visual Studio（IDE）ASP.NET Core（Web 应用开发框架）C#（编程语言）Docker Desktop for Windows（容器化工具）Elasticsearch（通过 NuGet 安装） 这个应用程序模拟了一个典型的库存管理系统，由两个微服务组成（即 Transactions API 和 Sidecar API）。前者作为生产者发送日志消息，而后者负责消费这些消息并将其发送到 Elasticsearch。 需要注意的是，Transactions API 并不会直接调用 Sidecar API。相反，Transactions 控制器中的 Create 操作方法会将日志消息发送到一个并发队列中，该队列随后会将消息存储到本地文件系统共享目录中的文本文件里。Sidecar API 会从共享目录中读取这些存储的消息，对其进行处理，然后再发送到 Elasticsearch。 下面是该应用程序的完整流程概览： 客户端调用 TransactionsController 中由 Create 操作方法表示的 HTTP Post 端点。Create 操作方法不会直接写入磁盘或直接发送消息到 Elasticsearch，而是将消息添加到一个自定义并发队列中。控制器立即返回 HTTP 响应；日志持久化被卸载到后台服务中处理。TransactionsAPI 中的后台服务使用线程安全的文件日志记录器，将这些消息持久化到共享目录中的文本文件。在 SidecarAPI 中，另一个后台服务从本地文件系统读取这些日志消息。最后，SidecarAPI 的后台服务将日志消息发送到 Elasticsearch。 在这个应用程序中，我们将创建以下类型： Tr