转载本文，请联系新钛云服务记录公众号。SpringCloud和Kubernetes都声称是开发和微服务的最佳运行时环境，但它们在本质上有很大不同。在本文中，我们将了解他们如何帮助交付基于微服务的架构(MSA)、他们专注于哪些领域，以及他们如何利用自己的优势在您的微服务之旅中实现两全其美。使用SpringCloud创建基于微服务的系统需要什么？为了构建一个支持增长到数十或数百个服务的可扩展且有弹性的微服务系统，有必要利用工具集集中管理和治理的广泛构建时和运行时功能。使用SpringCloud，这涉及实现功能服务（如统计服务、账户服务和通知服务）和支持基础设施服务（如日志分析、配置服务器、服务发现、身份验证服务）。描述这样一个使用SpringCloud的MSA的图表如下：该图表涵盖了系统的运行时方面，但没有涵盖封装、CICD、缩放、高可用性和自我修复，这些在MSA中也非常重要。假设大多数Java开发人员都熟悉SpringCloud，在本文中我们将通过解决这些问题来取得平衡，看看Kubernetes和SpringCloud之间的关系。微服务问题与其逐个比较，不如看看更广泛的微服务问题，看看SpringCloud和Kubernetes如何处理它们。MSA的好处在于它是一种具有易于理解的权衡的架构风格。微服务支持具有独立部署和技术多样性的强大模块边界。它们以开发分布式系统和大量运营开销为代价。一个关键的成功因素是专注于可以帮助您解决尽可能多的MSA问题的内容。使启动过程快速简便非常重要。在上图中，我们可以看到一个包含MSA中必须解决的最常见技术问题的列表。技术映射SpringCloud和Kubernetes是两个截然不同的平台，它们之间没有直接的功能对等。如果我们将每个MSA问题映射到两个平台中用于解决它的技术，我们将得出下表。从上表得出的主要结论是：SpringCloud拥有丰富的集成良好的Java库集，可以作为应用程序堆栈的一部分解决所有运行时问题。所以微服务本身有用于客户端服务发现、负载均衡、配置更新、指标跟踪等的库和运行时代理。单例集群服务和批处理作业等模式也在JVM中进行管理。Kubernetes是多语言的，不仅仅针对Java平台，而是以通用的方式解决所有语言的分布式计算挑战。它为平台级别和应用程序堆栈之外的配置管理、服务发现、负载平衡、跟踪、指标、单例、计划作业提供服务。该应用程序不需要任何库或客户端逻辑代理，可以用任何语言编写。在某些领域，这两个平台都依赖于类似的第三方工具。例如，ELK和EFK堆栈、跟踪库等。示例包括Hystrix和SpringBoot，它们在两种环境中同样有用。在某些领域，这两个平台是互补的，可以结合起来创建更强大的解决方案（KubeFlix和SpringCloudKubernetes就是这方面的例子）。微服务需求为了展示每个项目的范围，这里有一个包含端到端MSA需求的表格，从底部的硬件到顶部的DevOps和自助服务体验，以及它们与SpringCloud和Kubernetes的关系平台。在某些情况下，两个项目使用不同的方法来满足相同的要求，而在某些领域，一个项目可能比另一个项目更强。但也有一个好处，两个平台相辅相成，可以结合起来取长补短，以获得卓越的微服务体验。例如，SpringBoot提供了一个用于构建单个jar应用程序包的Maven插件。结合Docker和Kubernetes的声明式部署和调度功能，运行微服务变得轻而易举。同样，SpringCloud具有应用程序内库，用于使用Hystrix和Ribbon创建弹性、容错的微服务。但这还不够，当它结合Kubernetes的健康检查时，进程会被重启，相比SpringCloudSpringCloud为开发者提供了快速构建分布式系统中一些通用模式的工具，如配置管理、服务发现、路由，ETC。。它建立在NetflixOSS库之上，用Java编写，供Java开发人员使用。优势：SpringPlatform自身提供的统一编程模型和SpringBoot快速的应用创建能力，为开发者提供极佳的微服务开发体验。例如，使用很少的注释，您可以创建一个配置服务器。有丰富的库可供选择，涵盖了大多数运行时问题。由于所有库都是用Java编写的，因此它提供了多种功能、更好的控制和微调选项。不同的SpringCloud库可以很好地相互集成。例如，Feign客户端还会使用Hystrix进行熔断，使用Ribbon进行负载均衡请求。一切都是注释驱动的，使Java开发人员的开发变得容易。缺点：SpringCloud的主要优点之一也是它的缺点——它仅限于Java。MSA的一个强大动力是能够在需要时交换技术堆栈、库甚至语言。这在SpringCloud中是不可能的。如果要使用SpringCloud/NetflixOSS基础服务，比如配置管理、服务发现或者负载均衡，解决方案并不优雅。Java开发人员需要关心和处理Java应用程序的问题太多了。每个微服务都需要运行各种客户端来进行配置检索、服务发现和负载均衡。设置它们很容易，但这并没有隐藏构建时和运行时对环境的依赖性。例如，开发人员可以使用EnableConfigServer创建配置服务器，但这只是一种方式。每次开发人员想要运行单个微服务时，他们都需要启动并运行配置服务器。对于受控环境，开发者必须考虑让ConfigServer高可用，它支持Gi或Svn，所以他们需要一个共享的文件系统。同样，对于服务发现，开发者需要先启动一个Eureka服务器。SpringCloud本身在微服务之旅中的范围很短，开发者还需要考虑自动化部署、调度、资源管理、进程隔离、自愈、构建流水线等，以获得完整的微服务体验。在这一点上，我认为将SpringCloud与Kubernetes单独比较是不公平的，而是将SpringCloud+CloudFoundry（或DockerSwarm）与Kubernetes进行比较更公平。但这也意味着，要获得完整的端到端微服务体验，SpringCloud必须辅以Kubernetes本身等应用平台。KubernetesKubernetes是一个开源系统，用于自动化容器化应用程序的部署、扩展和管理。它是多语言的，并提供用于配置、运行、扩展和管理分布式系统的工具。优点：Kubernetes是一个多语言且与语言无关的容器管理平台，能够运行云原生和传统容器化应用程序。它提供的服务，例如配置管理、服务发现、负载均衡、指标收集和日志聚合，可以被多种语言使用。这允许在组织中拥有一个可供多个团队（包括使用Spring的Java开发人员）使用并服务于多种用途的平台：应用程序开发、测试环境、构建环境（运行源代码控制系统、构建服务器、工件存储库）等.Kubernetes解决了比SpringCloud更广泛的MSA问题。除了提供运行时服务，Kubernetes还允许您配置环境、设置资源约束、RBAC、管理应用程序生命周期、启用自动扩展和自我修复。Kubernetes技术基于Google15年的容器开发和管理经验。它是Github上最活跃的开源社区之一。缺点：Kubernetes是多语言的，因此，它的服务和原语是通用的，没有针对不同平台（例如SpringCloudforJVM）进行优化。例如，配置作为环境变量或挂载的文件系统传递给应用程序。它没有SpringCloudConfig提供的花哨的配置更新功能。Kubernetes不是面向开放人群的平台。它旨在供具有DevOps意识的IT人员使用。因此，Java开发者需要学习一些新的概念，学习新的解决问题的方法。虽然使用MiniKube启动Kubernetes实例非常容易，但手动安装高可用Kubernetes集群会产生大量的操作开销。Kubernetes仍然是一个相对较新的平台，并且仍在积极开发和发展中。因此，每个版本都会添加许多新功能，并且API可扩展且向后兼容。两全其美这两个框架都解决了MSA问题的不同范围，并且它们以根本不同的方式来解决。SpringCloud试图解决JVM内部的MSA挑战，而Kubernetes试图通过在平台级别解决问题来让开发人员解决问题。SpringCloud在JVM内部非常强大，而Kubernetes在管理这些JVM方面非常强大。所以把它们结合起来，取其精华。通过这种组合，Spring提供应用程序打包，Docker和Kubernetes提供部署和调度。Spring通过Hystrix线程池提供应用内隔离，Kubernetes通过资源、进程、命名空间隔离提供逻辑隔离。Spring为每个微服务提供健康端点，Kubernetes执行健康检查并将流量路由到健康服务。Spring将配置外部化并更新，Kubernetes将配置分发到每个微服务。配合默契，简直堪称完美。一张我最喜欢的微服务栈图就足够了，请看图：原文：https://dzone.com/articles/deploying-microservices-spring-cloud-vs-kubernetes
