(51条消息) SpringCloud和Kubernetes在微服务层面对比

2021-01-06 18:58:30

Spring Cloud 和 Kubernetes 都声称自己是开发和运行微服务的最佳环境，但它们在本质上有很大的不同，解决的问题也不同。在本文中，我们将看看每个平台是如何交付基于微服务架构(MSA)的？它们擅长哪些领域？以及如何充分利用这两个领域在微服务的旅程中取得成功。

背景

最近我读了很多关于用 Spring Cloud 结合容器化构建微服务架构的文章。如果您还没有阅读它，那么您应该多看看，因为它全面概述了如何使用 Spring Cloud 创建一个简单的基于微服务的系统。为了构建一个可扩展且具有弹性的微服务系统，甚至可以扩展到数十个或数百个服务，必须在具有广泛构建时和运行时功能的工具集的帮助下对其进行集中管理和治理。使用 Spring Cloud 过程涉及到实现功能性服务(如统计服务、帐户服务和通知服务)和支持基础设施服务(如日志分析、配置服务器、服务发现、认证服务)。下面是描述这种使用 Spring Cloud 的 MSA 的图表:

来自Spring Cloud

这张图涵盖了系统的运行时方面，但没有涉及打包、持续集成、扩展、高可用性和自修复方面，这些方面在 MSA 世界中也非常重要。假设大多数 Java 开发人员都熟悉 Spring Cloud，在本文中，我们将进行比较，通过解决这些额外的问题来了解 Kubernetes 与 Spring Cloud 之间的关系。

微服务关注点

我们不需要逐个特性进行比较，而是来看看更广泛的微服务关注点，看看 Spring Cloud 和 Kubernetes 是如何解决这些问题的。当今 MSA 的一个优点是，它是一种架构风格，其优点和利弊都得到了很好的平衡。微服务支持强大的模块边界、独立部署和技术多样性，但它们的代价是开发分布式系统和显著的运营、成本开销。因此，这是一个关键的成功因素，关注周围的工具，将帮助您解决尽可能多的 MSA 关注。快速且轻松的开始很重要，但学习研究过程是漫长的，所以你需要足够耐心才能到达。

微服务框架解决问题

在上面的图表中，我们可以看到一个包含最常见的技术关注点的列表(我们不包括非技术关注点，例如组织结构、文化等等)，这些都必须在 MSA 中解决。这是我个人的观点，不同的组织会有不同的看法，但在大多数情况下，它应该适用于每个人。

对比图

这两个平台非常不同，它们之间不存在直接的功能对等。如果我们将每个 MSA 关注点映射到用于在两种平台上解决它的技术/项目上，我们会得到下表。

Kubernetes和Spring Cloud对比图

从上表可以得出的主要结论是:

  • Spring Cloud 有一组丰富的集成良好的 Java 库，可以作为应用程序堆栈的一部分解决所有运行时问题。因此，微服务本身就有库和运行时代理来进行客户端服务发现、负载均衡、配置更新、指标检测等功能。但这些服务都是在 JVM 中进行管理。

  • Kubernetes 支持多种语言，它不仅针对 Java 平台，而且以通用的方式解决了分布式计算的挑战。它在应用程序堆栈之外的平台层上提供了配置管理、服务发现、负载均衡、跟踪、度量、代理、调度作业等服务。应用程序不需要添加任何客户端逻辑库或代理，也可以用任何语言编写。

  • 在某些领域，两个平台都依赖于类似的第三方工具。例如，ELK 和 EFK 栈，链路跟踪库等等。

  • 有一些组件，如 Hystrix、Spring Boot，在这两种环境中都很有用。在一些领域，这两个平台是互补的，可以结合在一起创建一个更强大的解决方案(KubeFlix 和 Spring Cloud Kubernetes 就是这样的例子)。

微服务必要条件

为了说明每个项目的范围，这里有一个(几乎)端到端的 MSA 需求表，从底部硬件开始，到顶部的 DevOps 和自助化部署服务，以及它与 Spring Cloud 和 Kubernetes 平台的关系。

