微服务2.0时代来临？程序员应该何去何从？
自微服务架构开始兴起已近三年多了，早期的Spring Cloud Netflix架构已经成熟，并已被Spring Cloud整合到解决一般云问题的新解决方案中，例如，Sleuth，Zipkin，Contract等就是这种状况。git
可是如今架构趋向于朝着不一样的方向发展。在这篇文章中，咱们将分析迄今为止微服务架构的路径以及将来将伴随咱们的工具和技术。web
微服务的诞生
回到起源，咱们必须回到2015年初，当时“微服务”的概念在西班牙开始变得强劲。微服务的第一个开发堆栈被发布，也就是取得了相对普及的Netflix堆栈，在第一2015年3月发布。算法
今天它仍然是云计算的全部解决方案包括Spring中最受关注和最受欢迎的：
安全
另外两个解决方案（Consul和Zookeeper）使用了与Netflix堆栈的不一样组件，Netflix组件包括Zuul ，Ribbon 和Hystrix 。 最初，该架构由如下部分组成：
服务器
配置服务器：外部化配置服务器，容许咱们集中生态系统的全部配置。它不是Netflix的一部分（由于Netflix使用的是Archaius），但它是由Spring开发的。网络
- Eureka ：服务器，用于注册微服务和有关它们的元数据。
- Ribbon：用于在客户端中平衡请求的库。它与Eureka通讯以得到每一个微服务的可用实例的寄存器。
- Hystrix ：使用断路器模式进行级联错误管理的库。
- Zuul ：将做为API网关/边缘服务的服务器，做为微服务生态系统的入口点。
若是如今咱们看惯了单体巨石架构，这组架构彷佛变大了，可是解决了分布式架构的主要需求：注册，集中配置，负载平衡，抵御失败…架构
在部署逻辑上，与微服务的使用相关联，咱们使用容器解决方案进行部署，在这种状况下，咱们都知道而且是市场上最受欢迎的解决方案：Docker。dom
另外一个问题是容器编排解决方案。咱们是一个少数早期采用的OpenShift 3，红帽解决方案基于Kubernetes，这是在推出2015年6月。分布式
但实际状况是，当时已经有各类容器编排解决方案。固然，没有一个是很是成熟的，它们在市场上也没有多少占有率。ide
微服务的创建
自2015年问世以来，微服务架构迅速变得很是重要，而且随着时间的推移而逐渐增长。在云解决方案成功的推进下，做为他们的主要架构解决方案，二者都在这里相辅相成。
与任何取得成功的架构或工具同样，一系列应用程序和其余库涵盖了最初未被考虑的功能区域。这就是请求的可追溯性，这是分布式系统中的一种常见需求，它最初没有超出手动实现的解决方案。
这些和其余需求反映在完成咱们生态系统的新库包中，其中一些是：
Sleuth：库容许咱们根据标头的组合在不一样的应用程序/微服务之间分布可请求的请求。
Zipkin ：存储临时数据的服务器，引用分布式请求进行相关性和延迟研究。
Contract合同：库容许咱们实施消费者驱动的合同模式，以增长咱们的更改不会致使任何API条件中断的信心。
此外，演变也随之而来，不只仅是一部分了，他们开始为其余功能定义标准堆栈，好比对记录和监控相当重要的组件也开始涌现出来。
这时，用于记录监控这些用途的工具好比（Elasticsearch - Logstash或FluentD - Kibana）成为了这些新的架构中不可或缺的部分，增长了它的受欢迎程度。
经过全部这些新工具/库包，咱们享受了一个更完整的生态系统，同时比如今更加复杂，它实际上涵盖了咱们所拥有的全部需求。
另外一方面，在微服务架构设计中出现了非堵塞的通讯须要，当时在没有一个纯粹的完整性解决办法的状况下使用Vert.x，后来Spring 5的React提供了支持。
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，请求可追溯性…这就是咱们进入微服务架构的下一个重要步骤。
新宠的诞生
若是咱们考虑微服务架构中给咱们带来最多问题的那部分，大多数人都赞成这些问题都与网络有关。具体而言，一切都与延迟，远程调用失败的管理，平衡，请求的可追溯性，对不存在的实例的调用或降低有关…
这些状况下的责任分为不一样的层次。例如，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中，部署了一个带有这种代理的附加容器，以下图所示：
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 …
结束语
最后感谢你们的观看，以上文章为我的观点，若是对你有帮助，记得关注点赞转发支持！