转载

微服务2.0时代：Spring Cloud Netflix与 Kubernetes＆Istio比较

自微服务架构开始兴起已近三年多了，早期的Spring Cloud Netflix架构已经成熟，并已被Spring Cloud整合到解决通常云问题的新解决方案中，例如， Sleuth，Zipkin ， Contract 等就是这种情况。

但是现在架构趋向于朝着不同的方向发展。在这篇文章中，我们将分析迄今为止微服务架构的路径以及未来将伴随我们的工具和技术。

第1集：微服务的诞生

回到起源，我们必须回到2015年初，当时“微服务”的概念在西班牙开始变得强劲。微服务的第一个开发堆栈被发布，也就是取得了相对普及的Netflix堆栈，在第一2015年3月发布。

今天它仍然是云计算的所有解决方案包括Spring中最受关注和最受欢迎的：

微服务2.0时代：Spring Cloud Netflix与 Kubernetes＆Istio比较

另外两个解决方案（ Consul 和Zookeeper）使用了与Netflix堆栈的不同组件，Netflix组件包括Zuul ，Ribbon 和Hystrix 。最初，该架构由以下部分组成：

微服务2.0时代：Spring Cloud Netflix与 Kubernetes＆Istio比较

配置服务器：外部化配置服务器，允许我们集中生态系统的所有配置。它不是Netflix的一部分（因为Netflix使用的是Archaius），但它是由Spring开发的。
Eureka ：服务器，用于注册微服务和有关它们的元数据。
Ribbon：用于在客户端中平衡请求的库。它与Eureka通信以获得每个微服务的可用实例的寄存器。
Hystrix ：使用断路器模式进行级联错误管理的库。
Zuul ：将作为API网关/边缘服务的服务器，作为微服务生态系统的入口点。

如果现在我们看惯了单体巨石架构，这组架构似乎变大了，但是解决了分布式架构的主要需求：注册，集中配置，负载平衡，抵御失败...

在部署逻辑上，与微服务的使用相关联，我们使用容器解决方案进行部署，在这种情况下，我们都知道并且是市场上最受欢迎的解决方案： Docker 。

另一个问题是容器编排解决方案。我们是一个少数早期采用的 OpenShift 3 ，红帽解决方案基于Kubernetes，这是在推出 2015年6月。

但实际情况是，当时已经有各种容器编排解决方案。当然，没有一个是非常成熟的，它们在市场上也没有多少占有率。

第2集：建立

自2015年问世以来，微服务架构迅速变得非常重要，并且随着时间的推移而逐渐增加。在云解决方案成功的推动下，作为他们的主要架构解决方案，两者都在这里相辅相成。

与任何取得成功的架构或工具一样，一系列应用程序和其他库涵盖了最初未被考虑的功能区域。这就是请求的可追溯性，这是分布式系统中的一种常见需求，它最初没有超出手动实现的解决方案。

这些和其他需求反映在完成我们生态系统的新库包中，其中一些是：

Sleuth：库允许我们根据标头的组合在不同的应用程序/微服务之间分布可请求的请求。
Zipkin ：存储临时数据的服务器，引用分布式请求进行相关性和延迟研究。
Contract合同：库允许我们实施消费者驱动的合同模式，以增加我们的更改不会导致任何API条件中断的信心。

此外，演变也随之而来，不仅仅是一部分了，他们开始为其他功能定义标准堆栈，比如对记录和监控至关重要的组件也开始涌现出来。

这时，用于记录监控这些用途的工具比如（Elasticsearch - Logstash或FluentD - Kibana）成为了这些新的架构中不可或缺的部分，增加了它的受欢迎程度。

通过所有这些新工具/库包，我们享受了一个更完整的生态系统，同时比现在更加复杂，它实际上涵盖了我们所拥有的所有需求。

另一方面，在微服务架构设计中出现了非堵塞的通信需要，当时在没有一个纯粹的完整性解决办法的情况下使用Vert.x，后来Spring 5的React提供了支持。

