spring cloud vs k8s_spring cloud k8s

个人总结：

spring cloud是从应用框架层面解决了微服务架构的一部分(网关、服务发现，负载平衡，配置管理，指标跟踪等)，易于java开发者上手，缺乏打包、持续集成、伸缩、高可用和自我修复等，而且局限于java平台；

k8s从平台层面解决了微服务架构整个流程，并且不限语言，上手难度稍高些。(可管理应用程序整个生命周期，应用自动扩展、持续集成、伸缩、高可用和自我修复等)

Spring Cloud的微服务架构：

该图展示了运行时的方方面面，但没有包括打包、持续集成、伸缩、高可用和自我修复等在微服务架构中重要点。

微服务架构中最常见的技术要点：

技术对比图：

如果将每个MSA(微服务架构)问题映射到用于在两个平台中解决该问题的技术/项目，我们将得出下表。

上表的主要内容是：

• Spring Cloud具有一组丰富的，高度集成的Java库，可以解决所有运行时问题，并将其作为应用程序堆栈的一部分。结果，微服务本身具有库和运行时代理，可以进行客户端服务发现，负载平衡，配置更新，指标跟踪等。单例集群服务和批处理作业等模式也可以在JVM中进行管理。

• Kubernetes是多语言的，不仅针对Java平台，而且以一种通用的方式针对所有语言解决了分布式计算难题。它在平台级别和应用程序堆栈外部提供用于配置管理，服务发现，负载平衡，跟踪，指标，单例，计划作业的服务。该应用程序不需要任何用于客户端逻辑的库或代理，并且可以用任何语言编写。

• 在某些方面，两个平台都依赖于类似的第三方工具。例如，ELK和EFK堆栈，跟踪库等。某些库（例如Hystrix和Spring Boot）在两种环境下都同样有用。在某些领域中，两个平台是互补的，并且可以组合在一起以创建更强大的解决方案（KubeFlix和Spring Cloud Kubernetes就是这样的示例）。

微服务要求

下表列出了（几乎）端到端MSA要求，从底部的硬件开始，到顶部的DevOps和自助服务经验，以及它们之间的关系到Spring Cloud和Kubernetes平台。

长处和短处

Spring Cloud

Spring Cloud为开发人员提供了工具，可在分布式系统中快速构建一些常见模式，例如配置管理，服务发现，断路器，路由等。它基于Java编写的Netflix OSS库（面向Java开发人员）构建。

长处
Spring平台本身提供的统一编程模型以及Spring Boot的快速应用程序创建功能为开发人员提供了出色的微服务开发经验。例如，使用很少的批注，您可以创建Config Server，而使用更少的批注，则可以获取客户端库来配置服务。
有丰富的库可供选择，涵盖了大多数运行时问题。由于所有库都是用Java编写的，因此它提供了多种功能，更强的控制能力和微调选项。
不同的Spring Cloud库彼此很好地集成在一起。例如，Feign客户端还将使用Hystrix进行电路断开，并使用Ribbon进行负载平衡请求。一切都是注释驱动的，这使得Java开发人员易于开发。
弱点
Spring Cloud的主要优点之一就是缺点-它仅限于Java。MSA的强大动力是在需要时可以交换技术堆栈，库甚至语言。Spring Cloud无法做到这一点。
Java开发人员要关心和处理Java应用程序负有太多责任。每个微服务都需要运行各种客户端以进行配置检索，服务发现和负载平衡。设置起来很容易，但这并没有隐藏对环境的构建时间和运行时依赖性。例如，开发人员可以使用@EnableConfigServer创建Config Server，但这仅是一条快乐的路。每次开发人员想要运行一个微服务时，他们都需要启动并运行Config Server。对于受控环境，开发人员必须考虑使Config Server高度可用，并且由于它可以由Git或Svn支持，因此他们需要一个共享文件系统。同样，对于服务发现，开发人员需要首先启动Eureka服务器。对于受控环境，
仅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个提交者，是Github上最活跃的开源社区之一。
弱点
Kubernetes是多语言的，因此，它的服务和原语是通用的，并未针对诸如Spring Cloud for JVM之类的不同平台进行优化。例如，配置作为环境变量或已挂载的文件系统传递给应用程序。它没有Spring Cloud Config提供的高级配置更新功能。
Kubernetes不是以开发人员为中心的平台。更偏向于由具有DevOps(运维开发)意识的IT人员使用。因此，Java开发人员需要学习一些新概念，并乐于学习解决问题的新方法。尽管使用MiniKube启动Kubernetes的开发人员实例非常 容易，但是手动安装高度可用的Kubernetes集群仍然存在大量操作开销。
Kubernetes仍然是一个相对较新的平台（已有2年的历史了），并且仍在积极地发展和壮大。因此，可能很难跟上每个发行版中添加的许多新功能。好消息是，已经设想到了这一点，并且该API是可扩展的并且向后兼容。

优缺点对比图：

这两个框架都解决了MSA的不同问题，并且以根本不同的方式进行。Spring Cloud方法正在尝试解决JVM内部的每个MSA挑战，而Kubernetes方法正在尝试通过在平台级别解决问题来使开发人员消除该问题。Spring Cloud在JVM内部非常强大，而Kubernetes在管理这些JVM方面非常强大。因此，将它们结合起来并从两个项目的最佳部分中受益似乎是一种自然的进步。

通过这种组合，Spring提供了应用程序打包，而Docker和Kubernetes提供了部署和调度。Spring通过Hystrix线程池提供应用程序内的隔离，而Kubernetes通过资源，进程和名称空间的隔离提供隔离。Spring为每个微服务提供运行状况端点，而Kubernetes执行运行状况检查并将流量路由到运行状况良好的服务。Spring外部化并更新配置，Kubernetes将配置分发给每个微服务。这个清单还在继续。

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

原文地址：https://dzone.com/articles/deploying-microservices-spring-cloud-vs-kubernetes