在某些情况下，两个项目使用不同的方法来处理相同的需求，在某些领域，这一个可能比另一个更强。但这两个平台也有一个互补点，可以结合在一起提供更优质的微服务体验。例如，Spring Boot 为构建单个 jar 应用程序包提供了 Maven 插件。Docker 和 Kubernetes 的声明式部署和调度功能使运行微服务变得非常容易。类似地，Spring Cloud 内有丰富的应用程序类库，用于创建弹性、容错等功能，使用 Hystrix(带有熔断、限流和断路器模式)和 Ribbon(用于负载均衡)。但光有这些是不够的，当它与 Kubernetes 健康检查、进程重启和自动扩展等功能相结合才能将微服务变成一个真正的抗脆弱系统。

优点和缺点

由于这两种平台并不是直接按功能进行比较，而是技术层面对比，以下是每种平台的优缺点总结。

Spring Cloud

Spring Cloud 为开发人员提供工具，以快速构建分布式系统中的一些常见模式，如配置管理、服务发现、断路器、路由等。它建立在 Netflix oss 库之上，用 Java 编写，供 Java 开发人员使用。

优点

  • Spring 平台本身提供的统一编程模型，以及 Spring Boot 的快速应用程序开发能力，为开发人员提供了良好的微服务开发体验。例如，用很少的注解就可以完成配置中心服务，用很少的注解就可以让客户端库使用您的后台服务。

  • 有丰富的库可供选择，涵盖了大多数运行时问题。由于所有的库都是用 Java 编写的，所以它提供了多种特性、更大的控制和微调选项。

  • 不同的 Spring cloud 库彼此很好地集成在一起。例如，一个 Feign 客户端也能使用 Hystrix 来做断路器，使用 Ribbon 来做请求的负载。一切都是注解驱动的，易于开发，感觉就像 Java 开发人员的天堂。

缺点

  • Spring Cloud 的一个主要优点同时也是它的缺点——它仅限于 Java。MSA 的一个强大动机是在需要时能够改变技术栈、库甚至语言。这些对 Spring Cloud 来说是不可能的。如果你想消费 Spring Cloud/Netflix OSS 基础设施服务，比如配置管理、服务发现、负载均衡，这个解决方案并不能完美解决。Netflix Prana 项目实现了 sidecar 模式，以在 HTTP 上公开基于 Java 的客户端库，使用非 java 语言编写的应用程序可能存在于 Netflix 生态系统中，但它不是很优雅。此外，自从我写了这篇文章以来，Pivotal 还宣布了一个名为 SteelToe 的新项目，它允许使用 net 客户端的服务发现和配置 Java 服务调用。

  • Java 开发人员有太多的责任去关心和处理 Java 应用程序。每个微服务都需要运行各种客户端，以进行配置检索、服务发现和负载平衡。设置这些很容易，但这并不会隐藏构建时间和对环境的运行时依赖关系。例如，我可以很容易地创建一个带有@EnableConfigServer 注解的配置服务器，但这只是一个简单的方法。每次我想运行一个微服务时，我都需要启动配置服务器并运行它。对于受控环境，我必须考虑使配置服务器高度可用，因为它可以由 Git 或 Svn 支持，所以我需要为它共享文件系统。类似地，对于服务发现，我需要首先启动 Eureka 服务器。对于受控环境，我需要在每个 AZ 上使用多个实例对其进行多副本部署等等。作为一名 Java 开发人员，除了实现所有功能性服务之外，我还必须构建和管理一个重要的微服务平台。

  • 仅仅 Spring Cloud 在微服务领域的应用范围就比较局限，为了获得完整的微服务体验，您还需要考虑自动部署、调度、资源管理、进程隔离、自愈、构建管道等问题。就此而言，我认为将 Spring Cloud 单独与 Kubernetes 进行比较是不公平的，更公平的比较应该是将 Spring Cloud + Cloud Foundry(或 Docker Swarm)与 Kubernetes 进行比较。但这也意味着，要想获得完整的端到端微服务体验，Spring Cloud 必须辅之以 Kubernetes 之类的平台。

Kubernetes

