【架构】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提供的多语言原语。

 

参考资料：

http://blog.csdn.net/qq_34463875/article/details/53816943

 

spring-boot 和 docker 集成：http://www.open-open.com/lib/view/open1450684294167.html