2019独角兽企业重金招聘Python工程师标准>>> 
自微服务架构开始兴起已近三年。我还记得，早在2015年，当我撰写关于Spring Cloud Netflix微服务架构组件的第一篇文章时。
随着时间的推移，该架构已经成熟，并已被Spring Cloud整合到解决通常云问题的新解决方案中。例如，Sleuth，Zipkin，Contract ...... 就是这种情况......
但是现在架构趋向于朝着不同的方向发展。在这篇文章中，我们将分析迄今为止微服务架构的路径以及未来将伴随我们的工具和技术。
第1集：微服务的诞生
回到起源，我们必须回到2015年初，当时“微服务”的概念在西班牙开始变得强劲起来。
虽然几个月前全球开始采取相关措施，但正如我们在此图表中看到的那样，它代表了Google搜索“微服务”的数量：
一个 天，正处于鼎盛时期，但它仍然有旅游作为目前仍有不少企业尚未实施，不仅微服务，而且甚至不知道它们是什么。
微服务的第一个堆栈被释放，或者说取得了相对普及是Netflix的，这是通过Spring作为云施洗，他为主要解决方案的叠泉，云Netflix的，看到光在她的第一2015年3月发布。
今天仍然是云计算的所有解决方案，包括Spring，最受关注和最受欢迎的：
此外，另外两个解决方案（Consul和Zookeeper）使用Netflix堆栈的几个部分，例如Zuul ，Ribbon 和Hystrix 。 最初，该架构由以下部分组成：
- 配置服务器：外部化配置服务器，允许我们集中生态系统的所有配置。它不是Netflix的一部分（因为Netflix使用的是Archaius），但它是由Spring开发的。
- Eureka ：服务器，用于注册微服务和有关它们的元数据。
- 功能区：用于在客户端平衡请求的库。它与Eureka通信以获得每个微服务的可用实例的寄存器。
- Hystrix ：使用断路器模式进行级联错误管理的库。
- Zuul ：作为API网关/边缘服务的服务器是微服务生态系统的入口点。
对于那些仍然不了解它们的人，你可以在这里更详细地找到它们。
与我们在单片架构中看到的相比，这组件虽然看起来很大，却解决了分布式架构的主要需求：注册，集中配置，平衡，失败前的弹性......
是的，它在软件层中完成，包含用于此类功能的专用服务器（Eureka，Config-server和Zuul）以及我们整合到我们的应用程序（Hystrix和Ribbon）中的库。
逻辑上，与微服务的使用相关联，我们用于部署容器解决方案，在这种情况下，我们都知道并且在市场上最受欢迎的解决方案：Docker。
另一个问题是容器编排解决方案。我们是一个少数早期采用的OpenShift 3，红帽解决方案基于Kubernetes，这是在推出2015年6月。
但实际情况是，当时已经有各种容器编排解决方案。当然，没有一个是非常成熟的，它们在市场上也没有多少。
第2集：建立
自2015年问世以来，微服务架构迅速变得非常重要，并且随着时间的推移而不断增加。
在云解决方案成功的推动下，作为他们的主要架构解决方案，两者都在这里相辅相成。
与任何取得成功的架构或工具一样，一系列应用程序和其他库涵盖了最初未被考虑的功能区域。
这就是请求的可追溯性，这是分布式系统中的一个共同需求，它最初没有超出手动实现的解决方案。
这些和其他需求反映在完成我们生态系统的新图书馆中，其中一些是：
- 侦探：库允许我们根据标头的组合在不同的应用程序/微服务之间分布请求的可跟踪性。
- Zipkin ：存储临时数据的服务器，引用分布式请求进行相关性和延迟研究。
- 合同：库允许我们实施消费者驱动的合同模式，以增加我们的更改不会导致任何API条件中断的信心。
此外，演变也在继续，不仅仅是书店的一部分。他们开始为其他功能定义标准堆栈，这对于日志记录和监控至关重要。
这是堆栈的情况下（F）K（Elasticsearch - Logstash或FluentD - Kibana）用于记录，虽然他们是已经存在于市场，用于这些用途的工具，成为了这些新的架构中不可或缺的部分增加它的受欢迎程度。
通过所有这些新工具/书店，我们享受了一个更完整的生态系统，同时比现在更加复杂，它实际上涵盖了我们所拥有的所有需求。
反过来开始出现的非需要 - 阻断异步通信在微服务的体系结构，情况即在不存在在Spring纯试剂溶液通常与寻址Vert.x。
事实上，这种缺乏解决方案的原因是最近在春季5中支持反应性。
第3集：Kubernetes的崛起
正如我们之前评论的那样，当这些新架构出现时，市场上确实没有很多容器编排解决方案。
Kubernetes，Openshift，Docker Swarm，都在2015年的1.0.0版本中出现，2016年的Mesos ......在市场上没有主导解决方案。
时间的流逝给我们留下了一个看似明显的支配者，那就是Kubernetes，或者基于Kubernetes的解决方案，就像Openshift本身一样。
正因如此，我们已经可以发现管理解决方案Kubernetes 在不同的平台：在谷歌逻辑（因为他们Kubernetes的创造者）与Kubernetes引擎，而且还与亚马逊AWS EKS和天青与AKS。
同样，我们在帖子开头评论的一些功能，如Ribbon，Eureka和Config Server执行的负载平衡，注册，集中配置也由PaaS提供。那么为什么要使用Spring Cloud Netflix提供的？
这是几个客户抨击我们的问题。解决方案很简单：在该架构的初始阶段，市场上没有建立编排解决方案。
在软件架构中包含这些部分（Eureka，Ribbon ......）使其更加便携。由于这些服务包含在工件本身中，因此可以在不同的云解决方案之间移动应用程序，而无需担心这些横向服务的耗尽。
同样，Spring Cloud Netflix提供的解决方案比云解决方案通常提供的解决方案具有更强大的功能。这些是一些额外的功能，提供：
- Ribbon 除了允许我们实现自己的平衡算法之外，还提供不同的平衡算法，这比包含PaaS的典型Round Robin或Random提供了更多的灵活性。
- Eureka允许我们 在注册表中包含和查阅有关实例的其他信息：网址，元数据......在PaaS解决方案中，我们通常无法选择注册表中包含的信息。
- Config Server为我们提供了一个分层的属性系统，允许我们查阅git存储库的各个分支和/或标签。
但是，显然，我们将利用它们达到我们使用它们的程度。就像购买670马力的法拉利车在高速公路上不能超过120公里/小时的人一样，可以安静地使用一个实用工具。
以类似的方式，我们有一个具有所有这些可能性的架构，但我们没有利用它们，这是大多数客户端通常会发生的事情：它们不需要这种高级架构功能。
目前，鉴于这种观点，Kubernetes似乎是市场上占主导地位的云解决方案，并且PaaS本身涵盖了分布式系统的许多固有需求，因此它承担责任是有道理的。
事实上，如果我们考虑PaaS理念，那就是它的目的：从较低级别的功能/资源中抽象出来，以便应用程序可以专注于业务逻辑。所有这些功能都很清楚，它们不属于业务范围。
这使我们能够将我们的应用程序（即我们的业务逻辑）与管理其分布式特性所固有的结构需求分离，从而使系统的不同层之间的分离更加明确。
这些是Kubernetes可以吸收的Spring Cloud Netflix的结构特征：
注册，平衡和健康检查（尤里卡和丝带）
Kubernetes证明了系统中出现的每个新Pod。但与Eureka + Ribbon组合不同，平衡不是在客户端完成的，因此应用程序不必知道服务的所有现有实例（这是通过Eureka客户端完成的）。
应用程序知道的是Kubernetes 服务层，它将是一个凝聚服务实例的抽象。通过这种方式，客户调用所述服务层，该服务层将维护一个恒定的地址，并且该地址将是对特定目标实例执行平衡的地址。
Kubernetes还将负责定期进行健康检查，以检查实例的健康状况。在Eureka的情况下，反过来，实例是那些通知它们对服务器的正确可用性的实例。
集中配置（配置服务器）
由于Kubernetes的最新版本有可用的configmaps。这些允许我们将属性作为环境变量单独存储为属性文件（本地或远程）。
这些属性可用于从容器的定义到容纳到容器中的容积，类似于秘密。
即使面对必须迁移到基于非Kubernetes的解决方案的情况，现实情况是，今天大多数PaaS提供类似的服务。
但是，Kubernetes仍然有一些功能无法覆盖Spring Cloud Netflix所做的功能，这将无法让我们完全分离。
这些功能是级联错误管理，网关API，请求可追溯性......这就是我们进入微服务架构的下一个重要步骤。
第4集：街区新生儿
如果我们考虑微服务架构中给我们带来最多问题的部分，我相信我们所有与他们合作过的人都会同意这一切都与网络有关。具体而言，一切都与延迟，远程调用中的故障管理，平衡，请求的可追溯性，对不存在的实例的调用或下降有关...
这些情况的责任分为不同的层次。例如，PaaS（或注册服务）负责向我们提供健康实例列表。Hystrix负责管理外部呼叫以控制超时和管理故障情况......
在这个灰色区域，嵌套在应用层和PaaS之间，在出现更多问题的时刻，我们将在这里找到微服务架构的新革命。
输入Istio
Istio是一种服务网络解决方案，基于Google在执行大规模服务方面的经验和最佳实践。它与IBM和Lift共同开发，于2017年5月作为Opensource发布，目前版本为0.7.1，对应于今年3月。从版本0.3.0开始，他们计划每月发布一个版本。
对于那些不熟悉服务网格概念的人，我认为这是一个最好的定义：
“服务网格是一个专用的基础设施层，用于使服务到服务通信安全，快速和可靠。如果您正在构建云本机应用程序，则需要一个服务网格“，Blog Buoyant：什么是服务网格？为什么我需要一个呢？
Service Mesh是一个在去年开始大量涌现的概念。证据就是Paypal或Ticketmaster这样拥有大量流量的大公司已经在使用它，而且Envoy和Linkerd已经是Cloud Native Computing Foundation的一部分。
但在进入为什么微服务世界将要改变之前，让我们看看它将如何实现。
Istio是一种工具，它可以收集我们在其下一层（PaaS）和紧接上方（应用程序）中放置的功能，以负责管理与网络通信相关的所有内容。
实际上，Istio并没有引入新的功能，而是将现有的功能移动到它所在的中间层。
为此，它所做的是在我们的应用程序旁边放置一个代理，它将拦截它们的所有网络通信，管理它们以提供可靠性，弹性和安全性。
在我们的应用程序旁边放置此代理称为sidecar-proxy模式。这一点，脚踏实地，包括，在我们的应用程序的容器荚内的例子Kubernetes部署，增派容器所述代理，你可以看到下面的图片：
Istio 默认使用Envoy 作为sidecar-proxy，它将伴随我们所有的微服务。还可以将Linkerd用于数据平面。
Istio在我们的应用程序的单独容器中运行的事实导致服务网格本身和应用程序之间的更大分离。
此外，在从Ribbon和Hystrix等库中收集功能时，它将应用程序完全从结构复杂性的管理中解放出来。
在处理与网络通信相关的所有事情时，Istio为我们提供了大量功能，其中包括：
- 路由请求：我们可以根据不同的标准，如源应用程序，目的，应用程序版本，请求头路由请求......此外，我们可以按百分比获得的流量或重复什么可以让我们金丝雀部署和A / B测试。
- 运行状况检查和负载平衡：控制健康实例并使用不同的可用算法进行平衡。
- 管理超时和断路：我们可以配置不同服务的超时以及断路，重试的配置......
- 故障注入：为了测试我们应用程序的弹性，我们可以插入两种类型的故障：延迟和取消请求。
- 配额管理：允许您设置呼叫限制。
- 安全性：不同服务之间的安全通信，基于验证通信两部分的角色的访问，白名单和黑名单......
- 监控和记录：记录，捕获服务网格指标，分布式可追溯性......
它可以部署在不同的基础架构上：Kubernetes，基于Eureka或Consul注册的环境以及很快在CloudFoundry和Mesos中注册的环境。
如果我们仔细研究它的功能，我们会发现它收集了Netflix套件的许多职责：断路和Hystrix超时管理，平衡功能区请求......
如果你想深入研究这个主题，我推荐这篇文章，其中包括Hystrix和Envoy / Istio之间非常好的比较。
此外，Istio与Spring Cloud已经使用的一些解决方案集成在一起，就像Zipkin的情况一样，它可以在使用Eureka作为记录的环境中工作。
它还与市场上的其他现有解决方案集成，用于公制存储，日志记录，配额管理......例如Prometheus，FluentD，Redis ......
只是覆盖功能反向代理，断路和管理超时执行Zuul和豪猪，这是两个工具评论说，他不能代替Kubernetes使得事实上它一个候选人来完成退休套房Netflix的。
为什么微服务架构的下一步呢？
我们评论了（上面）Istio给我们的功能以及他们的一般情况：起源，版本政治......
但真正有趣的是分析为什么我们认为它将成为市场上最好的解决方案之一，如果不是最重要的解决方案。我们收集了一些因素：
Service-mesh正在进入市场
市场上已有服务网络解决方案，例如Linkerd，这些解决方案正在逐渐建立（我们已经提到它们包含在Cloud Native Computing Foundation的保护下）。此外，还有更多新的解决方案，如Conduit。
特使是CNCF的一部分
我们再次强调云原生计算基金会作为云环境中最相关项目的凝聚者的重要性（您只需要看到项下的项目）。
特使，Istio用于其边车的代理人就是其中之一。Envoy在Lyft公司生产一年多后，在超过10000个VM中处理100多项服务，每秒处理2M请求，因此被Lyft发布。
这仅强调了Istio用于其构造的坚固支柱。
在更高抽象层次上的复杂和关键功能
围绕网络管理的一切通常都是微服务生态系统最头疼的问题之一。
这些功能对整个系统的正常运行至关重要，但配置和管理通常很复杂。
Istio为我们提供了一个强大的工具，可以封装所有这些问题及其管理，同时允许应用程序和PaaS本身从这些复杂性中抽象出来。
与Kubernetes非常好的整合
基于Kubernetes的解决方案是那些在市场上更具相关性的解决方案。除了最初由谷歌（如Kubernetes）开发之外，Istio使用非常相似的语法。
扩展Kubernetes API以添加新类型的资源和属性，但仍然保持其相同的本质。
所有这些意味着，尽管有新的资源和概念，但对于之前曾与Kubernetes合作过的人来说，API和与Istio的交互很容易识别并立即对它有一种熟悉感。
在Openshift的路线图上
正如我们评论的那样，Openshift基于Kubernetes，而且Istio与谷歌的整合非常好，而且来自谷歌，所有这些似乎都表明Istio将是Openshift中提供的解决方案。
关于如何与Istio集成，已经有关于Openshift自己网站的帖子和教程。
Polyglot微服务生态系统
微服务架构的一个特征是它们必须是多字形的。但是，目前，Netflix套件仅适用于Java ，因此如果我们使用任何其他语言的微服务并且我们想在Eureka注册，我们将不得不自己进行集成。
以类似的方式，我们不能使用像Hystrix这样的库，并且在我们使用的语言中没有类似的库，我们将不得不打破我们自己的断路器。
相反，Istio在使用边车模式时完全独立于编写应用程序的语言。无论生成它们的语言如何，Istio都会简单地拦截调用。
有很多原因可以解释为什么Istio将成为微服务架构的下一个重大变革，以及为什么我们应该开始实施它。
同时还有一个原因会减慢其进度，并且尽管它是一个强大而稳定的产品，但它的几乎所有功能和集成目前都处于alpha或beta阶段。
今天采用Istio可能有点早，但它确实指出了一些方法，一个雄心勃勃的路线图，它就在这里。
结论
我们已经遍历了最近的微服务架构，并指出了它们的未来。Be Istio，Linkerd，甚至是管理市场的Conduit，显而易见的是服务网络正在努力。
如今，没有多少公司将它们纳入其堆栈，有些甚至不在其路线图中。但我们只需要回顾并记住Docker发生的事情，作为一种相对年轻的技术进入市场，并在几年内将其应对为今天不可或缺的工具。
随着服务网的兴趣越来越大，新的解决方案出现的数量和功率以及它们的灵活性，它似乎是合乎逻辑来想，几年大家谁是部署分布式云应用的范围内会做用手段的服务网格。
来源
- Google云平台博客：Istio：开发和管理微服务的现代方法。
- Istio的博客：介绍Istio。
- Istio文档。
- 浮力博客：什么是服务网格？为什么我需要一个呢？
- Christian Posta的博客：比较特使和Istio电路打破Netflix OSS Hystrix。
- Kubernetes文档：配置Pod以使用ConfigMap。