Spring Cloud for Microservices与Kubernetes的比较

Spring Cloud for Microservices与Kubernetes的比较

和都声称是开发和运行微服务的最佳环境，但是它们本质上截然不同并且解决了不同的问题。在本文中，我们将研究每个平台如何帮助交付基于微服务的体系结构（MSA），它们擅长的领域，以及如何兼顾两者，才能成功实现微服务之旅。

背景故事

最近，我读了关于建立微服务架构随着春季云和码头工人由A. Lukyanchikov。如果您还没有阅读它，则应该阅读，因为它全面概述了使用Spring Cloud创建基于简单微服务的系统所需要的工作。为了构建可扩展到数十个或数百个服务的可伸缩且具有弹性的微服务系统，必须借助具有广泛构建时间和运行时功能的工具集来对其进行集中管理和控制。使用Spring Cloud，它既要实现功能服务（例如统计服务，帐户服务和通知服务），又要支持基础架构服务（例如日志分析，配置服务器，服务发现，身份验证服务）。下图描述了使用Spring Cloud的此类MSA：

带有Spring Cloud的MSA（作者：A。Lukyanchikov）

该图涵盖了系统的运行时方面，但没有涉及打包，持续集成，可伸缩性，高可用性，自我修复方面，这在MSA领域中也非常重要。假设大多数Java开发人员都熟悉Spring Cloud，在本文中，我们将得出一个类似的结论，并通过解决这些额外的问题来了解Kubernetes与Spring Cloud的关系。

使用Red Hat最有价值的产品进行开发

您的会员资格可解锁有关企业云应用程序开发的Red Hat产品和技术培训。

微服务问题

与其进行逐个功能的比较，不如让我们看一下更广泛的微服务问题，并了解Spring Cloud和Kubernetes如何解决这些问题。如今，关于MSA的一件好事是它是一种具有公认的的建筑风格。微服务可实现强大的模块边界，独立部署和技术多样性，但它们开发分布式系统和。因此，押宝并被工具包围是成功的关键因素，这些工具将帮助您解决尽可能多的MSA问题。快速简便的开始很重要，但是生产过程很漫长，要达到就必须要有。

微服务问题

在上图中，我们可以看到一个清单，其中包含最常见的技术问题（我们未涵盖组织结构，文化等非技术问题），必须在MSA中解决。我的观点是不同的组织会有所不同，但是在大多数情况下，它应该适用于每个人。

技术映射

这两个平台非常不同，它们之间没有直接的功能奇偶校验。如果我们将每个MSA问题映射到用于在两个平台上解决该问题的技术/项目，我们将得出下表。

Spring Cloud和Kubernetes技术

上表的主要内容是：

· Spring Cloud具有一组丰富的，高度集成的Java库，可以解决所有运行时问题，并将其作为应用程序堆栈的一部分。结果，微服务本身具有库和运行时代理，可以执行客户端服务发现，负载平衡，配置更新，指标跟踪等。单例集群服务，批处理作业等模式也可以在JVM中进行管理。

· Kubernetes是多语言的，不仅针对Java平台，而且以通用的方式针对所有语言解决了分布式计算难题。它在应用程序堆栈之外的平台级别提供用于配置管理，服务发现，负载平衡，跟踪，指标，单例，计划作业的服务。该应用程序不需要任何用于客户端逻辑的库或代理，并且可以用任何语言编写。

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

· 诸如Hystrix，Spring Boot之类的某些库在两种环境下都同样有用。在某些领域中，

微服务要求

为了演示每个项目的范围，下表列出了（几乎）端到端的MSA需求，从底部的硬件开始，到顶部的DevOps和自助服务经验以及它与Spring的关系如何。Spring Cloud和Kubernetes platforms。

微服务要求

在某些情况下，两个项目都使用不同的方法满足相同的要求，并且在某些方面，一个项目可能比另一个项目更强大。但是，两个平台可以相互补充，并且可以组合使用，以提供卓越的微服务体验，这也是一个最佳选择。例如，Spring Boot提供了用于构建单个jar应用程序包的Maven插件。结合使用Docker和Kubernetes的声明式部署和调度功能，使运行微服务变得轻而易举。同样，Spring Cloud具有应用程序内库，可使用Hystrix（具有隔板和断路器模式）和Ribbon（用于负载平衡）来创建弹性的，容错的微服务。但是，仅凭这一点还不够，当与Kubernetes健康检查结合使用时，

长处和短处

由于这两个平台不是逐个特征地直接可比，而不是逐项研究，因此这里总结了每个平台的优缺点。

Spring Cloud为开发人员提供了工具，可在分布式系统中快速构建一些常见模式，例如配置管理，服务发现，断路器，路由等。它基于Java编写的Netflix OSS库（面向Java开发人员）构建。

长处

· Spring平台本身提供的

· 有很多库可以解决大多数运行时问题。而且，由于所有库都是用Java编写的，因此它提供了多种功能，更好的控制和微调选项。

· 不同的Spring Cloud库相互之间很好地集成在一起。例如，Feign客户端还将使用Hystrix进行断路，并使用Ribbon来平衡请求。一切都是注释驱动的，易于开发，感觉就像Java开发人员的天堂。

弱点

