部署微服务的时候，Spring Cloud 和 Kubernetes 哪个更好？ - DockOne.io

【编者的话】本文比较了当下最火热的两大微服务开发平台：Spring Cloud和Kubernetes的优缺点，并指出结合二者的优点来组合使用，将在微服务旅程上获得更大成功。

当我们需要部署微服务的时候，哪个更好？Spring Cloud还是Kubernetes？答案是都可以，只是各自有其优势。

Spring Cloud和 Kubernetes都宣称自己是开发和运行微服务的最佳环境，但是它们的本质非常不一样，所追求的目标也不同。本文我们分析一下两个平台是如何在其擅长的、实现基于微服务的架构（MSA）上起到作用的，并判断如何利用两者的强项，来帮助我们在微服务旅程上获得成功。

背景故事

最近我读了A. Lukyanchikov写的一篇非常精彩的 文章，讲的是用Spring Cloud和Docker来构建微服务架构。如果你还没读过，你应该读一下，因为它给出了一个关于如何利用Spring Cloud来创建一个简单的基于微服务的系统的综合视角。为了构建一个能扩展到数千个服务的可扩展且有弹性的微服务系统，它就必须有一套拥有广泛的构建时和运行时能力的工具集来帮助管理和控制。使用Spring Cloud，既能实现功能型服务（比如统计服务，账号服务以及通知服务），又能实现基础架构服务（比如日志分析，配置服务器，服务发现，认证服务等）。描述这样一个使用Spring Cloud构造的微服务架构（MSA）图如下所示：

MSA with Spring Cloud (by A. Lukyanchikov)

该图包含了运行时视角，但是它不包含打包，持续集成，扩展性，高可用，自愈等在MSA世界中同样重要的功能。本文假设大部分Java开发者都熟悉Spring Cloud，我们来做个对比，看看Kubernetes是如何提出这些额外的概念，以关联到Spring Cloud的。

微服务概念

我们不会针对两者一个一个概念的比对，而是根据更广阔的微服务概念，来看看Spring Cloud和Kubernetes分别是如何实现他们的。今天有关MSA的一个好事是，它是一个有着易于理解的 优缺点评估的架构风格。微服务能加强模块边界，各模块可以有独立的部署和技术差异。但是同时也 带来了代价，需要开发分布式系统以及 明显增加操作成本。一个关键的成功因素是聚焦于使用一套能帮助你实现尽可能多的MSA概念的工具。能使得启动过程迅速且容易是很重要的，但是通向产品化的旅程是很漫长的，你需要达到 这样的高度才能到达那里。

Microservices concerns

如上图所示，我们可以看到MSA中必须实现的那些最普遍的技术概念（我们将不会关注非技术概念，比如组织结构，文化等）。

技术匹配

Sping Cloud和Kubernetes这两个平台非常不一样，并且它们之间也没有直接的等价特性。如果我们将每个MSA概念匹配到这两个平台使用的实现这些概念的技术/项目，我们能得出下表。

Spring Cloud and Kubernetes technologies

从上表中能快速得出的结论是：

• Spring Cloud有一个丰富的集合，完备整合了Java库，以实现各种运行时概念，作为应用栈的一部分。因此，这些微服务自身有库和运行时代理，来做客户端的服务发现，负载均衡，配置更新，度量跟踪等。各种模式，比如单集群服务和批量任务，也是由JVM来管理的。
• Kubernetes兼容多种语言，目标不止Java平台，并且以一种通用方式为所有语言实现了分布式的计算挑战。它提供了平台级以及应用栈之外的服务，比如配置管理，服务发现，负载均衡，追踪，度量，单例，调度任务。应用不需要任何库或者代理来实现客户端逻辑，且可用任何语言来写。
• 在某些领域，两个平台都依赖相似的第三方工具。比如，ELK和EFK栈，追踪库等。某些库，比如Hystric和Spring Boot，在两个环境上都非常有用。有些领域两个平台是互补的，整合到一起能创造出一个更强大的解决方案（ KubeFlix和 Spring Cloud Kubernetes就是这样的例子）。

微服务需求

为了画出每个项目的范围，这里有张表列出了几乎是端到端的MSA需求，从最底层的硬件，到最上层的DevOps和自服务经验，并且列出了如何关联到Spring Cloud和Kubernetes平台。