第3集：Kubernetes的崛起

正如我们之前评论的那样，当这些新架构出现时，市场上确实没有很多容器编排解决方案。

Kubernetes，Openshift，Docker Swarm，都在2015年的1.0.0版本中出现，2016年的Mesos ...... 在市场上没有主导解决方案。

随着时间的推移，我们看起来似乎是一个明显的支配者，那就是Kubernetes，或者基于Kubernetes的 Openshift 的解决方案。

正因如此，我们已经可以发现管理解决方案Kubernetes 实现在不同的平台：谷歌的 Kubernetes引擎，亚马逊 AWS EKS 等。

同样，在帖子开头讨论的一些功能，例如由Ribbon，Eureka和Config Server执行的负载平衡，注册，集中配置也可由PaaS提供。那么为什么要使用Spring Cloud Netflix提供的这些功能呢？

这是几个客户经常询问我们的问题。答案很简单：在该架构的初始阶段，市场上没有建立编排解决方案。

在软件架构中包含这些部分（Eureka，Ribbon ......）使其更加便携。由于这些服务包含在工件本身中，因此可以在不同的云解决方案之间移动应用程序，而无需担心这些横向服务的耗尽。

同样，Spring Cloud Netflix提供的解决方案比云解决方案通常提供的解决方案具有更强大的功能。这些是一些额外的功能，提供：

Ribbon 除了允许我们实现自己的平衡算法之外，还提供不同的平衡算法，这比包含PaaS的典型Round Robin或Random提供了更多的灵活性。
Eureka允许我们在注册表中包含和查阅有关实例的其他信息：网址，元数据......在PaaS解决方案中，我们通常无法选择合并到注册表中的信息。
Config Server为我们提供了一个分层的属性系统，允许我们查阅git存储库的各个分支和/或标签。

我们拥有一个具有所有这些可能性的架构，但我们没有充分利用它们，这通常发生在大多数客户端中：它们不需要这种高级架构功能，因为他们认为可以通过PaaS实现这些功能。

今天，Kubernetes云解决方案是在市场上占主导地位的PaaS，如果我们想想PaaS理念，那它的目的就是：从较低级别的功能/资源中抽象出来，以便应用程序可以专注于业务逻辑。所有这些功能都很清楚，它们不属于业务范围。

这让我们分离我们的应用程序，也就是我们的业务逻辑，这使得系统的各个层之间更明确的分离性质。

这些是Kubernetes可以吸收的Spring Cloud Netflix的结构特征有：

1.注册，负载平衡和健康检查（eureka和Ribbon）

Kubernetes系统中会出现的一个新Pod装载一个微服务，但与Eureka + Ribbon组合不同，负载平衡不是在客户端完成的，因此在Kubernetes中应用程序不必知道服务的所有现有实例（这是通过Eureka客户端完成的）。

在pod中的应用程序知道的是Kubernetes 服务层，这是一个凝聚服务实例的抽象。通过这种方式，客户端调用这个服务层，该服务层将维护一个恒定的地址，并且该地址将执行特定目标实例的平衡。

Kubernetes还将负责定期进行健康检查，以检查实例的健康状况，反过来在Eureka的情况下，是由实例通知服务器是否具有正确的可用性。

2.集中配置（配置服务器）

由于Kubernetes的最新版本有可用的 configmaps 。这些允许我们将属性作为环境变量单独存储为属性文件（本地或远程）。

但是，Kubernetes仍然有一些功能无法覆盖Spring Cloud Netflix所做的功能，这将无法让我们完全分离。这些功能是级联错误管理，网关API，请求可追溯性......这就是我们进入微服务架构的下一个重要步骤。

第4集：街区新生儿

如果我们考虑微服务架构中给我们带来最多问题的那部分，大多数人都同意这些问题都与网络有关。具体而言，一切都与延迟，远程调用失败的管理，平衡，请求的可追溯性，对不存在的实例的调用或下降有关...

