微服务系统服务框架
利用Spring Cloud 来创建一个简单的基于微服务的系统的综合视角。为了构建一个能扩展到数千个服务的可扩展且有弹性的微服务系统，它就必须有一套拥有广泛的构建时和运行时能力的工具集来帮助管理和控制。使用 Spring Cloud，既能实现功能型服务（比如统计服务，账号服务以及通知服务），又能实现基础架构服务（比如日志分析，配置服务器，服务发现，认证服务等）。描述这样一个使用 Spring Cloud 构造的微服务架构（MSA）图如下所示：
MSA with Spring Cloud（by A. Lukyanchikov）
从技术匹配情况来分析：
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] 就是这样的例子）。
从微服务需求角度来分析：
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 做成了可扩展且是后向兼容的。