· Spring Cloud的主要优点之一就是它的缺点- 它仅限于Java。MSA的强大动力是能够在需要时更改技术堆栈，库甚至语言。Spring Cloud无法做到这一点。如果您想使用Spring Cloud / Netflix OSS基础架构服务（例如配置管理，服务发现，负载平衡），则该解决方案并不理想。在项目实现了跨斗模式，以公开的基于Java的客户端库通过HTTP，使其可能写在非JVM语言应用在NetflixOSS生态系统中存在，但它是不是很优雅。此外，自从我撰写本文以来，Pivotal宣布了一个名为项目，这也允许从.Net客户端使用服务发现和Config Server服务。

· Java开发人员要负责处理Java应用程序，这要承担太多责任。每个微服务都需要运行各种客户端以进行配置检索，服务发现和负载平衡。设置起来很容易，但是并不能掩盖运行时对环境的依赖的构建时间。例如，我可以使用@EnableConfigServer创建一个配置服务器。注释很容易。每次我想运行一个微服务时，都需要启动并运行Config Server。对于受控环境，我必须考虑使Config Server高度可用，并且由于它可以由Git或Svn支持，因此我需要共享文件系统。同样，对于服务发现，我需要首先启动Eureka Server。对于受控环境，我需要将其与每个AZ上的多个实例进行集群。感觉像Java开发人员，除了实现所有功能服务之外，我还必须构建和管理一个不平凡的Microservices平台。

· 仅Spring Cloud 在Microservices旅程中的范围更短，并且您还需要考虑自动化部署，调度，资源管理，进程隔离，自我修复，构建管道等，以获取完整的Microservices体验。就这一点而言，我认为将Spring Cloud与Kubernetes单独进行比较是不公平的，而更合理的比较应该是Spring Cloud + 。但这也意味着，要获得完整的端到端微服务体验，必须为Spring Cloud补充Kubernetes本身。

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

长处

· Kubernetes是一个多语言和通用容器管理平台，能够运行云原生和传统容器化应用程序。它提供的服务（例如配置管理，服务发现，负载平衡，指标收集，日志聚合）可以通过多种语言来使用。这允许在组织中拥有一个可以供多个团队（包括使用Spring框架的Java开发人员）使用的平台，并可以满足多种目的：应用程序开发，测试环境，构建环境（运行源代码控制系统，构建服务器，工件存储库），等等

· 与Spring Cloud相比，Kubernetes 解决了更多的MSA问题。除了提供运行时服务外，Kubernetes还允许您置备环境，设置资源约束，RBAC，管理应用程序生命周期，启用自动缩放和自我修复（几乎像一个平台一样）。

· 我不禁要提及Kubernetes技术是基于Google的15年研发经验和容器管理经验而建立的。此外，它拥有近1000个提交者，是Github上

弱点

· Kubernetes是多语言的，因此其服务和原语是通用的，并未针对诸如Spring Cloud for JVM之类的不同平台进行优化。例如，配置作为环境变量或完整的文件系统传递给应用程序。它没有Spring Cloud Config提供的高级配置更新功能。

· Kubernetes 不是以开发人员为中心的平台。打算由具有DevOps意识的IT人员使用。因此，Java开发人员需要学习一些新概念，并乐于学习解决问题的新方法。尽管使用启动Kubernetes的开发人员实例非常，但是手动安装高度可用的Kubernetes集群仍然存在大量操作开销。

· Kubernetes仍然是一个相对较新的平台（已有2年的历史了），并且仍在积极地开发和发展。因此，每个发行版中都添加了许多新功能，这些新功能可能很难跟上。好消息是，已经设想到了这一点，并且该API是可扩展的并且向后兼容。

如您所见，这两个平台在某些领域都有优势，而在其他领域则有待改进。Spring Cloud是开发人员友好的平台，可快速上手，而Kubernetes是DevOps友好的，具有陡峭的学习曲线，但涵盖了更多的微服务问题。这是这些要点的摘要。

长处和短处

这两个框架都解决了MSA的不同关注范围，并且它们以根本不同的方式来处理。Spring Cloud方法试图通过使开发人员易于解决来解决JVM内部的每个MSA挑战，而Kubernetes方法试图通过在平台级别解决它来使开发人员解决该问题。Spring Cloud在JVM内部非常强大，而Kubernetes在管理这些JVM方面非常强大。因此，将它们结合起来并从两个项目的最佳部分中受益似乎是一种自然的进步。

Kubernetes支持的Spring Cloud

通过这种组合，Spring提供了应用程序打包，而Docker和Kubernetes提供了部署和调度。Spring通过Hystrix线程池提供应用程序内隔离，而Kubernetes通过资源，进程和名称空间隔离提供隔离。Spring为每个微服务提供运行状况端点，而Kubernetes执行运行状况检查并将流量路由到运行状况良好的服务。Spring外部化并更新配置，Kubernetes将配置分发给每个微服务。而且这个清单还在继续。

我最喜欢的微服务堆栈

我最喜欢的微服务平台如何？我俩喜欢。我喜欢Spring框架提供的开发人员经验。它全部由注释驱动，并且库涵盖了所有功能需求。我还喜欢Apache Camel（在这种情况下为Spring Integration），它与应用程序级的集成，连接器，消息传递，路由，弹性和容错性有关。然后，对于与集群和管理多个应用程序实例有关的任何事情，我更喜欢Kubernetes功能。每当有功能重叠（例如服务发现，负载平衡，配置管理）时，我都会尝试使用Kubernetes提供的多语言原语。

閱讀更多 愛上樹的程序猿 的文章

關鍵字: 比较 分布式计算 Java虚拟机