Kubernetes

十多年来，Spring Boot 一直是构建企业 Java 应用程序的事实上的标准。其丰富的生态系统、约定优于配置的范例、强大的依赖注入引擎和广泛的社区支持使 Java 成为全球后端系统的基石。 然而，向云原生架构、Kubernetes 编排、Docker 容器化和无服务器执行（AWS Lambda、Knative） 的转变给后端基础设施带来了新的技术挑战：内存效率、即时扩展和冷启动延迟。 传统的 Java 框架是为长期运行的整体服务器而设计的，最初并不是为短暂的容器化环境而设计的。当微服务在 Kubernetes 上从 0 个实例水平扩展到 50 个实例或作为短期无服务器函数执行时，等待 3 到 10 秒等待 Java 虚拟机 (JVM) 进程启动（同时消耗 200MB 以上的堆内存）会带来运营和财务障碍。 输入 Quarkus：一个从头开始构建的 Kubernetes 原生 Java 框架，专为 GraalVM 和 OpenJDK HotSpot 定制 Java。 Quarkus 被称为“超音速亚原子 Java”*，从根本上重新定义了 Java 代码的编译、启动和执行方式。 在本架构比较指南中，我们将在核心架构、运行时内存、冷启动时间、开发人员体验、响应式模型、生态系统成熟度和可操作的决策框架等方面详细分析 Quarkus 与 Spring Boot，以帮助您为下一个项目选择正确的框架。 1. 核心架构理念 Spring Boot 和 Quarkus 之间的根本区别在于何时应用程序元数据、依赖关系连接和配置扫描发生：运行时与构建时。

在现代云原生系统中，微服务的作用不仅仅是运行业务逻辑。他们必须处理日志记录、管理 SSL/TLS 证书、收集指标、实施重试机制以及协调与其他服务的安全通信。 如果我们将所有这些横切功能直接嵌入到每个应用程序的代码库中，最终会导致代码膨胀、紧密耦合和语言锁定。 这就是 Sidecar 模式 的用武之地。在本指南中，我们将使用简单的类比和 Kubernetes 配置示例来详细介绍 Sidecar 模式是什么、为什么它对于现代微服务架构至关重要，以及它是如何工作的。 现实世界的类比：摩托车边车 理解这种模式的最简单方法是想象一辆带边车的摩托车。 想象一下您有一辆高性能摩托车。它的设计初衷是为了出色地完成一件事：快速运送一名乘客。现在，假设您需要携带乘客行李或添加额外的座位。 您可以完全重新设计摩托车的车架、发动机和车轮，将其变成汽车。然而，这需要付出巨大的努力，破坏了自行车的简单性，并且使其难以维护。 相反，您附加一个 sidecar。 边车是一个独立的、独立的单元，连接到摩托车。它共享摩托车的旅程，摩托车去往任何地方，并且紧密配合运行。然而，摩托车的核心发动机仍然没有受到影响。 在软件架构上： 摩托车 是您的主要应用程序容器（运行核心业务逻辑，例如结账或用户身份验证）。 Sidecar 是一个单独的帮助容器（运行实用程序任务，例如 SSL 终止、监控或日志传送）。 旅程是部署的生命周期（例如，Kubernetes Pod）。 问题：交叉关注点和代码膨胀 在 sidecar 出现之前，开发人员必须将辅助库直接包含在他们的应用程序代码中。例如，如果您想将日志发送到中央服务器，则可以导入日志库。如果您需要指标，则添加了指标 SDK。 这种基于库的方法带来了几个重大挑战： 语言锁定：如果监控库仅用 Go 编写，则无法轻松在 Python 或 Java 微服务中使用它。您必须为堆栈中的每种语言找到或构建一个库。 代码污染：业务逻辑因用于重试、服务发现、加密和日志记录的基础设施特定代码而变得混乱。 复杂升级：如果在通信库中发现安全漏洞，每个微服务都必须更新其依赖项、重新编译和重新部署。 资源争用：帮助程序代码与主应用程序在同一运行时进程中运行，这意味着记录器中的内存泄漏可能会导致整个核心应用程序崩溃。 解决方案：Sidecar 模式 Sidecar 模式通过将辅助任务移出主应用程序进程并将其放入紧邻应用程序运行的单独的独立进程中来解决这些问题。