Kubernetes和Spring Cloud哪个部署微服务更好？

Spring Cloud 和Kubernetes都自称自己是部署和运行微服务的最好环境，但是它们在本质上和解决不同问题上是有很大差异的。在本文中，我们将看到每个平台如何帮助交付基于微服务的架构（MSA），它们擅长哪个领域，并且如何两全其美的使用从而在微服务之旅上获得成功。

背景

最近我读了 A. Lukyanchikov的一篇非常棒的文章（https://dzone.com/articles/microservice-architecture-with-spring-cloud-and-do），关于使用Spring Cloud和Docker来构建微服务架构。如果你还没看过，建议你看一下，它给出了一个综合的概述：如何使用Spring Cloud来创建一个简单的基于微服务的系统。为了创建一个可增长到数十或上百个服务的可扩展、弹性的微服务系统，必须在一个拥有广泛构建时和运行能力工具集的帮助下集中管理和治理。通过Spring Cloud，涉及到实现功能性服务（例如统计服务、账户服务和通知服务）并且支持基础服务（例如日志分析、配置服务器、服务发现、服务授权）。一个使用Spring Cloud的MSA描述图表如下：

用Spring Cloud的MSA（来自A. Lukyanchikov）

这张图涵盖了系统的运行方面，但是不涉及打包、持续集成、缩放、高可用和自我修复，这些在MSA中同样非常重要。我们假设大部分JAVA开发人员熟悉Spring Cloud，在本文中，我们将做个类比并且看看Kubernetes如何联系Spring Cloud来处理这些额外的障碍。

微服务障碍

通过特征对比而不是做一个比较，我们来看一下广阔的微服务障碍和Spring Cloud与Kubernetes如何处理这些障碍。如今MSA的优点就是它是一种得益于易理解和权衡下的架构风格。微服务通过独立部署和多样化技术使得模块边界强化。但是它们以开发分布式系统成本和巨大的运营开销为代价。一个关键的成功要素就是集中在周围的工具上，将会帮你处理尽可能多的MSA问题。启动过程快而简单是很重要的，但是产品过程是很长的，你需要变得更厉害才能成功。

微服务关注点

在上面的图中，我们可以看到一个最常见的技术障碍列表（不涵盖非技术性的障碍，例如组织结构、文化等等）需要在MSA中处理。

技术映射

两个平台Spring Cloud和Kubernetes非常不同并且它们之间没有直接的相同特征。如果在两个平台上每个MSA障碍映射到技术/项目以前常用来处理它，会提出如下图表。

Spring Cloud和Kubernetes技术

上面的图表主要的结论就是：

• Spring Cloud拥有丰富的、综合的JAVA类库来处理所有执行障碍作为部分应用堆栈。因此，微服务自身有类库和执行代理来做客户端服务发现负载均衡、配置升级、指标追踪等等。模式例如单例模式集群服务和批量作业也在JVM中管理。
• Kubernetes可多语言，没有只是把JAVA平台当目标，处理了所有语言用一类方法的分布式计算挑战。它为了在平台层配置管理、服务发现、负载均衡、追踪、指标、单例模式、调度作业提供服务，并且在应用套件之外。应用程序为了客户端逻辑无需任何类库或代理，它可以使用任何语言来编写。
• 在一些方面，两个平台依靠相似的第三方工具。例如ELK和EFK stacks, tracing libraries等等。一些类库，像是Hystrix和Spring Boot，在两个环境中都同样使用很好。在一些方面两个平台是互补的，可以组合创建一个更强大的解决方案( KubeFlix 和Spring Cloud Kubernetes这样的例子)。

微服务需求

为了演示每个项目的范围，这里有个（几乎）端到端的MSA需求表格，在底部从硬件开始，上到顶部DevOps和自服务经验，以及它如何将Spring Cloud和Kubernetes平台联系到一起。

微服务需求

