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

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

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

背景故事

最近我读了A. Lukyanchikov写的一篇非常精彩的文章[1]，讲的是用 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 概念的工具。能使得启动过程迅速且容易是很重要的，但是通向产品化的旅程是很漫长的，你需要达到这样的高度[2]才能到达那里。

Microservices concerns

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

技术匹配

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

Spring Cloud and Kubernetes technologies

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

Spring Cloud 有一个丰富的集合，完备整合了 Java 库，以实现各种运行时概念，作为应用栈的一部分。因此，这些微服务自身有库和运行时代理，来做客户端的服务发现，负载均衡，配置更新，度量跟踪等。各种模式，比如单集群服务和批量任务，也是由 JVM 来管理的。

Kubernetes 兼容多种语言，目标不止 Java 平台，并且以一种通用方式为所有语言实现了分布式的计算挑战。它提供了平台级以及应用栈之外的服务，比如配置管理，服务发现，负载均衡，追踪，度量，单例，调度任务。应用不需要任何库或者代理来实现客户端逻辑，且可用任何语言来写。

在某些领域，两个平台都依赖相似的第三方工具。比如，ELK和EFK栈，追踪库等。某些库，比如 Hystric 和 Spring Boot，在两个环境上都非常有用。有些领域两个平台是互补的，整合到一起能创造出一个更强大的解决方案（KubeFlix[3] 和Spring Cloud Kubernetes[4] 就是这样的例子）。

微服务需求

为了画出每个项目的范围，这里有张表列出了几乎是端到端的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[5] 项目实现了 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，管理应用生命周期，使能自动伸缩和自愈（表现为就像一个反脆弱[6]平台）。

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 提供的跟语言无关的原语。