这些情况下的责任分为不同的层次。例如，PaaS（或注册服务）负责向我们提供健康实例列表。Hystrix负责管理外部呼叫以控制超时和管理故障情况......

在这个灰色区域，嵌套在应用层和PaaS之间，在出现更多问题的时刻，我们将在这里找到微服务架构的新革命。

Istio

Istio 是一种服务网络解决方案，基于Google在执行大规模服务方面的经验和良好实践。它与IBM和Lift共同开发，于2017年5月作为Opensource发布，他们计划每个月发布一个版本。

对于那些不熟悉服务网格概念的人来说，这里的定义似乎是最好的：

“服务网格是一个专用的基础设施层，用于使服务到服务通信安全，快速和可靠。如果您正在构建云本机应用程序，则需要一个服务网格“，Blog Buoyant：什么是服务网格？为什么我需要一个呢？

Service Mesh 是一个在去年开始大量涌现的概念。这方面的证据就是Paypal或Ticketmaster这样拥有大量流量的大公司已经在使用它，而且 Envoy 和 Linkerd 已经是 Cloud Native Computing Foundation的一部分。

在讨论为什么微服务世界将要发生这些大的变化之前，让我们看看它将如何实现。

Istio是一种工具，可以收集我们在其下层（PaaS）和紧接上方（应用程序）中放置的功能，以负责管理与网络通信相关的所有内容。

实际上，Istio并没有引入新的功能，而是将现有的功能移动到将要放置的中间层。

为此，它所做的是在我们的应用程序旁边放置一个代理，它将拦截它们的所有网络通信，管理它们以提供可靠性，弹性和安全性。

在我们的应用程序旁边放置此代理称为sidecar-proxy边车代理模式。在Kubernetes中，在我们的应用程序的容器部署的pod中，部署了一个带有这种代理的附加容器，如下图所示：

微服务2.0时代：Spring Cloud Netflix与 Kubernetes＆Istio比较

Istio 默认使用Envoy 作为sidecar-proxy，它将伴随我们所有的微服务。还可以将Linkerd用于数据平面。

Istio在我们的应用程序的单独容器中运行的事实导致服务网格本身和应用程序之间的更大分离。

此外，在从Ribbon和Hystrix等库中实现收集功能时，它可以完全免除应用程序对架构复杂性的管理。

在处理与网络通信相关的所有事情时，Istio为我们提供了大量功能，其中包括：

路由请求：我们可以根据不同的标准，如源应用程序，目的，应用程序版本，请求头路由请求......此外，我们可以按百分比获得的流量或重复什么可以让我们金丝雀部署和 A / B测试。
运行状况检查和负载平衡：控制健康实例并使用不同的可用算法进行平衡。
管理超时和断路：我们可以配置不同服务的超时以及断路，重试的配置......
故障注入：为了测试我们应用程序的弹性，我们可以插入两种类型的故障：延迟和取消请求。
配额管理：允许您设置呼叫限制。
安全性：各种服务之间的安全通信，基于验证通信两部分的角色的访问，白名单和黑名单......
监控和记录：记录，捕获服务网格指标，分布式可追溯性......

它可以部署在不同的基础架构上：Kubernetes，基于Eureka或Consul注册的环境以及很快在CloudFoundry和Mesos中注册的环境。

如果我们仔细研究它的功能，我们会发现它收集了Netflix套件的许多职责：断路和Hystrix超时管理，负载平衡Ribbon区请求......

此外，Istio与Spring Cloud已经使用的一些解决方案集成在一起，就像Zipkin的情况一样，它可以在使用Eureka作为记录的环境中工作。

它还与市场上的其他现有解决方案集成，用于公制存储，日志记录，配额管理......例如Prometheus，FluentD，Redis ......

原文 https://www.jdon.com/51617

正文到此结束