Kubernetes 是一个用于自动化部署、扩展和管理容器化应用程序的开源系统。它是支持多种语言的，并为配置、运行、扩展和管理分布式系统提供了了良好的支持。

优点

  • Kubernetes 是一个多语言的通用容器管理平台，能够运行本地云和传统的容器化应用程序。它提供的服务，如配置管理、服务发现、负载平衡、指标收集、日志聚合，都可以被各种语言使用。这允许在组织中拥有一个平台，可以被多个团队使用(包括使用 Spring 框架的 Java 开发人员)，并服务于多种目的:应用程序开发、测试环境、构建环境(用于运行源代码控制系统、构建服务)

  • 与 Spring Cloud 相比，Kubernetes 解决了更广泛的 MSA 问题。除了提供运行时服务外，Kubernetes 还允许您提供环境、设置资源约束、RBAC、管理应用程序生命周期、支持自动伸缩和自愈(行为几乎像一个抗脆弱的平台)。

  • 我忍不住要提到 Kubernetes 技术是基于谷歌 15 年的研发和管理容器的经验。此外，它拥有近 1000 名提交者，是 Github 上最活跃的开源社区之一。

缺点

  • Kubernetes 支持多种语言，因此它提供的服务是通用的，并没有针对不同的平台或者语言进行优化，比如针对 JVM 的 Spring Cloud。例如，配置作为环境变量或文件系统传递给应用程序。它没有 Spring Cloud Config 提供配置自动更新功能特性。

  • Kubernetes 并不是一个专注于开发者的平台。它的目的是让有 DevOps 意识的 It 人员使用。因此，Java 开发人员需要学习一些新概念，并以开放的心态学习解决问题的新方法。尽管使用 MiniKube 启动 Kubernetes 实例的开发人员非常容易，但是手动安装高可用的 Kubernetes 集群会带来很大的操作成本。

  • Kubernetes 仍然是一个相对较新的平台，它仍然在积极开发和成长。因此，每个版本都会增加很多新特性，可能很难跟上。好消息是，它设计思想超前，而且 API 是可扩展和向后兼容的。

两者完美结合

正如你所看到的，这两个平台在某些领域都有优势，并在其他领域有所改进。Spring Cloud 是一个快速起步的、对开发者友好的平台，而 Kubernetes 是对 DevOps 友好的，具有陡峭的学习曲线，但涵盖了更广泛的微服务关注点。以下是这些观点的总结。

这两个框架处理不同范围的 MSA 关注点，而且它们采用的是完全不同的方式。Spring Cloud 方法试图通过让开发人员更容易地解决 JVM 中的每个 MSA 挑战，而 Kubernetes 方法则试图通过在平台级别解决问题，让开发人员的问题消失。Spring Cloud 在 JVM 中非常强大，而 Kubernetes 在管理这些 JVM 方面非常强大。因此，将它们结合起来并从两个项目的最佳部分中获益是一种自然而然的方式。

通过这样的组合，Spring 提供了应用程序打包，而 Docker 和 Kubernetes 提供了部署和调度。Spring 通过 Hystrix 线程池提供了应用程序内部的隔离，Kubernetes 通过资源、进程和名称空间方式提供了隔离。Spring 为每个微服务提供运行状况接口，Kubernetes 执行运行健康状态检查并根据健康状况将流量暴露到外部。Spring 将配置外部化并更新，Kubernetes 将配置分发给每个微服务。这样的例子不胜枚举。

微服务技术栈

那我最喜欢的微服务平台是什么呢? 实话说我两个都喜欢。我喜欢 Spring 框架提供的开发人员体验。它完全是由注解驱动的，并且涵盖有各种功能需求的组件。我还喜欢 Apache Camel，因为它在应用程序级别上集成连接器、消息传递、路由、弹性和容错等功能。然后可以解决对于集群管理多个应用程序实例有关的任何事情，我更喜欢神奇的 Kubernetes 能力。每当有功能重叠时，比如服务发现、负载均衡、配置管理，我当然会尝试使用 Kubernetes 提供的能力。

赞 (0)

相关推荐