用于微服务的Spring Cloud与Kubernetes相比
用于微服务的Spring Cloud与Kubernetes相比
译文，原文地址：https://developers.redhat.com/blog/2016/12/09/spring-cloud-for-microservices-compared-to-kubernetes/
Spring Cloud和Kubernetes都声称是开发和运行微服务的最佳环境，但它们在本质上都是非常不同的，并且解决了不同的问题。在本文中，我们将了解每个平台如何帮助提供基于微服务的架构（MSA），以及他们擅长的领域，以及如何在微服务之旅中取得成功。
背景故事
我队最近读了一篇关于用A. Lukyanchikov构建Spring Cloud和Docker微服务架构的文章。如果您还没有阅读它，那么您应该，因为它全面概述了使用Spring Cloud创建基于微服务的简单系统所需的内容。为了构建可扩展且具有弹性的微服务系统，该系统可以增长到数十或数百个服务，它必须在具有广泛构建时间和运行时功能的工具集的帮助下进行集中管理和管理。使用Spring Cloud，涉及实现功能服务（例如统计服务，帐户服务和通知服务）和支持基础结构服务（例如日志分析，配置服务器，服务发现，身份验证服务）。使用Spring Cloud描述此类MSA的图表如下：
带有Spring Cloud的MSA（作者：A。Lukyanchikov）
该图涵盖了系统的运行时方面，但没有涉及包装，持续集成，扩展，高可用性，自我修复方面，这些在MSA世界中也非常重要。假设大多数Java开发人员都熟悉Spring Cloud，在本文中我们将通过解决这些额外的问题来了解Kubernetes与Spring Cloud的关系。
微服务问题
我们不是通过功能比较来做一个功能，而是让我们看看更广泛的微服务问题，看看Spring Cloud和Kubernetes如何解决这些问题。今天MSA的一个好处是，它是一种具有良好理解效益和权衡的建筑风格。微服务实现了强大的模块边界，独立部署和技术多样性，它们但以开发分布式系统-状语从句：显关系着的运营开销为代价。因此，它是一个关键的成功因素，可以帮助您尽可能多地解决MSA问题。快速而简单的开始很重要，但是生产之旅很长，需要你来到这个高度才能达到目标。
微服务问题
在上图中，我们可以看到一个列表，其中包含最常见的技术问题（我们没有涵盖非技术问题，如组织结构，文化等），这些问题必须在MSA中解决。这是我的观点，对于不同的组织而言会有所不同，但在大多数情况下，它应该适用于所有人。
技术制图
这两个平台非常不同，它们之间没有直接的特征奇偶性。如果我们将每个MSA关注点映射到用于在两个平台中解决它的技术/项目，我们会提出下表。
Spring Cloud和Kubernetes Technologies
上表的主要内容是：
-
Spring Cloud具有丰富的集成良好的Java库，可以解决作为应用程序堆栈一部分的所有运行时问题。因此，微服务本身具有库和运行时代理，可以进行客户端服务发现，负载平衡，配置更新，度量跟踪等。单例集群服务，批处理作业等模式也在JVM中进行管理。
-
Kubernetes是多语言，不仅仅针对Java的平台，而是针对所有语言方式解决通用的分布式计算挑战。它在应用程序堆栈之外的平台级别上提供配置管理，服务发现，负载平衡，跟踪，度量，单例，预定作业的服务。应用程序不需要任何用于客户端逻辑的库或代理，它可以用任何语言编写。
-
在某些领域，两个平台都依赖于类似的第三方工具。例如ELK和EFK堆栈，跟踪库等。
-
一些库如Hystrix，Spring Boot在这两种环境中同样有用。在某些领域，两个平台都是互补的，可以组合在一起以创建更强大的解决方案（KubeFlix和Spring Cloud Kubernetes就是这样的例子）。
微服务要求
为了演示每个项目的范围，这里有一个（几乎）端到端MSA要求的表格，从底部的硬件开始，到最顶层的的DevOps和自助服务体验以及它与Spring Cloud和Kubernetes平台。
微服务要求
在某些情况下，两个项目都使用不同的方法处理相同的要求，在某些领域，一个项目可能比另一个项目更强。但也有一个甜蜜点，两个平台互为补充，可以结合使用，提供卓越的微服务体验。例如，Spring Boot提供了用于构建单个jar应用程序包的Maven插件。结合Docker和Kubernetes声明的部署和调度功能，可以轻松运行Microservice。同样，Spring Cloud具有应用内弹性创建库，使用Hystrix（带隔离和断路器模式）和 Ribbon（用于负载平衡）创建弹性，容错的微服务。但仅凭这一点是不够的，当他与Kubernetes的运行时状况检查结合使用时，进程重启和自动扩展功能将微服务转变为真正的防碎片系统。
长处和短处
由于两个平台都没有直接比较功能，而不是挖掘每个项目，这里是每个平台总结的优缺点。
Spring Cloud
Spring Cloud为开发人员提供了工具，可以快速构建分布式系统中的一些常见模式，例如配置管理，服务发现，断路器，路由等。它构建于用Java开发人员编写的基于Java的Netflix OSS库之之上。
优势
-
Spring Platform自身提供的统一编程模型，以及Spring Boot的快速应用程序创建功能，为开发人员提供了出色的微服务开发体验。例如，只需很少的注释就可以创建一个配置服务器，而更少的注释可以让客户端库配置您的服务。
-
有大量的库可以解决大多数运行时问题。由于所有库都是用的Java编写的，因此它提供了多种功能，更好的控制和微调选项。
-
不同的Spring Cloud库彼此很好地集成在一起。例如，Feign客户端也将使用Hystrix进行电路中断，而Ribbon则用于负载平衡请求。一切都是注释驱动，易于开发，感觉像Java开发人员的天堂。
弱点
-
Spring Cloud的一个主要优点也是它的缺点 – 它仅限于Java .MSA的强大动力是能够需要时更改技术堆栈，库甚至语言。Spring Cloud无法做到这一点。如果您想使用Spring Cloud / Netflix OSS基础架构服务，例如配置管理，服务发现，负载平衡，那么解决方案并不优雅。在Netflix的普拉纳的项目实现了跨斗模式，以公开的基于Java的的客户端库通过HTTP，使其可能写在非JVM语言应用在NetflixOSS生态系统中存在，但它是不是很优雅。此外，由于我写了这篇文章，匹维托宣布了一个名为SteelToe的新酷项目，它也允许从净客户端使用服务发现和配置服务器服务。
-
没有为Java的人员开发责任太多关心Java的状语从句：应用程序来处理。每个微服务都需要运行各种客户端来进行配置检索，服务发现和负载平衡。设置它们很容易，但这并不会将运行时依赖性的构建时间隐藏到环境中。例如，我可以使用@EnableConfigServer创建一个配置服务器容易注释，但这只是快乐的道路。每次我想运行单个微服务时，我都需要启动并运行Config Server 。对于受控环境，我必须考虑使用配置服务器高度可用，并且因为它可以由Git或Svn支持，所以我需要共享文件系统。同样，对于服务发现，我需要首先启动Eureka Server。对于受控环境，我需要在每个AZ等上集中多个实例。感觉就像Java的开发人员一样，除了实现所有功能服务之外，我还必须构建和管理一个不重要的微服务平台。
-
单独的Spring Cloud在微服务之旅中的范围较短，您还需要考虑自动部署，调度，资源管理，流程隔离，自我修复，构建管道等，以获得完整的微服务体验。对于这一点，我认为将Spring Cloud单独与Kubernetes进行比较是不公平的，Spring Cloud + Cloud Foundry（或Docker Swarm）和Kubernetes之间的比较更公平。但这也意味着，对于完整的端到端微服务体验，Spring Cloud必须补充类似Kubernetes本身的东西。
Kubernetes
Kubernetes是一个开源系统，用于自动化容器化应用程序的部署，扩展和管理。它是多语言，提供配置，运行，扩展和管理分布式系统的原语。
优势
-
Kubernetes的英文一个多语言状语从句：通用容器管理平台个人文库，能够运行云原生和传统的容器化应用程序。它提供的服务（如配置管理，服务发现，负载平衡，指标收集，日志聚合）可以通过各种语言使用。这允许组织中的一个平台可供多个团队（包括使用弹簧框架的Java的开发人员）使用并用于多种目的：应用程序开发，测试环境，构建环境（运行源代码控制系统，构建服务器，工件存储库），等等
-
与Spring Cloud相比，Kubernetes 解决了更广泛的MSA问题。除了提供运行时服务之外，Kubernetes还允许您配置环境，设置资源约束，RBAC，管理应用程序生命周期，启用自动缩放和自我修复（行为就像几乎反一个混乱平台个人文库）。
-
我无法抗拒自己提到Kubernetes技术是基于谷歌15年的研发和管理容器的经验。此外，有近千个提交者，它是Github上上最活跃的开源社区之一。
弱点
-
Kubernetes是多语言，因此它的服务和原语是通用的，并没有针对不同的平台进行优化，例如Spring Cloud for JVM。例如，配置作为环境变量或已安装的文件系统传递给应用程序。它没有Spring Cloud Config提供的精美配置更新功能。
-
Kubernetes仍然是一个相对较新的平台（2岁），仍在它积极开发状语从句：发展。因此，每个版本都添加了许多新功能，这些功能可能难以跟上。好消息是，已经设想了这个，并且API是可扩展和向后兼容的。
两全其美
正如您所看到的，这两个平台在某些领域都具有优势，而在其他领域也有待改进.Spring Cloud是一个快速入门，开发人员友好的平台，而Kubernetes是DevOps友好的，具有陡峭的学习曲线，但涵盖了更广泛的微服务问题。以下是这些要点的摘要。
长处和短处
这两个框架都针对不同的MSA问题，他们以一种根本不同的方式来解决这个问题.Spring Cloud方法试图通过让开发人员轻松解决JVM内部的每个MSA挑战，而Kubernetes方法试图通过在平台级别解决问题来使问问消失.Spring Cloud在JVM中非常强大，而Kubernetes在管理这些JVM方面非常强大。因此，将它们结合起来并从两个项目的最佳部分中受益，感觉就像是一种自然的进步。
Spring Cloud由Kubernetes支持
通过这样的组合，Spring提供了应用程序打包，Docker和Kubernetes提供了部署和调度.Spring通过Hystrix线程池提供应用程序内批量处理，Kubernetes通过资源，进程和命名空间隔离提供批量处理.Spring为每个微服务提供健康端点，Kubernetes执行健康检查和流量路由到健康服务.Spring外部化和更新配置，Kubernetes将配置分发给每个微服务。这个清单一直在继续。
我最喜欢的微服务堆栈
我最喜欢的微服务平台怎么样？我喜欢他们俩。我喜欢Spring框架提供的开发人员体验。它是所有注释驱动的，并且有涵盖所有功能需求的库。我也喜欢Apache Camel（在本例中）中是Spring Integration），它与应用程序级别的集成，连接器，消息传递，路由，弹性和容错有关。然后，对于与群集和管理多个应用程序实例有关的任何事情，我更喜欢神奇的Kubernetes功能。每当功能重叠时，例如服务发现，负载平衡，配置管理，我都会尝试使用Kubernetes提供的多语言原语。
版权声明：本文为zzch原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。