在某些情况下，两个项目用不同的方法满足同样的需求，在一些方面，一个项目可以比另一个项目更强。但也有个sweet的地方，就是两个平台可以互补并组合成一个更出众的微服务体验。例如，Spring Cloud提供Maven插件来创建单独JAR应用程序包。结合Docker、Kubernetes的声明式部署和调度能力，轻松运行微服务。同样，Sring Cloud有应用程序内类库来创建弹性、容错微服务，使用Hystrix（bulkhead和断路器模式）与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模式，显示基于Java客户类库越过HTTP，使得用non-JVM语言编写的应用程序存在于NetflixOSS生态系统变得可能，但它不是很优雅。
• 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是一个多语言和未可知语言的容器管理平台，它可以运行原生云和运行传统容器化应用程序。它提供的服务，例如配置管理、服务发现、负载均衡、指标收集和日志聚集，都通过各种各样的语言来实现。这允许组织中有多个团队来使用一个平台（包括Java开发者使用Spring），并且用于多种目的：应用程序开发、测试环境、创建环境（运行资源控制系统、创建服务其、存储库）等等。
• 当比较Spring Cloud、Kubernetes处理广泛MSA问题时，除了提供运行服务，Kubernetes也让你提供环境、设置资源限制、RBAC、管理应用程序生命周期，实现自动缩放和自我修复（表现的几乎像是一个抗脆弱的平台）。
• Kubernetes技术是基于谷歌15年的R&D和管理容器的经验。另外，将近1000名提供者，这是在Github上最活跃的一个开源社区之一。

缺点

• Kubernetes是多语言的，同样的，它的服务和原语是通用的，并且对于不同平台来说不是最佳的，例如Spring Cloud for JVM。举个例子，配置传递给应用程序作为环境变量或挂载文件系统。它没有Spring Cloud Config提供的奇特的配置升级能力。
• Kubernetes不是一个面向开发者的平台。它打算让那些在意DevOps的人员来使用。因此，Java开发人员需要学习一些新概念和开放的学习一些新方法来解决问题。尽管它是超简单的开始一个开发人员使用 MiniKube的Kubernetes实例，这有一个巨大的操作开销就是手动安装一个高可用的Kubernetes集群。
• Kubernetes仍然是一个相对较新的平台（2岁），它还在积极的发展和成长。因此伴随着每次释放有许多新特性增加，可能很难跟上。好消息是这是设想中的，API是可扩展和向后兼容的。

两个世界中的最佳

如你所见，两个平台在核心领域都很强，并且在其他领域改进。Spring Cloud可以快速使用、对开发者友好的平台，然而Kubernetes对DevOps友好，艰难的学习曲线，但是覆盖更广泛的微服务障碍。以下是这些点的总结。

优点和缺点

两种架构处理了不同范围的MSA障碍，并且它们从根本上用了不同的方法。Spring Cloud方法是试图解决在JVM中每个MSA挑战，然而Kubernetes方法是试图让问题消失，为开发者在平台层解决。Spring Cloud在JVM中非常强大，Kubernetes管理那些JVM很强大。同样的，它就像一个自然发展，结合两种工具并且从两个项目中最好的部分受益。

通过Kubernetesd支持的Spring Cloud

通过这样一种结合，Spring提供应用程序打包，Docker和Kubernetes提供部署和调度。Spring通过Hystrix线程池提供应用程序内隔板，Kubernetes通过资源、进程和命名空间隔离提供隔板。Spring为每个微服务提供健康终端，Kubernetes执行健康检查并且为健康服务通信路由。Spring外部化且升级配置，Kubernetes给每个微服务分配配置。这样的还有很多。

我喜欢的微服务堆栈

我最喜欢哪个微服务平台？两个都喜欢。我喜欢Spring框架带来的开发者体验。全部都是注解驱动的，类库覆盖所有种类的功能需求。我也喜欢Apache Camel（宁愿Spring Spring Integration）为集成、连接器、消息、路由、弹性和在应用层的容错所做的。然后与集群和多种应用程序实例管理，我更喜欢Kubernetes神奇的力量。每当有一个功能重叠，例如服务发现、负载均衡、配置管理，我试着使用Kubernetes提供的多语言原语。