Microservices requirements

在某些场景下，两个项目使用不同的方法达成了相同的需求，在某些领域，一个项目可能会强于另一个。但是在某些情况下，两个项目是互补的，可以组合起来达成高级的微服务经验。例如，Spring Boot提供了Maven插件来构建单个JAR应用包。这样就可以结合Docker和Kubernetes的声明式部署和调度能力，使得运行微服务变得轻而易举。同样的，Spring Cloud有个内嵌的应用库，可以利用Hystric（自带隔离和熔断模式）和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协议，使得那些非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是语言不感知的容器管理平台，能兼容运行原生云应用和传统的容器化应用。它提供的服务，比如配置管理，服务发现，负载均衡，度量收集，以及日志聚合，能被各种语言使用。这使得组织可以只提供一个平台供多个项目组使用（包括使用Spring的Java开发者），并且提供多种目的：应用开发，测试环境，构建环境（运行资源控制系统，构建服务器，人工仓库）等。
• 和Spring Cloud相比，Kubernetes实现了更广阔的MSA概念集合。除了提供运行时服务，Kubernetes也允许我们提供环境变量，设置资源限制，RBAC，管理应用生命周期，使能自动伸缩和自愈（表现为就像一个 反脆弱平台）。
• Kubernetes的技术是基于Google 15年的管理容器的研究和开发经验。除此以外，还有将近1000个 committer，它几乎是GitHub上开源社区最活跃的项目。

缺点

• Kubernetes是兼容多种语言的，因此它的服务和原语是通用的，不像Spring Cloud对JVM那样，没有针对不同的平台做优化。例如，配置是通过环境变量或者挂载文件系统传递给应用的。它没有Spring Cloud配置提供的那样精妙的配置更新能力。
• Kubernetes不是一个针对开发者的平台。它的目的是供有DevOps思想的IT人员使用。因此，Java开发者需要学习一些新的概念，并更开放得学习新的解决问题的方式。不管使用 MiniKube来部署一个Kubernetes开发实例是多么得容易，手工安装一个高可用的Kubernetes集群是有明显的操作成本的。
• Kubernetes仍是一个相对较新的平台（2年），它也还在活跃得开发和生长中。因此每个版本都会有许多新的特性，使得我们很难去一直跟踪。好消息是这个问题已经被正视，API做成了可扩展且是后向兼容的。

两个平台的最佳实践

正如你所看到的，两个平台都有各自的强项，也有需要提高的地方。Spring Cloud 是一个容易上手的，开发者友好的平台。而Kubernetes是DevOps友好的，有着陡峭的学习曲线，但是包含了更广泛的微服务概念。这里是针对这几点的总结。

Strengths and weaknesses

两个框架实现了不同范围的MSA概念，使用的是从根源上就有区别的方式。Spring Cloud方式是尽力在JVM范畴内来解决每个MSA的挑战，而Kubernetes的方式是尽力为开发者在平台层面消除这些问题。Spring Cloud在JVM内非常强大，Kubernetes在管理这些JVM上非常强大。因此，整合这两者取它们的最佳部分，是一个很自然的进步过程。

Spring Cloud backed by Kubernetes

有了这样一个整合，Spring提供应用的打包，Docker和Kubernetes提供部署和调度。Spring通过Hystrix线程池提供应用内的隔离，而Kubernetes通过资源，进程和命名空间来提供隔离。Spring为每个微服务提供健康终端，而Kubernetes执行健康检查，且把流量导到健康服务。Spring外部化配置并更新它们，而Kubernetes分发配置到每个微服务。这个列表将一直持续。

My favorite microservices stack

我最喜欢的微服务平台是哪个？我 两个都喜欢。我喜欢Spring 框架提供的开发者经验。它是标签驱动的，并且拥有包含了各种功能需求的库。跟任何整合相关的，我喜欢Apache Camel（而不是Spring Integration），它能提供应用级别的连接器，消息，路由，可靠性和容错功能。而对跟集群和管理多应用实例相关的，我更喜欢魔法般的Kubernetes能力。不论何时，有重复功能，比如服务发现，负载均衡，配置管理，我尽量使用Kubernetes提供的跟语言无关的原语。

原文链接： Deploying Microservices: Spring Cloud vs. Kubernetes（翻译：池剑锋）